MetaBasic

[Charles Pegge]

In earlier topics we discussed the potential for a Preprocessor which could extend the syntax on PowerBasic and other Basics in a very flexible way, enabling for instance, programs containing Global variables to be combined without doing extensive name changes.

Many enhancements can be made merely by managing names. Many older programs are left stranded because it is too time consuming to refactor them manually, or they may be deployed in one project, and you want to use them in another, without altering the original source code.

You may want to do things which are unsupported by the present PB syntax or which are awkward to express. Macros can help but are limited to very simple situations, and will be idiosyncratic to your particular project.

The main disadvantage of sitting a MetaLanguage on top of a language, as Theo points out, is the problem of debugging. The source code to be debugged, is not the code that you wrote yourself. Different debugging methods in the metalanguage are required to be able to trace through a program efficiently.

So with all this in mind, and a trail of old code languishing in the archives, I thought this would be well worth trying. This is something that can be developed progressively, with very simple beginings and plenty of materials to test with.

[Charles Pegge]

Notation / Concepts: Combining programs:

This is a sketch

 
SOLAR x y z wb

 LIST TYPE
 LIST DECLARE
 LIST DIM
 
-------------------------------

 BEGIN MODULE  A_

   SAME wavb() as wb()

   BIND "MyAudio.bas"
   BIND "initial.inc"
   BIND "audio.inc"

 END MODULE

 BEGIN MODULE  B_

   SAME xp as x
   SAME yp as y
   SAME zp as z

   BIND "MyVisuals.bas"
   BIND "3d.inc"
   BIND "controls.inc"

 
 END MODULE



 

[Kent Sarikaya]

Charles is Solar wb  then a global procedure named wb()?

Then in the code after the passes, would it look like wb() or wb?

Sorry for my confusion!

[Charles Pegge]

Kent, I have conflated variables and procedures so both would be affected by the naming scheme.

Both procedures and variables would either get tagged with their module name or translated into a Solar name.

Anything globally defined in the module that does not have a solor name is then visible only within its own module.

The BIND word is a way of including only those INCLUDE FILES that belong to the module. So things ike "win32api.inc"are left alone!

But there is plenty of scope for inventing new rules as we go.

[Charles Pegge]

REGIONS

Extending the Solar / Global / Local paradigm, Regions allow scoping either inside functions or outside them, setting up a namespace for groups of functions or variables.

Unlike Modules, regions can be nested: in this example xxx is visible to the entire module, xx is visble to Region AA but function x is only visble to region A. And anything defined within Region A or region B is visible only within those regions.
So function X in region A is completely isolated from function x in region B.

This will allow greater encapsulation of program components than is normally possible in conventional BASIC




function xxx()
  ..
end function

REGION AA

    function xx()
     ..
    end function

  REGION A

     function x()
      ..
     end function

  END REGION

  REGION B

    function x()
     ..
    end function

  END REGION

END REGION

[Theo Gottwald]

I have also thought about this Charles.
One more Problem is that you can not easily share the Source code.
Anyway I like the idea because it would be really possible to extend the PB Syntax for example for ne namespaces and Modules.
I would have to be done within a new sort of Editor that can automatically switch between the Source and the generated code (on button click).
And you would need to be able to switch betwenn both views.
Also it would be necesary to change code parts in the "pre-compiled view" and these should then be overtaken to the Source View.

Anyway, did i tell you that  I'd really like to see something that understands PB Syntax (or at least a structural Part of it, without all DDT stuff) and spits out 64 bit executables? 

[Charles Pegge]

Wow! this is an ancient thread. I have in fact, implemented the region idea - as scope blocks and inner functions.

Anyway. To address your points Theo, using one language to generate the source of another, is a process that could be iterated ad infinitum. Oxygen can be embedded (as a dll) in a PB program, and with the right parsing facilities, it is not too difficult to generate any code or coding layer with appropriate syntax checking.

[David Boytor]

eveything you describe is a CLASS in PowerBasic.

CLASS is just more convolution.

Instead of just functions,types,sub - make a class and put all that there so - as point out above - it hides the source code.

OH ya - secrets in code must never be revealed - i guess some would say it deals with patents, copyrights.

well all of it is BS - just!

[Charles Pegge]

I recall Fred saying that the Windows GUI is OOP in disguise. The window styles are effectively classes and all the handles are  object pointers. It is probably the best way we have for handling multiple items consistently.

For the technically minded, black-box software is irritating. You cannot learn from it, but I suppose it is necessary as long as we have a monetised economy, and have to protect intellectual assets.