BlitzMax Grammar
BlitzMax Forums/BlitzMax Programming/BlitzMax Grammar
| ||
| Hello! It seems as though there's always a few BlitzMax language features that each person, except maybe the luminaries, don't know (for example, $w or @ type tags, line continuation "..", etc.) And it may take a good amount of trial and error to find exactly how to use a given feature acceptably. The best thing would be a detailed language reference, but assuming no one wants to take the time to write this and keep it updated, something that would be very useful is for BRL to just release the language grammar for BlitzMax. A language grammar isn't exactly a trade secret, and is usually a part of language documentation (here are the grammars of Java, C#, and C, in a variety of formats) http://java.sun.com/docs/books/jls/second_edition/html/syntax.doc.html http://msdn.microsoft.com/en-us/library/aa664812(VS.71).aspx http://www.quut.com/c/ANSI-C-grammar-y.html Do you think this might be a possibility? ~Jesse |
| ||
| I've actually started to write one a couple of times, but there are some complications with function pointers. I remember concluding that a context free grammar isn't possible to describe the full language, but that an additional symbol table is required to distinguish between different forms of function calls. I might be wrong though. Anyway, a grammar would definitely be nice for e.g. source highlighting. |
| ||
| an additional symbol table is required to distinguish between different forms of function calls Eh? |
| ||
| Here's a few more notes after quick scan of latest Language docs: - Functions chapter omits fact that brackets are optional for invokers that ignore return value, which is what makes good blitzmax code sexiest in town - tilde escape sequence is incorrect - bullet lists all have formatting issues as does first paragraph of user defined types chapter - modules is missing a docmods section - alphabetical ordering of chapters is not logical, add numeric prefix to Language chapters? - interfacing with C chapter omits $z and $w discussion The optional brackets and the rules for extern vs standard function declarations could be a bit of a problem for a correct grammatical definition of the language. |
| ||
| Eh? Without knowing the type of an identifier it is sometimes impossible to know if the code is a cast or a function call. Even here: a(b) Without knowing what a and b stand for (are they type names, functions/function pointers or variables; what their data type is) it is impossible to say what this expression stands for. It becomes more complicated with nested casts/calls, but that's the basic problem. |
   |