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

> 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?

> 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
>