August 26, 2008
BCS wrote:
> Reply to Benji,
> 
>> I've used ANTLR a few times. It's nice.
>>
> 
> I've used it. If you gave me the choice of sitting in a cardboard small box all day or using it again, I'll sit in the cardboard box because I fit in that box better.

I've always been impressed by the capabilities of ANTLR. The ANTLRWorks IDE is a very cool way to develop and debug grammars, and Terrence Parr is one of those people that pushes the research into interesting new areas (he wrote something a few months ago about simplifying the deeply-recursive Expression grammar common in most languages that I found very insightful).

The architecture is pretty cool too. Text input in consumed and AST's are constructed using token grammars, which are then transformed using tree-grammars, and code-generation is performed by output grammars. It's a very elegant system, and I've seen some example projects that used a sequence of those grammars to translate code between different programming languages. It's cool stuff.

So I appreciate ANTLR from that perspective. I think the theory behind the project is top-notch.

But the syntax sucks. Badly. The learning curve is waaaay too steep for me, so I've always had to keep the documentation close by. And once the grammars are written, they're hard to read and maintain.

Also, there's a strong bias in the ANLTR community toward ASTs. I prefer to construct a somewhat higher-level parse tree. For example: given the expression "1 + 2", I'd like the parser to construct a BinaryOperator node, with two Expression node children and an enum "operator" field of "PLUS". I'd like it to use a set of pre-defined "parse model" classes that I've written to represent the language elements.

It's hard to do that kind of thing in ANTLR, which usually just creates a "+" node with children of "1" and "2".

The majority of my parser-generator experience has been with JavaCC, which leaves model-generation to the user, which works better for me.

--benji
August 26, 2008
superdan wrote:
> tho to be brutally honest listenin' more an' talkin' less always helps

LOL

Coming from you, dan, that's my favorite ironic quote of the day :)

--benji
August 26, 2008
Reply to Benji,

> BCS wrote:
> 
>> Reply to Benji,
>> 
>>> I've used ANTLR a few times. It's nice.
>>> 
>> I've used it. If you gave me the choice of sitting in a cardboard
>> small box all day or using it again, I'll sit in the cardboard box
>> because I fit in that box better.
>> 
> I've always been impressed by the capabilities of ANTLR. The
> ANTLRWorks IDE is a very cool way to develop and debug grammars, and
> Terrence Parr is one of those people that pushes the research into
> interesting new areas (he wrote something a few months ago about
> simplifying the deeply-recursive Expression grammar common in most
> languages that I found very insightful).
> 
> The architecture is pretty cool too. Text input in consumed and AST's
> are constructed using token grammars, which are then transformed using
> tree-grammars, and code-generation is performed by output grammars.
> It's a very elegant system, and I've seen some example projects that
> used a sequence of those grammars to translate code between different
> programming languages. It's cool stuff.
> 
> So I appreciate ANTLR from that perspective. I think the theory behind
> the project is top-notch.
> 
> But the syntax sucks. Badly. The learning curve is waaaay too steep
> for me, so I've always had to keep the documentation close by. And
> once the grammars are written, they're hard to read and maintain.
> 
> Also, there's a strong bias in the ANLTR community toward ASTs. I
> prefer to construct a somewhat higher-level parse tree. For example:
> given the expression "1 + 2", I'd like the parser to construct a
> BinaryOperator node, with two Expression node children and an enum
> "operator" field of "PLUS". I'd like it to use a set of pre-defined
> "parse model" classes that I've written to represent the language
> elements.
> 
> It's hard to do that kind of thing in ANTLR, which usually just
> creates a "+" node with children of "1" and "2".
> 
> The majority of my parser-generator experience has been with JavaCC,
> which leaves model-generation to the user, which works better for me.
> 
> --benji
> 

My feeling's exactly (or near enough)


August 26, 2008
Reply to superdan,

> BCS Wrote:
> 
>> Reply to Benji,
>> 
>>> I've used ANTLR a few times. It's nice.
>>> 
>> I've used it. If you gave me the choice of sitting in a cardboard
>> small box all day or using it again, I'll sit in the cardboard box
>> because I fit in that box better.
>> 
> i've used it too eh. u gotta be talking about a pretty charmin' cozy
> box there. the effin' mcmansion of boxes in fact. coz antlr is one of
> the best if not the best period.
> 

The above is intended as a pun, "I don't fit in the ANTLR box". It's like MS Word, as long as you do it the way things are intended to be done, clear sailing, as soon as you try something else rocks and shoals. 

