Announcement

**StanHelton** · 14 Jun 2008, 11:56 AM

First let me say, Excellent Work!

Here's my thoughts:

6 - GLOBALS: Absolutely agree on supporting arguments to include and peer review. I think we should limit the use of globals to critical system level variables. An example:

Code:

GLOBAL ConverterOptions AS ConverterOptionsType

where the type might look something like this:

Code:

TYPE SystemOptionsType
    CodeGeneration AS LONG    ' %TargetSDK, %TargetDDT, %TargetModSDK and so on
    IncludeFiles AS LONG    ' %FormsOnly, %AllProcedures, other descriptive constants
    WinVerOptimization AS LONG    ' %Win9x, %Win2K, %WinXP & etc.
    TargetCompiler AS LONG    ' %PBWin80, %PBCC40
    ....
    ....
END TYPE

7b - PB treats anything after the line continuation as a comment. I think we should ignore this behavior in the compiler and use the apostrophe (') to uniformly identify comments.

11c - File Extension suggestion:
BI for declarations, type definitions, equates, prototypes.
INC for all other code
Resource Files as in PB IDE
DLL - What about treating these like global variables for now: argument for and peer review.

All Documentation - text format to keep it simple.

EXCELLENT WORK !!!!

Stan

**Rodney Hicks** · 14 Jun 2008, 12:25 PM

I see I lost a section somewhere.

There should have been a Heading %EQUATES
That any and all be commented for clarity.

Rod

**StanHelton** · 14 Jun 2008, 12:39 PM

Originally posted by Rodney Hicks View Post

There should have been a Heading %EQUATES
That any and all be commented for clarity.

Rod

Comments STRONGLY encouraged for all equates and for anything that might not be painfully clear.

If you don't get any more comments in the next day or so, let's make it official.

Stan

later: sorry, I didn't see the date. By all means stick to the schedule you set up. sjh

**Rodney Hicks** · 14 Jun 2008, 01:03 PM

As you wish, I only set next Friday so we could practice meeting goals.

Rod

**StanHelton** · 14 Jun 2008, 01:23 PM

Originally posted by Rodney Hicks View Post

As you wish, I only set next Friday so we could practice meeting goals.

Rod

Rod,

Oops. You set a goal and I missed it. Didn't mean to override you there. Got so involved in the details I missed the first sentence.

Change my last post to "I vote for this version."

Please follow your original plan.

Stan

**Brian Chirgwin** · 16 Jun 2008, 03:05 PM

My $0.02 cents

Originally posted by Rodney Hicks View Post

A first pass at some conventions and standards for the project. Could everyone please respond with agreement or disagreement by the item number on left by June 20?

Indenting.
1-- to 4-space boundaries please.

I use 3 spaces, but can be retrained to use 4.

Declaring Variables
2-- At the top of the SUB or FUNCTION. not inline.

I think this makes sense accept, of course, for redim arrays.

In some languages the following code will not create the variable (set space aside) until the variable dim statement is reached. In other words, 100K would be set aside only if the condition was true. This is doesn't seem to be true with PowerBASIC (at least not 8.04).

Code:

      if <somecondition> then 
        local str as String * 100000
      end if

Underscore
3-- Could we make use of this for line continuation and file names only.(not in variable or function names)

I can agree to this as well except in the following cases:

private functions - I usually try to mark functions with a prefix (p__) when they should not be called outside the module
separating functions by module - I try to prefix functions with the module name (or alias) to prevent functioname collision. It is difficult to tell what the module name ends and the function name begins. i.e. parserFunctionname vs parser_Functionname where the filename is parser.bas.

.

Variable naming
4a-- "modified Hungarian Notation"
b-- meaningful names, don't be afraid to comment if possibly confusing
c-- data type prepended to meaningful name made up of words with initial letter capitalized.
d-- p prepended to that for pointers
eg:
local dwSQLiteArrayAddress as dword
local pszQueryResults() as asciz ptr

redim pszQueryResults(0 to lmax) at dwSQLiteArrayAddress

4a. I like using s for String, and n for Numeric. using dw or i for integer means the variable name must be changed in the type is changed. I was working in a VB3 to VB6 project where everything in VB3 was defined as iNumber, in VB6 these needed be changed to longs, and the variable names no longer contained the type of the variable and changing the variable name wasn't that easy. Knowing it is numeric is useful or string is useful. If I need to know the exact numeric type, I can find the dim statement. Just my opinion and I am willing to do either. By the way, Microsoft made this change to there standard for the same reason.

Globals

Chris>>
6-- Having skimmed Stan's ToDoList, I also picked up an item "Use of Global Vars" under "Coding Conventions". This is one that deserves to be expanded into "Use of Global and Static variables as an alternative to dynamic memory allocation".

In my opinion, the use of Globals etc should be kept to a minimum and a reasonable case made for the use of globals at peer review level - in other words, although they are to be avoided, I don't think that they are inexcusable. An exception would be when writing a small supporting application, in which case, who cares.
<<

While there is a school of thought that thinks, believes, demands Globals should be avoided at all costs, I am not a member of that school.Admittedly, a project of this size might give me pause. However, Globals are a tool in the toolbox. I too, urge judicious use.

I recommend globals be prefixed with gMODULENAME. For example,

global gParserErrorMsg as String

Parser is the module Parser.bas. This will prevent duplicate globals from becoming an issue.

I don't think globals should be used to avoid dynamic structures. Globals have issues. Globals also should not be used as an alternative to passing parameters to a function. Pass the parameter to avoid using a global.

FUNCTION names
7a-- Meaningful (in English).
b-- parameters listed one per line with line continuation character(underscore) to leave room for verbose(if needed) comments.
c-- Immediately following parameters a description of the function's purpose. I also suggest programmer's initials and date. All commented out, of course.
d-- Use visual separators

7a Agree. We should probably develop a cheat sheet of common names that should be used. i.e.

7b. Usually don't, but makes sense.
7c. Disagree, sort of, the function name should be enough to describe it. A short sentence I don't want paragraphs of text. I worked with someone who wrote a page (printed page) of text for each line of code. Then when he modified the code he didn't update his comments. They quickly became useless and trying to find code in the comments destroyed productivity. Although I agree some comments are required, they should be used only when the code might be mistaken.

If you are putting comments inline to indicate what a section of code does, break it out to a function and use a function name for the comment. This is an indication that the function is doing to much.

7d. I assume you mean separator between Functions and not _ between Function name words.

FUNCTION prototypes
- I'm off the beaten track here. I only use them for exposed functions. <<Chris
8-- Other functions are ordered in the source code so that prototypes are not essential to compilation. <<Chris me too

Agree where possible.

FILES
VB source files
9a-- Begin all filenames with VB_
b-- Use VB standard extensions
eg:
VB_testgrphx.frm
c-- I'm not so sure that the VB source files have to be named in stringent fashion, unless they are files produced expressly for this project.

I can go either way. VB project will be in its own subdirectory see http://www.powerbasic.com/support/pb...ad.php?t=37653

Code:

        [B]PB source files[/B]
10a--             Begin all filenames with PB_vb2pb_
  b--             Include concise descriptive term up to 8 letters PB_vb2pb_whatever.
  c--            Include date of submission in name PB_vb2pb_YYYYMMDD ( Use the YYYYMMDD format so the highest number is always the latest)
  d--             Include Programmer's Initials as last two characters of filename
  e--             Use extensions as supplied by the PB IDE.

                I suggest the date and programmer information because at this early stage I already have four different files named vb2pb.bas on                    my computer.

10a. Drop the PB_ prefix. I don't think this is necessary.
10b. vb2pb_ Fine, but a lot of characters used for limited purpose as all files will begin with vb2pb. The vb2pb source will not have any files not related to the source (or am I mistaken).
10c. This can be included on code that is sent in via email. Anyone perfoming a commit of source via SVN, the source will be automatically dated.
10d. Again this data will be in SVN.

Additional info:
Since PB doesn't have Public/Private functions/subs, I recommend that functions that should not be called begin with some prefix (maybe p__ two underscores). A module such as Parser.bas will have a public interface and private functions that are used internally only.

[CODE]
Generated source files.
11a-- For the project purposes that the converter generate a name that include the date in the above format followed by an underscore character and then some identification of the version iteration.

b-- That the release version of the CONVERTER defaults to the name of the VB source, with an option to change as the user sees fit.

c-- I have not broached the subjects of DLLs, INCs, or Resource files at this time, still open to suggestions.

[/quote]

I think it makes more sense to put comments at the begining of each converted file as to the version that created it. Options used, version, etc...

I don't see a benefit in having filenames have a suffix of the version that created it. If you are using a new version, it should replace the version you have, not create a new version of the file. If a new filename is created then the PB includes need to be modified to refer to the new filename.
i. e. #include "<filename>I1.bas" to #include <filename>i2.bas.
If you want to keep copies of created source for each iteration, change the output directory. i.e. \iteration1\, \iteration2\. Keep the filenames the same under each directory.

**Rodney Hicks** · 17 Jun 2008, 02:03 AM

Brian, thanks for responding.

1. INDENTS
Chris and I both thought 4, I because it would be more clearly seen. I personally use 2 space indents, but with so many diverse people(more than 1) a little extra seems advisable.

3. UNDERSCORE
I threw this in there because for some reason those_ _ _ _ things throw me off my game. We will go with what the majority prefers.

4a VARIABLE NAMING
Again, because of the group concept instead of just me concept. The more info we give the less confusing, although I know it can work against us.

6 GLOBALS
While some have issues with globals, I think that we should keep the tool but be careful with it. I don't think were too far apart on this. We'll have to name them well though.

7a FUNCTION NAMES
That cheat sheet is a good idea, once I've done some of the other chores I'll do something about it if no one else has.(although it probably should be done earlier)

7c Part of the reason for the programmers initials and date near the top of all functions is the group nature.
I fully believe that somewhere along the way we'll be grabbing the wrong function because of name similarity, and a little extra info might help. Another thing is, I'm not too sure what is going to happen to the source code for the release version of this project, and an in source paper trail might be handy.
On the other hand with your code control it may not be an issue, so I've tried to cover all bases.

7d Example
***************************************************

Re the source code naming conventions.
This issue may not be an issue once we're using you're system.
Like I said, it is already an issue with me on my computer, and it sure would be nice just to look at the filename and know I've got the right one. I don't quite see why you think the include files would have to change. I'm operating under the assumption that an include file won't be an include file until it's complete. It is also part of the reason that the conventions listed did not apply to it(my assumption may be way off base). This naming convention was only for the main file, from each programmer.

However, there is also the possibility of just using a serial number, sort of like the upgrades for Vista. This too might require some other changes. Floating ideas here.

I have this sneaking suspicion that there's gonna be an awful lot of files.

Rod

**Fred Harris** · 18 Jun 2008, 12:11 PM

underscores?

Underscore
3-- Could we make use of this for line continuation and file names only.(not in variable or function names)

Rodney, please don't take my underscores away! I love them!

I will admit when I first met them long ago I took a very dim view of them. But over the years I first got used to them, then got to like them. When object oriented language code such as VB or C++ code is converted to procedural code, the underscore idiom of first specifying the object, then an underscore, then some modality of the object is often encountered. In my opinion it is clearer than running piles of words together. Any opinions?

**Rodney Hicks** · 18 Jun 2008, 12:43 PM

I have this feeling that free use of the underscore might be in order.

Rod

**StanHelton** · 18 Jun 2008, 07:52 PM

Originally posted by Rodney Hicks View Post

I have this feeling that free use of the underscore might be in order.

Rod

**Rodney Hicks** · 19 Jun 2008, 08:48 AM

Gentlemen
I need some standard to continue this process. The following 'code' is pretty much useless because it assigns literals to literals. It makes for quick reference only and it would be nice if I only had to do all of this once.
It would be nice if what I was doing could be absorbed right into the code, no?
That said, how do we want to access the list of words, which is going to get a lot bigger yet.

Most common used first, simplest terms first, etc. ??
A two dimension array?
Any ideas.

Code:

'OPTION, END, EXIT, ON will need an addon I think.




'VBSTATEMENTS                        PBSTATEMENTS
'*************************************************************************************************************************
'"AppActivate"  =                    "VB AppActivate code not supplied."
"BEEP"         =                    "BEEP"
"CALL"         =                    "CALL"
"CHDIR"        =                    "CHDIR"
"CHDRIVE"      =                    "CHDRIVE"
"CLOSE"        =                    "CLOSE"                            ' pb does more
'"CONST"        =                    "CONST function/sub required"
"DEFINT"       =                    "DEFINT"
"DEFLNG"       =                    "DEFLNG"
"DEFCUR"       =                    "DEFCUR"
"DEFSNG"       =                    "DEFSNG"
"DEFDBL"       =                    "DEFDBL"
'"DEFDEC"       =                     "DEFDEC function/sub required"
'"DEFDATE"      =                     "DEFDATE function/sub required"
"DEFSTR"       =                    "DEFSTR"
'"DEFOBJ"       =                    "DEFOBJ function/sub required"
'"DEFVAR"       =                    "DEFVAR function/sub required"
'"DIM"          =                    "DIM function/sub required"      'caution on this one, module and procedural levels
'"DO"           =                    "DO"                             'need supporting RESERVED words before using in project
'"LOOP"         =                    "LOOP"                           'need supporting RESERVED words before using in project
'"END"          =                    "END"                            'PB END does not support Property, Type, or With
'"ENUM"         =                    "VB Enum code not supplied"
"ERASE"        =                    "ERASE"                           'first ensure array type.watch for objects etc.
"ERROR"        =                    "ERROR"
'"EVENT"        =                    "VB Event code not supplied"
'"EXIT"         =                    "EXIT"                           'VB  does not Exit SELECT,
'"EXIT Property"=                    "VB EXIT Property code not supplied"
"FILECOPY"     =                    "FILECOPY"
'"FOR EACH"     =                    "VB FOR EACH function/sub required"
"FOR"          =                    "FOR"
"NEXT"         =                    "NEXT"                            'step must be in the range of counter type
"FUNCTION"     =                    "FUNCTION"                        'this may have to serve as a flag for function analysis
"GET"          =                    "GET"                             'needs in depth scrutiny
"GOSUB"        =                    "GOSUB"
"RETURN"       =                    "RETURN"
"GOTO"         =                    "GOTO"
"IF"           =                    "IF"
"ELSE"         =                    "ELSE"
"ELSEIF"       =                    "ELSEIF"                          'didn't find this in ref. mat, but is in examples
"END IF"       =                    "END IF"
'"IMPLEMENTS"   =                     " VB IMPLEMENTS code not supplied"
"INPUT #"      =                    "INPUT #"                         'more to PB statement
"KILL"         =                    "KILL"
"LET"          =                    "LET"                             'optional in both languages
"LINE INPUT #" =                    "LINE INPUT #"
'"LOAD"         =                    "VB LOAD function/sub required"
"LOCK"         =                    "LOCK"
"UNLOCK"       =                    "UNLOCK"
"LSET"         =                    "LSET"                             'VB version can't be used with UDTs
"MID"          =                    "MID$"                             'PB MID$ allows neg. length of replacement
"MKDIR"        =                    "MKDIR"
"NAME"         =                    "NAME"
"ON ERROR"     =                    "ON ERROR"                         'see SUB/FUNCTION in header
'"ON"           =                    "ON"                              'for use with GOSUB and GOTO
'"GOSUB"        =
'"GOTO"         =
"OPEN"         =                    "OPEN"                             'PB open can have 1 more parameter
"OPTION BASE"  =                    "'OPTION BASE NOT APPLICABLE"      'set up this way due to its rarity
'"OPTION COMPARE"=                    " VB OPTION COMPARE sub/function required"
"OPTION EXPLICIT"=                    "OPTION EXPLICIT"                'if not present expect variants
'"OPTION PRIVATE"=                   "VB OPTION PRIVATE needs scrutiny"
"PRINT #"      =                    "PRINT #"
'"PRIVATE"      =                    "VB PRIVATE function/sub required"
'"PROPERTY GET" =                    "VB PROPERTY GET function/sub required"
'"PROPERTY LET" =                    "VB PROPERTY LET function/sub required"
'"PROPERTY SET" =                    "VB PROPERTY SET function/sub required"
'"PUBLIC"       =                    "VB PUBLIC function/sub required"
'"PUT"          =                    "PUT"                               'needs in dept scrutiny
'"RAISEVENT"    =                    "VB RAISEVENT function/sub required"
"RANDOMIZE"    =                    "RANDOMIZE"
"REDIM"        =                    "REDIM"
"REM"          =                    "REM"
"RESET"        =                    "RESET"
"RESUME"       =                    "RESUME"
"RMDIR"        =                    "RMDIR"
"RSET"         =                    "RSET"                                'VB version can't be used with UDTs
'"SAVEPICTURE"  =                    "VB SAVEPICTURE function/sub required"
'"SAVESETTING"  =                    "VB SAVESETTING function/sub required"
"SEEK"         =                    "SEEK"
"SELECT"       =                    "SELECT"
"CASE"         =                    "CASE"
'"SENDKEYS"     =                    "VB SENDKEYS function/sub required"
'"SET"          =                    "VB SET function/sub required"
"SETATTR"      =                    "SETATTR"
"STATIC"       =                    "STATIC"                              'VB usage may need scrutiny
'"STOP"         =                    "VB STOP not supported"
"SUB"          =                    "SUB"                                 'this may have to serve as a flag for sub analysis
"TIME"         =                    "TIME$"
'"TYPE"         =                    "VB TYPE function/sub required"
'"UNLOAD"       =                    "VB UNLOAD function/sub required"
"WHILE"        =                    "WHILE"
"WEND"         =                    "WEND"
'"WIDTH #"      =                    "VB WIDTH # function/sub required"
'"WITH"         =                    "VB WITH function/sub required"
"WRITE #"      =                    "WRITE #"

Rod

**Chris Holbrook** · 19 Jun 2008, 09:29 AM

Originally posted by Rodney Hicks View Post

That said, how do we want to access the list of words, which is going to get a lot bigger yet.
Most common used first, simplest terms first, etc. ??
A two dimension array?

The best way to access the array will be via a hash table, so don't worry about sequence. I have code for that too!

In use, you will need

the VB function name,
the PB function name(null if the same? does it matter?)
the CODEPTR to the translation function,
an index to an error message table?,
maybe a VB parameter count so that the parser can report apparent errors without calling the translation fn?

Any offers for more attributes?

**StanHelton** · 19 Jun 2008, 10:04 AM

Originally posted by Chris Holbrook View Post

...
In use, you will need

the VB function name,
the PB function name(null if the same? does it matter?)
the CODEPTR to the translation function,
an index to an error message table?,
maybe a VB parameter count so that the parser can report apparent errors without calling the translation fn?

Any offers for more attributes?

My personal wish list:

vbName
vbType -- relevant data type, scalar, array, object ref, class ref, & etc.
vbArguments -- usually will match pbArguments, but not always
vbPrototype -- generic if possible

pbEquivalent
pbPrototype -- generic if possible -- your CODEPTR to translator function, Chris

pbArguments

vb2pbErrorCodes

I'm trying to use something like this in an array of UDTs. Then Rod's .INC file could be used to load the array.

Thinking out loud again,
Stan

**Chris Holbrook** · 19 Jun 2008, 11:42 AM

Originally posted by StanHelton View Post

vbType -- relevant data type, scalar, array, object ref, class ref, & etc.
pbArguments

where will these be used outside of the translation function?

**StanHelton** · 19 Jun 2008, 01:14 PM

Originally posted by Chris Holbrook View Post

where will these be used outside of the translation function?

vbType might be helpful when deciding which translator function to use, assuming there is a different translator function for each major vbType.

pbArguments could help a translator function know which other translator function to call when it finds an embedded vbType.

**Chris Holbrook** · 19 Jun 2008, 01:44 PM

Originally posted by StanHelton View Post

vbType might be helpful when deciding which translator function to use, assuming there is a different translator function for each major vbType.

pbArguments could help a translator function know which other translator function to call when it finds an embedded vbType.

Ah. I was thinking about one translation function per keyword, KISS principle.

**StanHelton** · 19 Jun 2008, 02:18 PM

Originally posted by Chris Holbrook View Post

Ah. I was thinking about one translation function per keyword, KISS principle.

The discussion you and Fred were having about terms got me thinking about this kind of thing:

someTermName.otherTermName

which could be an object call that will lead to embedded functions when translated to PB.

For example, the VB "Tab" is an object with the properties Caption, Image, ToolTipText, Tag, Index, and Key.

**Chris Holbrook** · 19 Jun 2008, 03:03 PM

Originally posted by StanHelton View Post

For example, the VB "Tab" is an object with the properties Caption, Image, ToolTipText, Tag, Index, and Key.

so you see the keyword table as being a subset of the symbol table?

**Fred Harris** · 19 Jun 2008, 04:35 PM

some ramblings

Just wanted to pass some random thoughts. Hash Table? Will we really need it? Are there enough terms that it will be desirable? Rodney is listing all the reserved words. What kind of numbers are we talking about here? By reserved words I'm thinking of things like "BEEP", CStr, Len, Mid, etc. I guess one might refer to these sorts of things as Verbs?

Objects are another catagory, e.g., Listbox, textbox, etc. For every object you'll have properties, methods and events. Just taking a wild stab at numbers lets say an average of 50 properties for each object - plus or minus 25 depending on the object.

Believe it or not, I just decided to see if my 'off the top of my head' guesses were in order, so I opened my old VB reference to TextBox and there were EXACTLY 50 properties!!! There were 9 methods, and 17 events.

From the code I've written so far what seems to be the case is that many relatively small arrays holding all these goodies are what we need. In other words, program logic will determine for example that we are dealing with an assignment statement in which a text box is on the LHS (left-hand side!) and some kind of string or other on the RHS. One then finds out that the object call is to set the text property of the text box. All that is really needed is a small array to hold all the properties of a text box (50). It would be possible to have one large property array holding all the properties of every object, but why have to scan through an array holding 500 elements when you already are at a point in code where you know for absolute certin that you are dealing not with a listview control or a database but rather with a textbox and its 50 properties? Just a thought.

In terms of my early goal of first determining what general type of statement a program line is, i.e., assignment statement, use of reserved word, user function call, object method call -- well, "How many catagories do we really need?"

Should statements starting with a VB reserved word (verb?) be seperated out from Object Method calls? If there isn't an assignment statement involved, all these are rather similiar in terms of handling...

lstVBConverterMembers.AddItem "Stan Helton", 0
Erase vbObj
Call frmName_btnClose_Click()

The 1st will resolve ultimately (for me the Sdk'er) to a SendMessage() call on the listbox to add an item.

The second is a procedure call that VB itself sets in motion. The last is an ordinary procedure call.

As things stand now the 1st and 3rd will be identified and found in the Symbol Table. The middle one in a list of reserved words.

Well, today was a hectic day for me. Didn't get as much time at this as I would have liked!