Hi William,

> Just tried out the Antlrworks 'debugger', and I'm impressed!  I need
> to figure out what are the most useful things to 'break' on -- I
> checked the 'all' box and got tired clicking the mouse so much. :-)

I use 'consume' but do not run whole files, just code parts that are
not parsed according to my expectations. When it is a larger code
block, you could just jump to the end and look at the parser and ast
(which are impressive too!). Then remove parts that are not relevant
and step through the smaller code blocks.

> It was cool watching it step thru one of my CANbus JAL libraries!
I imagine it is!
And btw, is CANbus related to your tractor problem? ;)

> I learned something new today:  'pling' is another name for the
> exclamation point.  I've always heard it called 'bang' or 'bang sign'.
> But I think I will learn to like 'pling'. :-)
Nice to surprise a native English speaker :) I prefere the sound of
pling over bang and 'exclamation mark' is just impractical long.

> Joep: I'm not sure if 'qualitly_expr' should be 'quality_expr' ?
> Please advise.
I'm sure you are just polite and know 'qualitly' is wrong ;) I changed
it to 'equality', to conform (to a certain level) to the C example
grammar.

With the grammar complete, I started thinking about gode generation
and, as a result, about compatability.
First of all, there are a few issues with JAL grammar that are make it
more difficult to process. E.g. calling a function without parenthesis
will not be recognised as such and the include name without quotes or
other separator does require a hack (and that's undoubtable the reason
you have to put the filename at the same line - a requirement that is
uncommon in JAL).

But there are also other issues. What happens if you have 'for 8 using
x loop' and modify x in the loop? This is not documented. You could of
course determine what happens in the current compiler version with a
given target PIC. But that does not assure it works the same for an
other PIC (family) or newer compiler versions.

And last but not least, we need a way to add code that is copied to
the c-source (like include statements and directives that don't have a
JAL equivalent) and maybe even instructions to the parser.

Anyway, I started with 'code generator' functions (don't know if that
is a good name - suggestions are welcome), that walk the AST and emit
text that will become compilable c-code. And although complete JAL
support is still a long way, first expressions with variable types
that are available in C are visible at the horizon ;)

Joep

-- 
You received this message because you are subscribed to the Google Groups 
"jallib" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/jallib?hl=en.

Reply via email to