[antlr-interest] C# Target Poll

[Johannes Luber]

> At 11:27 17/05/2008, Johannes Luber wrote:
>  >My motivation to consider C5 is simply that I prefer to use
>  >state-of-the-art tools, and to a certain extent .NET falls 
> short. I
>  >have used it in a few projects so far and will use it again. It 
> is
>  >easy to use. I had no problems besides non-binary-serializing of 
> a
>  >dictionary, which was caused by .NET bugs, so I wouldn't hold 
> that
>  >against C5. Also, serializing seems to be an unusual need for
>  >compilers anyway and can be circumvented by own designs anyway, 
> as
>  >it probably would have been anyway. Please correct if I'm wrong 
> and
>  >C5 would prevent doing from something what you can do now.
> 
> What direct improvement/extra features does it provide (for the 
> purposes of the ANTLR runtime) that the standard .NET classes do 
> not?  What is the advantage in using it, given the penalty of 
> adding an additional assembly?

Looking at the sources, the only used .NET collections seem to be ArrayList and Hashtable. While I didn't create those files I believe it safe to assume that ANTLR itself doesn't require now more features. On the other hand we have an own implementation of a StackList, which is adding Push()/Pop() to ArrayList. C5's own ArrayList has it inbuilt. Then there is Hashlist which doesn't seem to have an equivalent in C5, so it has to be included anyway.

Problematic may be future requirements by mimicking the Java runtime, but that is driven by Ter and thus quite unsure. But there are some collections available in the Java runtime and not in .NET natively, so this issue can arise anytime (as it nearly did once two weeks ago). Having a more powerful collection library is insurance for this case. Still the main benefit would be that no translation from ANTLR objects to C5 collections are necessary by the users.

This requires that enough people do use C5 instead other options. Micheal points out in another email that C5 is no natural extension of BCL classes. One of the design goals was to introduce more orthogonality than the BCL classes have, so I won't disagree with him. In fact that novel design was attracting me to C5. I suppose that is something what other people can argue about - adhering to the broken designs because they are always available and familiar or starting fresh anew.

Looking at potential new functionality from the PowerCollections, I am a bit disappointed of the choices offered. Furthermore, there is no new development done. Is this because it is well-polished software or don't want people maintain this software? Considering that Micheal offered himself a problem with the PowerCollections I'm wondering about its future. C5 is still actively maintained, though.

When I was asking about your opinions, I was well aware of this issue. But that people actually require a leaner option than what is already delivered surprises me. Don't they know about the Mono linker, which can distill only the required functionality of included assemblies? Or is that impractical? In the latter case, inclusion of C5 may be not a good idea.
> 
> Bear in mind that the CSharp target can't use it anyway (as that's 
> still v1-compatible), so by using it you'd create a much larger 
> difference between CSharp and CSharp2.  And probably add to the 
> maintenance cost.

Well, for ANTLR 3.2 I have to split the runtimes anyway. Not only I can change the directory structure a bit (the current one doesn't sit well with me, but I have to look into possibly alternatives first), but I can use in interfaces generics as well. Currently the interfaces conform to .NET 1.1, so the templates work with same code. Splitting the runtimes allows me to limit the .NET 1.1 stuff into one place and with 3.3 I can simply delete the old stuff.
 
> (Also, you've referred to ANTLR-generated parsers as 'compilers' 
> at least twice now.  While that's indeed a common usage, they're 
> also used to parse data structures, so they're not *always* 
> 'compilers'.  Doesn't make much difference to the serialisation 
> case, except that it's possible someone might want to serialise an 
> AST.  It's probably more likely they'll serialise something else 
> generated from the AST/parse, but you never know.)

Well, for serializing there are prebuild solutions, as a Google search shows. I don't believe that this issue is a deathblow anymore, considering that even the in-built dictionary can't be serialized with XML, IIRC.

Johannes
-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser