[Cuis] Why or why not OMeta? (was Re: Brainstorming question: what non-trivial uses can you think of for an object-based parser? (strings not invited))

[Thierry Goubier]

Hi,



Le 23/05/2015 11:30, H. Hirzel a écrit :
> On 5/22/15, Phil (list) <pbpublist at gmail.com> wrote:
>>
>> Not strange at all given where it sounds like you're coming from re:
>> performance being a key requirement.  I won't try to put any spin on it:
>> everything I've seen indicates that OMeta is among the slowest parsers
>> out there, but pretty quick given its approach.  Computing power what it
>> is today, for many applications the response is 'it's fast enough' or
>> 'who cares?' (see the World Wide Web, client- and server-side, for a
>> perfect example)  I would imagine that if you have heavy data processing
>> workloads or have very specific response time requirements, then you do
>> care and OMeta wouldn't work for the application.  However, as a
>> language for DSLs, at most you're typically only going to see a small
>> fraction of a second of overhead.  Another way to think of it: if speed
>> OF the solution is the priority, don't use OMeta.  If speed TO the
>> solution is the priority, that's what OMeta does well.  I'll get more
>> specific below...
>
>
> Speed is an issue but not the only one. We need an in-depth comparison.

The investment you have to make in fully functional parsers is high, so 
it tend to makes comparisons harder :(

>>> I have been writing compiler front-ends for the past 7 years, first
>>> with Flex / Bison and C, and then with Smalltalk / SmaCC (I maintain
>>> SmaCC for Pharo).
>
> Great. Where do you have the repository?

http://github.com/ThierryGoubier/SmaCC

It's currently SmaCC 2.0.4 as from refactory.com, missing the 
master/slave distributed rewriting engine I haven't ported and with the 
+ / * / ? additions to the grammar syntax.

Has a strong dependency on RB. Significantly different from the past 
1.0.X version that was available for Squeak/Pharo.

> Currently OMeta 2 is in focus but later I think we need all of the
> parsers ported to Cuis for comparison.

What do you intend to do with them? Writing working parsers for a 
programming language is a significant investment.

>
> Yes, the short grammar are a strong point. Compact and readable.

The problem is, as far as my experience goes with grammars, they are 
neither that short nor that readable ;)

Of course, if you compare to a hand-written parser... Even if for 
Smalltalk use, I wouldn't replace the RB parser. Fast, and extremely 
powerfull (refactoring).

>>>
>>> So what are the benefits of OMeta? Note that SmaCC would very easily
>>> do parsing over any kind of objects, not only tokens.
>
> Can you elaborate on this?

A SmaCC Parser sees only a stream of instances of SmaCCToken, on which 
it only uses an "id" notion (or multiple ids when in GLR/ambiguity 
mode). So you could replace tokens by anything else as long as you use 
this id thing (the id is a number).

Regards,

Thierry