Commander X16

On 9/30/2020 at 10:07 PM, desertfish said:

 



Maybe the subroutine calling convention can be improved.  The return value is now always processed via the evaluation stack which is not optimal and subroutines cannot be reentrant because they have static allocation of their parameters rather than a new stack frame for each call , but I don't consider the latter a real problem on 6502 machines. Just write a loop instead of recursion.

22 hours ago, desertfish said:

I don't have a  preference for one or the other simply due to the fact that I am not knowledgeable enough about parser generators to know the differences ?



How would Prog8's grammar look like in a LALR 1 definition?   (as compared to the current prog8.g4 spec)   Why would it be preferable?



I've chosen Antlr because that looked to be a high performance, well supported, and broadly used parser generator for Java (and thus, Kotlin).  I'm open for alternative better solutions though.   The parser is in its own project, so you could make another one next to it. The biggest effort would be the mapping into the Ast nodes that the rest of the compiler uses. And perhaps dealing with parser errors.

Quote

 



LL or LR?

This question has already been answered much better by someone else, so I'm just quoting his news message in full here:



I hope this doesn't start a war...



First - - Frank, if you see this, don't shoot me.  (My boss is Frank DeRemer, the creator of LALR parsing...)



(I borrowed this summary from Fischer&LeBlanc's "Crafting a Compiler")



  Simplicity    - - LL

  Generality    - - LALR

  Actions       - - LL

  Error repair  - - LL

  Table sizes   - - LL

  Parsing speed - - comparable (me: and tool-dependent)



Simplicity - - LL wins

==========

The workings of an LL parser are much simpler.  And, if you have to

debug a parser, looking at a recursive-descent parser (a common way to

program an LL parser) is much simpler than the tables of a LALR parser.



Generality - - LALR wins

==========

For ease of specification, LALR wins hands down.  The big

difference here between LL and (LA)LR is that in an LL grammar you must

left-factor rules and remove left recursion.



Left factoring is necessary because LL parsing requires selecting an

alternative based on a fixed number of input tokens.



Left recursion is problematic because a lookahead token of a rule is

always in the lookahead token on that same rule.  (Everything in set A

is in set A...)  This causes the rule to recurse forever and ever and

ever and ever...



To see ways to convert LALR grammars to LL grammars, take a look at my

page on it:

  http://www.jguru.com/thetick/articles/lalrtoll.html



Many languages already have LALR grammars available, so you'd have to

translate.  If the language _doesn't_ have a grammar available, then I'd

say it's not really any harder to write a LL grammar from scratch.  (You

just have to be in the right "LL" mindset, which usually involves

watching 8 hours of Dr. Who before writing the grammar...  I actually

prefer LL if you didn't know...)





Actions - - LL wins

=======

In an LL parser you can place actions anywhere you want without

introducing a conflict



Error repair - - LL wins

============

LL parsers have much better context information (they are top-down

parsers) and therefore can help much more in repairing an error, not to

mention reporting errors.



Table sizes - - LL

===========

Assuming you write a table-driven LL parser, its tables are nearly half

the size.  (To be fair, there are ways to optimize LALR tables to make

them smaller, so I think this one washes...)



Parsing speed - comparable (me: and tool-dependent)



--Scott Stanchfield in article <33C1BDB9.FC6D86D3@scruz.net> on comp.lang.java.softwaretools Mon, 07 Jul 1997.



 

2 hours ago, geek504 said:

I could not find something specifically for Kotlin, and I didn't spend too much time trying to figure out the Java/Kotlin integration.

On 10/9/2020 at 6:57 PM, geek504 said:

After checking out most lexers/parsers it seems to me that Lark is the sweetest thing since apple pie!