Compiler improvement suggestion 1

[stevech]

Compiler should ignore white space after an underscore for line continuation. If present, it causes a syntax parser error.

Compiler should ignore comments after an underscore for line continuation. If present, it causes a syntax parser error.

example:

const a as byte = 1, _ ' some comment
b as byte = 2, _ <space character here>
c as byte = 3

[dkinzer]

I agree that both of these would be nice additions. I believe that allowing whitespace following the continuation underscore can be implemented by simply stripping all whitespace from the end of each source line immediately after it is read in.

On the other hand, allowing a comment to follow is not so simple. The problem is one of determining in the lexical analyzer where a comment begins. It is a false assertion that the presence of an apostrophe indicates the presence of comment inasmuch as an apostrophe may appear in a quoted string. It might be possible to implement this by performing a complete lexical scan on a line right after it is read in to determine if it ends with a comment and, if so, strip it off. After this first pass, tokenizing could commence as it does now.

It is interesting to note that VB6 does not allow a comment after a line continuation underscore, perhaps for the reason cited above.

[stevech]

Hmmm, I thought VB6 allowed comments after the underscore but I stand corrected.

this topic came up since I, as a noob, am starting to figure out how best to code a list of constants used as indicies into an array, in lieu of the ability to have structures (this code is rejected):

const _
xalpha as byte = 0, _ ' comment about alpha
xbeta as byte = 1, _ ' comment about beta
xdelta as byte = 2

const xalphabetadeltaSIZE as byte = xdelta + 1

dim greekStuff(xalphabetadeltaSIZE) as byte ' this is a semi-structure with three constants to refer to "members" or array elements

-------
Maybe there's a cleaner work-around for the lack of structures in ZBasic? Perhaps I missed something better in the language.

[dkinzer]

Although it is not as clean as using structures (no type checking, etc.) you can make use of aliases to partition an array of bytes into various elements with the same or different types. For example:

[stevech]

hmm. Thanks for "alias" idea.


I thought I could put declarations of variables in a .bas file that is NOT part of the project's files. Call this "greekStuff.bas".

Then I create two modules
greekStuff1.bas
which merely does a #include "greekStuff.bas"

and another called
greekStuff2.bas
which also does a #include "greekStuff.bas"

as if I typed this three times into separate modules.
Two "instances" of the same storage declarations, in separate modules.

But alas, ZBasic won't allow the greekStuff.bas to be #included twice. Seems like it should be legal. I get:

GreekStuff1.bas:2: Error: duplicate module "GreekStuff", file "GreekStuff.bas"

[dkinzer]

I don't fully understand your objective so it's difficult to recommend someting that might help.

It is true that including a file is the same as having it be part of your project.

[stevech]

simplifying...

In, say, main(), I could code as follows, using ZBasic's scope rules:

module1.alpha = 1
module2.alpha = 2

---------------

moduleX has public storage definitions in it, as if it were a structure definition. It is NOT in the project's files.

module1 has an #include moduleX.bas i.e., it's an instance of the structure
module2 has an #include moduleX.bas

But there are two reasons why this doesn't work: (a) can't include twice (why?), (b) included code doesn't seem to take on the modules' scope rules.

[dkinzer]

[stevech]

thanks. I understand: if A includes B, then the module identity for code within B is B, not A. Seems like it ought to be the other way 'round though.

[dkinzer]