Considering a new FREE model for making EZGUI available to new customers

[George Bleck]

OK, took me a few re-reads to see the sought path there.

I'd expect some fairly complex forms of "features" could be designed, and putting that heavy work on the compiler to syntax check is unfair. Imagine someone implementing something similar to the OPEN command which could include optional sub-keywords like ACCESS, LOCK, HANDLE, CHAR, BASE, SHARED, READ, WRITE, (and READ WRITE!), BINARY, RANDOM, APPEND, INPUT, OUTPUT, etc. Too much for the compiler to deal with syntactically.

Although, I guess you could so something like this...
.

#SUPPORT "MyLibrary OPEN $ [FOR (INPUT|OUTPUT|APPEND|BINARY|RANDOM)] ACCESS (READ|WRITE|READ WRITE) [LOCK (SHARED|WRITE|READ|READ WRITE)] AS #LONG [LEN = #LONG] [BASE = #LONG] [CHAR = (ANSI|WIDE)]"

• Where "$" specifies a user supplied text string
• "#" specifies a user supplied number (with type after)
• "[..]" blocks denote optional items
• "(...|...)" blocks specify arrays.

That said, I still see no reason #UTILITY cannot do it. Just need the pre-processor to do the syntax checking based on it's own set of rules and it flags the errors before calling the compiler.

Although, in the end, the compiler does not actually compile 3rd-Party library calls of that type, so it is moot. Code calls must be in sub/function parameter list calling format, or as an object method/property. Unless of course your pre-processor is re-organizing your calls into a format the compiler can actually compile. But that puts us right back to let your pre-processor do all the syntax checking. The sky is the limit however YOU want to implement a calling structure, as long as your pre-processor can syntax check and then reformat things to the standard function/object call format that is compilable.

[Brian Alvarez]

Too much for the compiler to deal with syntactically.

Not really. PowerBASIC is already doing this internally with hard coded syntaxes for the statements, all i did was (one layer above as Eric said), make this accessible to the programmer. It was quite easy and not much overhead was added, if any. What i do is to add an intermediary DLL as if it was PBWIN.EXE, which pre-processes the source code, and it then internally invokes PBWIN.EXE to compile the source code seamlessly, you barely ever notice something happens differently.

Although, I guess you could so something like this...
.

#SUPPORT "MyLibrary OPEN $ [FOR (INPUT|OUTPUT|APPEND|BINARY|RANDOM)] ACCESS (READ|WRITE|READ WRITE) [LOCK (SHARED|WRITE|READ|READ WRITE)] AS #LONG [LEN = #LONG] [BASE = #LONG] [CHAR = (ANSI|WIDE)]"

• Where "$" specifies a user supplied text string
• "#" specifies a user supplied number (with type after)
• "[..]" blocks denote optional items
• "(...|...)" blocks specify arrays.

If you want to add a new OPEN statement, or add more switches to the current one, it is quite doable as is it now, and PowerBASIC compiles the code as always. There are currently a few dozen symbols that tell the engine to expect something or something else, this allows for a wide variety of statements. For example, adding E to the syntax, it means the statement can alter the ERR, and ERL and "report" an error happened... adding an R means the statement expects a variable of the RECt data-type, etc.

That said, I still see no reason #UTILITY cannot do it. Just need the pre-processor to do the syntax checking based on it's own set of rules and it flags the errors before calling the compiler.

A statement done with #UTILITY (and parsed separately) would need to be re-tokenized and figure datatypes separately, parse classes, types, global variables, local variables... etc, to determine a correct data type for each part of the statement. Simply UDT variables would be a gruesome task... but by telling the engine to treat the statement as any other native statement all this is not necesary. Try doing an example with #UTILITY and you will soon find is not as easy. My statement is "declared" once... and then you use the statement as many times as you want without the need to wite #UTILITY for each one. In fact you may not ever notice a difference between a native statement and a statement declared this way.

Although, in the end, the compiler does not actually compile 3rd-Party library calls of that type, so it is moot. Code calls must be in sub/function parameter list calling format, or as an object method/property. Unless of course your pre-processor is re-organizing your calls into a format the compiler can actually compile. But that puts us right back to let your pre-processor do all the syntax checking. The sky is the limit however YOU want to implement a calling structure, as long as your pre-processor can syntax check and then reformat things to the standard function/object call format that is compilable.

Which, in the end is exactly why i did it, and how i did it.

By the way, Sorry Chris, i dont want to hijack this thread... I just thought it was interesting and fun to allow 3rd party developers to extend the statement repertoire.