My other main issue I have had with ANTLR is that the documentation is ABSOLUTELY HORRIBLE! It took me three weeks working with it to even figure out that it was intended to be used differently than I expected. I was hard pressed to find critical information. Stuff that is, IMHO, only a quarter step less important than the fact ANTLR is a parser generator, stuff I'd expect to be looking straight at after hitting Google's "I'm feeling lucky" button for ANTLR, no scrolling needed.


August 26, 2008
Reply to superdan,

> Benji Smith Wrote:
> 
>> superdan wrote:
>> 
>>>> Noooooooobody uses backtracking to parse.
>>>> 
>>> guess that makes perl regexes et al noooooooobody.
>>> 
>> I suppose it depends on your definition of "parse".
>> 
> well since you was gloating about handling a csv file as "parsing" i
> thot i'd lower my definition accordingly :)
> 
> p.s. sorry benji. you are cool n all (tho to be brutally honest
> listenin' more an' talkin' less always helps) but you keep on raisin'
> those easy balls fer me. what can i do? i keep on dunkin'em ;)
> 

A CVS parser can be interesting if you have high enough performance demands (e.g. total memory footprint smaller than a single field might be)


August 26, 2008
>>> superdan wrote:
>> well since you was gloating about handling a csv file as "parsing" i
>> thot i'd lower my definition accordingly :)

I don't know about "gloating". I mentioned it, because it was relevant to the conversation about places where streaming parsers are useful. But I can't see how it was gloating. Geez.

Why is everything a challenge to you? Why can't you just have a conversation, without getting all argumentative?

BCS wrote:
> A CVS parser can be interesting if you have high enough performance demands (e.g. total memory footprint smaller than a single field might be)

It's also interesting from the perspective that you can write a basic parser, using a dirt-simple grammar, that performs no backtracking.

In the word of parsers, it's about as simple and braindead as you get, but it's damn handy nevertheless.

It's possible to do the same thing with a regular expression, but it's very tricky to correctly handle all the weird newline issues, and it's even harder to avoid backtracking. I've done it both ways, and the regex solution sucks, compared to using a real parser generator.

--benji
August 26, 2008
On Wed, 27 Aug 2008 00:30:07 +0400, Steven Schveighoffer <schveiguy@yahoo.com> wrote:

> "Denis Koroskin" wrote
>> On Tue, 26 Aug 2008 23:29:33 +0400, superdan <super@dan.org> wrote:
>> [snip]
>>>> The D spec certainly doesn't make any guarantees about
>>>> the time/memory complexity of opIndex; it's up to the implementing class
>>>> to do so.
>>>
>>> it don't indeed. it should. that's a problem with the spec.
>>>
>>
>> I agree. You can't rely on function invokation, i.e. the following might
>> be slow as death:
>>
>> auto n = collection.at(i);
>> auto len = collection.length();
>>
>> but index operations and properties getters should be real-time and have
>> O(1) complexity by design.
>>
>> auto n = collection[i];
>> auto len = collection.length;
>
> less than O(n) complexity please :)  Think of tree map complexity which is
> usually O(lg n) for lookups.  And the opIndex syntax is sooo nice for maps
> :)
>
> In general, opIndex just shouldn't imply 'linear search', as its roots come
> from array lookup, which is always O(1).  The perception is that x[n] should
> be fast.  Otherwise you have coders using x[n] all over the place thinking
> they are doing quick lookups, and wondering why their code is so damned
> slow.
>
> -Steve
>
>

Yes, that was a rash statement.
August 26, 2008
Benji Smith Wrote:

> superdan wrote:
> > tho to be brutally honest listenin' more an' talkin' less always helps
> 
> LOL
> 
> Coming from you, dan, that's my favorite ironic quote of the day :)

meh. whacha sayin'? i ain't talking much.
August 26, 2008
Benji Smith Wrote:

> >>> superdan wrote:
> >> well since you was gloating about handling a csv file as "parsing" i thot i'd lower my definition accordingly :)
> 
> I don't know about "gloating".

was jesting. 'twas too good a comeback after u switched the definition of parsing on me. twice :)

> I mentioned it, because it was relevant to the conversation about places where streaming parsers are useful. But I can't see how it was gloating. Geez.
>
> Why is everything a challenge to you? Why can't you just have a conversation, without getting all argumentative?

conversatin's cool. but if you says something wrong and i happen to knows how it is i'll say how it is.
August 26, 2008
Walter Bright:
> Looks like I keep falling behind on what modern CPUs are doing :-(

The 5 good PDF files in this page are probably enough to put you back in shape: http://www.agner.org/optimize/

(Especially ones regarding CPUs and micro architecture. The first document is the simpler one).

Bye,
bearophile
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18