Comparison of PetitParser with OMeta (was: Re: Message sent early. Oops)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Comparison of PetitParser with OMeta (was: Re: Message sent early. Oops)

Hannes Hirzel
Great and concise synoptic summary, Casey. This needs to be made
visible. Thanks!

Yes, we need both, PetitParser and OMeta.

But PetitParser seems easier to do

Paolo did a port 3 years ago.
https://github.com/pmon/Cuis-PetitParser (see his note today in another thread).

We need recent ports

http://smalltalkhub.com/#!/~Moose/PetitParser/commits

and have to be in the position to do them repeatedly.

Preferrably fully automatic (just file-In like VMMaker) or
semi-automatic (i.e. following a sheet of instructions how to do it,
example is the README here https://github.com/hhzl/Cuis-NeoCSV)

BTW Jan Kurs recently added Markdown parsing to the PetitParser
example grammar collection
http://scg.unibe.ch/research/indentParsing

--HH

On 5/20/15, Casey Ransberger <[hidden email]> wrote:
..

> What I was trying to say was that both PetitParser and OMeta are worth
> having around. OMeta gives you a grammar description that's a bit more
> concise that what you get out of PetitParser, but it also burdens the
> learner with a newish language, whereas PetitParser does more or less the
> same job using only cleverness around building a DSL within the context of
> pure Smalltalk.
>
> It's been reported [citation needed] that PetitParser outperforms OMeta. So
> that's an advantage. It fits with the "everything is Smalltalk" idea.
>
> OMeta, though, seems to express the grammatical transformations in far less
> code than the PetitParser equivalent, because it is its own language,
> tailored to the actual problem.
>
> Personal experience:
>
> With PetitParser, I had to write a ton of different methods to express
> grammars I was interested in. But they were always very short, in classic
> Smalltalk style.
>
> With OMeta, I could do the same thing in a page of cogent, all in your face
> code.
>
> Which is the greater cognitive advantage in language design?
>
> Where is the balance between Smalltalk-style versus this totally new thing?
>
> Our current languages, I'll suggest, are still found wanting, for some jobs.
> The beauty of Smalltalk is we can do everything in one language. But what if
> we came up with a new language, maybe something like an APL for the graphics
> pipeline? (Nile/Jezira)
>
> I'm not going to pretend to answer, but providing both strategies as
> extensions to a minimal, well understood system could be really useful. We
> might actually learn something in the compare and contrast session.
>
> It can't possibly hurt?
..
> --C

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Comparison of PetitParser with OMeta (was: Re: Message sent early. Oops)

Hannes Hirzel
Let repeat Phil's  note from one hour ago:

<citation>
True, they both get roughly the same job done.  I always think of more
traditional parsers like PetitParser as being for processing data from
the 'outside' (data files, other languages) where OMeta is something
you're likely to use on the 'inside' (part of your app logic).  Another
way to think of OMeta: Smalltalk's version of Lisp macros.
</citation>

What do you think about

"Another way to think of OMeta: Smalltalk's version of Lisp macros."

--Hannes

On 5/20/15, H. Hirzel <[hidden email]> wrote:

> Great and concise synoptic summary, Casey. This needs to be made
> visible. Thanks!
>
> Yes, we need both, PetitParser and OMeta.
>
> But PetitParser seems easier to do
>
> Paolo did a port 3 years ago.
> https://github.com/pmon/Cuis-PetitParser (see his note today in another
> thread).
>
> We need recent ports
>
> http://smalltalkhub.com/#!/~Moose/PetitParser/commits
>
> and have to be in the position to do them repeatedly.
>
> Preferrably fully automatic (just file-In like VMMaker) or
> semi-automatic (i.e. following a sheet of instructions how to do it,
> example is the README here https://github.com/hhzl/Cuis-NeoCSV)
>
> BTW Jan Kurs recently added Markdown parsing to the PetitParser
> example grammar collection
> http://scg.unibe.ch/research/indentParsing
>
> --HH
>
> On 5/20/15, Casey Ransberger <[hidden email]> wrote:
> ..
>> What I was trying to say was that both PetitParser and OMeta are worth
>> having around. OMeta gives you a grammar description that's a bit more
>> concise that what you get out of PetitParser, but it also burdens the
>> learner with a newish language, whereas PetitParser does more or less the
>> same job using only cleverness around building a DSL within the context
>> of
>> pure Smalltalk.
>>
>> It's been reported [citation needed] that PetitParser outperforms OMeta.
>> So
>> that's an advantage. It fits with the "everything is Smalltalk" idea.
>>
>> OMeta, though, seems to express the grammatical transformations in far
>> less
>> code than the PetitParser equivalent, because it is its own language,
>> tailored to the actual problem.
>>
>> Personal experience:
>>
>> With PetitParser, I had to write a ton of different methods to express
>> grammars I was interested in. But they were always very short, in classic
>> Smalltalk style.
>>
>> With OMeta, I could do the same thing in a page of cogent, all in your
>> face
>> code.
>>
>> Which is the greater cognitive advantage in language design?
>>
>> Where is the balance between Smalltalk-style versus this totally new
>> thing?
>>
>> Our current languages, I'll suggest, are still found wanting, for some
>> jobs.
>> The beauty of Smalltalk is we can do everything in one language. But what
>> if
>> we came up with a new language, maybe something like an APL for the
>> graphics
>> pipeline? (Nile/Jezira)
>>
>> I'm not going to pretend to answer, but providing both strategies as
>> extensions to a minimal, well understood system could be really useful.
>> We
>> might actually learn something in the compare and contrast session.
>>
>> It can't possibly hurt?
> ..
>> --C
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org