The Sinclair QL Forum

Hi Folks,

By 'grammar' I suspect you all mean syntax 'railway line' graphs, as defined for example in Jan Jones' handbook.
This will allow however strange legal programs like the very short : 100 ELSE

But try mixing lines of SELects with IFs and ELSEs in disorder, and you may find very unexpected though often legal results !

I imagine everyone is looking for a common playing field of syntax error reporting for all QL systems. This has yet to be defined !

One simple solution to backward compatibility is to adapt all programs to run on 128ko JS QLs, memory permitting...

No system is perfect though... and we already have a lot to be thankful for the interpretive sytems we have at our disposal. ( Eg: JavaScript Compilers = ouch !! )

Steve.

stevepoole wrote:By 'grammar' I suspect you all mean syntax 'railway line' graphs, as defined for example in Jan Jones' handbook.

I tend to use Backus Naur Form (BNF) to specify a grammar though it's an old format that may not be as common as the inline mechanism used by lex/yacc, antlr and the like. Syntax diagrams are more of a visual representation of BNF which I personally don't find as useful. There is also a more formal specification that takes on the form:

S -> Ab
A -> AC
A -> a
C -> c

When the point is to understand more about the structure of a language than its meaning. The four types of grammars in Chomsky's Hierarchy use this more formal approach to describe their meaning (i.e. to differentiate between recursive enumerable vs context-sensitive vs context-free vs regular). Grammars are a fun computer science topic and allow for lots of ways to categorize language parsing.

stevepoole wrote: This will allow however strange legal programs like the very short : 100 ELSE

A well defined grammar would not allow a dangling else but of course there are no rules in when someone writes their own grammar so they can do what they like. Grammars is just a nice concise way to capture how a language should parse. When using language construction tools like lex/yacc or antlr, you are forced to write the grammar first and then fill in its construction of the parse tree. When writing a parser yourself (i.e. generally a recursive descent parser) then you are on your own. When I write my own (i.e. I don't use a tool) I usually have the grammar specification that I first wrote, open in a document, and then keep cutting away each line of the grammar and using it as a comment as to where it is being implemented in the code. That way I stay on track with what I want the language to do.