Conventions

[StanHelton]

System Structure

I've uploaded v4 of the System FlowChart. There are 2 prototypes in this version. I favor the second one because I think it reflects our general consensus on how vb2pb should look. It's also a better guideline for defining the limits of the various modules we'll have to develop.

Please take a look at it. Offer ideas, suggestions, insults as you feel motivated. When we get this finalized it's a roadmap to the first release.

http://www.powerbasic.com/support/pbforums/showthread.php?t=37748

I've started a new thread called "SourceCode Only". Let's use this for source code until we get the SVN fully functional. Make things easier to find and work on.

http://www.powerbasic.com/support/pbforums/showthread.php?t=37766

Thanks,
Stan

[StanHelton]

Stan, in what way dependent? The lexer (parser) will populate some of these structures but requires rules to do so. Am I missing something?

Maybe not. What I had been doing was building my own parser. Felt like I was duplicating effort when I saw how far along you and Fred are with the Lexer.

[Chris Holbrook]

Just in case anybody's wondering, the class module is dependent on the code line parser so that has to be usable before I can go much further with it.

Stan, in what way dependent? The lexer (parser) will populate some of these structures but requires rules to do so. Am I missing something?

[Fred Harris]

Just ran a quick test w/VB6 Pro sp6. Duplication like that generates a compile time error so it's not likely we'll find such an animal in working VB code.

Thanks for checking that Stan! And Thank Goodness it didn't work!

[StanHelton]

Stan

Silly question here.

Some *&()%%$ fool went and set TODAY as the day to set the conventions in STONE. Are we okay for now?

Rod

This &%^?!!% clown is okay with it.

[Rodney Hicks]

Stan

Silly question here.

Some *&()%%$ fool went and set TODAY as the day to set the conventions in STONE. Are we okay for now?

Rod

[StanHelton]

Stan, after a quick look at your UDTs, the only thing I might add at this time to each is a comment component, which could clarify anything about that item and might also be used as a comment in output code. A good starting point for each.

I have begun.

Rod.

Done. I've updated these types in my vb2pbClassModule working file. Just in case anybody's wondering, the class module is dependent on the code line parser so that has to be usable before I can go much further with it.


New version:

 'VB6 & PB project file names
   TYPE vb2pbFileNamesType
      vbProjectFile AS STRING * 128     'VB6 project file name
      vbCurrentFile AS STRING * 128     'Current VB6 file name
      pbMainFile AS STRING * 128        'Main PB project file name
      pbClassFile AS STRING * 128       'PB .bi for class simulation file name
      pbMacroFile AS STRING * 128       'PB .bi for PB MACROs file name
      vb2pbComment AS STRING * 256   'explain & insert to output code
   END TYPE

   'vb6 class description type - process one vb class file at a time
   TYPE vb2pbClassDescType
      Namee AS STRING * 48                'name of class being processed
      PropertyCount AS LONG               'number of properties in class being processed
      FunctionCount AS LONG               '# of functions
      SubCount AS LONG                    '# of subs
      EventCount AS LONG                  '# of events
      SubClassCount AS LONG               '# of subclasses
      PropertyList AS STRING * 32750      'property names w/separator: $ItemSeparator
      FunctionList AS STRING * 32750      'function names w/separator: $ItemSeparator
      SubList AS STRING * 32750           'subs w/separators: $ItemSeparator
      SubClassList AS STRING * 32750      'subclasses w/separators: $ItemSeparator
      vb2pbComment AS STRING * 256   'explain & insert to output code
    END TYPE

   'vb6 property description type
   TYPE vb2pbPropertyDescType
      Namee AS STRING * 48
      DataType AS LONG
      Declaration AS STRING * 256
      vb2pbComment AS STRING * 256   'explain & insert to output code
    END TYPE

   'vb6 method description type
   TYPE vb2pbMethodDescType
      Namee AS STRING * 48
      DataType AS LONG
      Arguments AS STRING * 256     'use $TermSeparator between each arg definition
      vb2pbComment AS STRING * 256   'explain & insert to output code
    END TYPE

   'vb6 event description type
   TYPE vb2pbEventDescType
      Namee AS STRING * 48
      Arguments AS STRING * 256     'use $TermSeparator between each arg definition
      vb2pbComment AS STRING * 256   'explain & insert to output code
    END TYPE

   'Symbol table description
   TYPE SymbolTableItemType
      vbSymbol AS STRING * 32
      pbEquivalent AS STRING * 32
       vb2pbComment AS STRING * 256   'explain & insert to output code
   END TYPE

[Rodney Hicks]

Stan, after a quick look at your UDTs, the only thing I might add at this time to each is a comment component, which could clarify anything about that item and might also be used as a comment in output code. A good starting point for each.

I have begun.

Rod.

[StanHelton]

I see we're posting while other's are posting and other's are reading and replying and posting. Good show.

Fred, you wrote:


These all show up under the heading reference, but I too am not sure about how to handle them from a lookup point of view. That's why the two UDTs I posted earlier.

