[nem-en] Re: COM controls on WinForms?

[Kamil Skalski]

On Fri, 4 Mar 2005 15:36:37 -0600, Greg Fitzgerald <garious at gmail.com> wrote:
> That's cool, maybe it's about time I start looking at Nemerle more again.
> 
> I remember you guys talking about rewriting the parser a while back,
>  How's that coming?

Yes, the new parser is already implemented. For now it gave us more
elegance in most of its
parts, better error recovery, and some features for future implementation:
- it's no longer a LL(k) parser in its core definition - it matches
braces () { } [] first, so it can lookup after the [] and then decide
how to parse its contents
- preparsing braces gives very flexible way for deferring parsing, I
will soon implement extension to our syntax extending engine ;-) which
will allow parts of source code (contents of
braces or tokens between separators [,;]) to be parsed by a macro.
This will give us ability to embedd DSLs VERY easily:
def x = xml <bam>4 </bum>;
foreach (x in select * from Users where Users.x > 5) {  ... }

I will be writing some description after I implement it.

> but I haven't seen any activity on the list or webpage in a long time.

Lately we were doing mostly bugfixes. But Michal is finishing the new
typing engine and after that we will have fresh release with many new
features.

> 
> Do you feel the Nemerle parser is better than antlr?  If so, what makes it so?

These are two different things. How antlr is better:
- it is grammar based, which nemerle syntax extensions won't be in
reasonable future (but I don't say no), which gived very good
expressiveness and flexibility
- it is a general parser generator, which have a little connection
with parser of one, single language
- it allows you to build completely new language, where nemerle syntax
extensions allows extending only parts of its grammar

how is it worse:
- adding arbitrary syntax by linking to new macro library
- in Nemerle syntax extensions are loaded dynamically by importing namespaces:
   using MyExtensions;
    ... here some new keywords and rules are loaded
  namespace SomeMoreExts { 
    ... other ones
  }
  ... unload those from inside of namespace .. { }
  
  ok, it probably can be achieved for fixed set of new productions by
adding dynamic checks in antlr productions

- the parsing deffering which I mentioned
- error recovery

Of course all these comparisons are a little bit pointless - we use
handwritten parser to have the greatest flexibility in parsing
process, syntax extensions, etc. and we are fine with it, because it
is a parser for this fixed language. antlr as is, it a really great
tool, but for different
purposes.
Some long time ago we used parser generator jay (from mcs), but we had
continuous problems with conflicts, etc.

-- 
Kamil Skalski
http://nazgul.omega.pl