If someone else agrees with your thinking here I will go ahead with the first(smaller) UDT for the STATEMENTS, FUNCTIONS, KEYWORDS, and OPERATORS. I don't see any other way of constructing that array other than typing and I would like to start soon.

Rod

I think that's a good place to start, Rod.

Thinking about the objects, properties, events, and methods ....
and building on the udt idea ...
Here are some simple type structures I've been playing with -- anything look useful?

   'VB6 & PB project file names
   TYPE vb2pbFileNamesType
      vbProjectFile AS STRING * 128     'VB6 project file name
      vbCurrentFile AS STRING * 128     'Current VB6 file name
      pbMainFile AS STRING * 128        'Main PB project file name
      pbClassFile AS STRING * 128       'PB .bi for class simulation file name
      pbMacroFile AS STRING * 128       'PB .bi for PB MACROs file name
   END TYPE

   'vb6 class description type - process one vb class file at a time
   TYPE vb2pbClassDescType
      Namee AS STRING * 48                'name of class being processed
      PropertyCount AS LONG               'number of properties in class being processed
      FunctionCount AS LONG               '# of functions
      SubCount AS LONG                    '# of subs
      EventCount AS LONG                  '# of events
      SubClassCount AS LONG               '# of subclasses
      PropertyList AS STRING * 32750      'property names w/separator: $ItemSeparator
      FunctionList AS STRING * 32750      'function names w/separator: $ItemSeparator
      SubList AS STRING * 32750           'subs w/separators: $ItemSeparator
      SubClassList AS STRING * 32750      'subclasses w/separators: $ItemSeparator
   END TYPE

   'vb6 property description type
   TYPE vb2pbPropertyDescType
      Namee AS STRING * 48
      DataType AS LONG
      Declaration AS STRING * 256
   END TYPE

   'vb6 method description type
   TYPE vb2pbMethodDescType
      Namee AS STRING * 48
      DataType AS LONG
      Arguments AS STRING * 256     'use $TermSeparator between each arg definition
   END TYPE

   'vb6 event description type
   TYPE vb2pbEventDescType
      Namee AS STRING * 48
      Arguments AS STRING * 256     'use $TermSeparator between each arg definition
   END TYPE

   'Symbol table description
   TYPE SymbolTableItemType
      vbSymbol AS STRING * 32
      pbEquivalent AS STRING * 32
   END TYPE

[Rodney Hicks]

I see we're posting while other's are posting and other's are reading and replying and posting. Good show.

Fred, you wrote:

I'd be careful to not confuse VB language reserved words with objects, properties and methods. Why? Don't know exactly. Just feel it in my bones. Somehow, they are different kinds of animals.

These all show up under the heading reference, but I too am not sure about how to handle them from a lookup point of view. That's why the two UDTs I posted earlier.

If someone else agrees with your thinking here I will go ahead with the first(smaller) UDT for the STATEMENTS, FUNCTIONS, KEYWORDS, and OPERATORS. I don't see any other way of constructing that array other than typing and I would like to start soon.

Rod

[Rodney Hicks]

Chris,

Rod, if the VB has IFs shouldn't the PB have corresponding IFs, even if it could have coded in PB in a nicer way? Otherwise we are optimising not just translating.
Reply With Quote

Well, we'd likely be optimising instead of converting, and anticipation requires a sort of AI that we don't need to get into. The IF was just an example of the simplest kind.

The whole idea was a meandering thought, while waiting for direction on the structure of our PB word list. (and we know what thinking does.)

Rod

[StanHelton]

Just ran a quick test w/VB6 Pro sp6. Duplication like that generates a compile time error so it's not likely we'll find such an animal in working VB code.

[Fred Harris]

I havn't gotten to conditional logic yet, but I will soon. At a first pass through this, I'd say PB conditional logic and loop constructs are the same as VB. The only issues would be something lile this...

Select Case txtData.Text
  Case "Fred"

  Case "Stan"

  Case "Chris"

  Case "Elias"

End Select

I believe we've already found ways to handle this, so that doesn't bother me.

In terms of VB's built in "Classes", such as the way they've 'wrapped' text boxes, listboxes, etc., in OOP constructs, we already have the documentation on that and will need to use it. This is also true of the 'Common Controls', i.e., listviiews, tab, progress, etc. In terms of ActiveX controls their properties, methods, etc are found within type libraries and these are accessable through various COM Apis. In the case of user created classes, we'll have the class modules themselves for that, unless its a binary. If a binary the creator should have produced a valid type library. If not it won't be able to be used.

I'd be careful to not confuse VB language reserved words with objects, properties and methods. Why? Don't know exactly. Just feel it in my bones. Somehow, they are different kinds of animals.

Back to object.attribute vs userType.member. The only way I can see seperating these is from the Symbol Table. For example, a user could name a text box txtData and it would have a txtData.Text property for the text string in it. A user could create a TYPE as follows...

Type MyData
Text As Asciiz * 64
End Type

Dim txtData As MyData

Then you would have...

txtData.Text for a text box and for a UDT. I'm hoping VB doesn't allow that. Would someone check? If it does, I'm not sure the solution. We absolutely must be able to determine what any given symbol is.

[StanHelton]

Rod, if the VB has IFs shouldn't the PB have corresponding IFs, even if it could have coded in PB in a nicer way? Otherwise we are optimising not just translating.

My 2 cents: except for the short-circuit processing, IF works the same way in both compilers.

[StanHelton]

how do you decide what to leave out?

A pre-scan of the VB source to pull relevant items from the master based on what turns up? May be the easy way.

only by reference to the symbol table, same way as VB distinguishes them?

yes. I think you're right about that.

Yes but we don't see the source code for the built-in classes

hmmm. True. I'll have to think about that.

[Chris Holbrook]

... there may be certain conditions that VB requires that are unneeded in PB

Rod, if the VB has IFs shouldn't the PB have corresponding IFs, even if it could have coded in PB in a nicer way? Otherwise we are optimising not just translating.

[Rodney Hicks]

Quote:
Originally Posted by Rodney Hicks View Post
The parser may also need a 'look ahead' feature as well. EG: When it encounters "IF" it searches the following code to discern whether a single line "IF" statement or an "IF" block.
Can't see that, why should we care?
Reply With Quote

Perhaps I should have not put that thought down in black and white just yet.
However, there may be certain conditions that VB requires that are unneeded in PB, but that will be obvious to us in time for a later version.

Rod

[Chris Holbrook]

The parser is going to have to decide which of the hundreds of possibles is applicable at each instance, possibly in some recursive fashion, and pass control over to the appropriate code, also possibly in recursive fashion.

Yes! But do we have to pre-scan to build the symbol table or can it be done "on the fly". I would guess that it could.

The parser may also need a 'look ahead' feature as well. EG: When it encounters "IF" it searches the following code to discern whether a single line "IF" statement or an "IF" block.

Can't see that, why should we care?

[Chris Holbrook]

An instance table can be built from the master within the converter so that the master only gets scanned once.

how do you decide what to leave out?

I think we need to know if it's an object.attribute reference or a udt.member reference. Can these two types be identified within the code line?

only by reference to the symbol table, same way as VB distinguishes them?

Fred points out the 50+ attributes built in. The number of attributes probably varies quite a bit between object, event, and method types, especially the user-defined ones...don't all 3 get coded as classes?

Yes but we don't see the source code for the built-in classes

[Rodney Hicks]

Two possible UDTs to help us out. Other ideas welcomed.

TYPE SpecificWord
    vbTERM AS STRING*32   'the delimited word the parser will encounter
    pbTERM AS STRING*32   'the current equivalent of the vbTERM or if null a function call
    IsWhat AS LONG        '0=statement,1=keyword,2=function,4=Object,8=Event,16=Methods,32=constants,64=Properties,128=Operators
    Comment AS STRING*48  'a comment that may or may not be suitable to include in output source code
    QFlag AS LONG         'an as of yet undetermined usage
END TYPE

STATIC ParseTerm() AS SpecificWord
DIM ParseTerm(1000)

FUNCTION GetTerm(sParseWord,ParseTerm(?).IsWhat,QFlag)AS STRING

or

TYPE SpecificWord
    vbTERM AS STRING*32   'the delimited VB word the parser will encounter all are listed
    pbTERM AS STRING*32   'the current equivalent of the vbTERM or if null a function call
    IsWhat AS LONG        '0=statement,1=keyword,2=function,4=Object,8=Event,16=Methods,32=constants,64=Properties,128=Operators
    Params AS LONG        'the quantity for the sParseWord or the quantity it could be used in
    Objcts AS LONG        'the quantity for the sParseWord or the quantity it could be used in
    Props AS LONG         'the quantity for the sParseWord or the quantity it could be used in
    Meths AS LONG         'the quantity for the sParseWord or the quantity it could be used in
    Events AS LONG        'the quantity for the sParseWord or the quantity it could be used in
    consts AS LONG        'the quantity for the sParseWord or the quantity it could be used in
    Options AS LONG       'the quantity for the sParseWord or the quantity it could be used in
    comment AS STRING*48  'a comment that may or may not be suitable to include in output source code
    QFlag AS LONG         ' an as of yet undetermined usage
END TYPE

The only element that we can be sure of having a value is the very first, vbTerm, all the rest depend upon that term and must be appropriately filled. All these are examples only.

The function for the second UDT would have to be a little different, but the function would only end up calling another function I expect. Some would return a word to take the place of the non-existent pbTerm.

Any sParseWord not found in the first elements of the UDT would be one of the following:
a variable, an array, a User Defined Function/Sub, something else , all of which would require handling by better minds than me, I mean by the converter.
Note the use of Static. comments?
Should the TYPE definition be included in the *.inc file?
I feel the functions should be in a separate *.inc file or DLL perhaps.
I have to put the word comparison in something usable.

Am I getting close with this?

Rod