I was sitting next to a person who was wearing so much perfume that I sneezed and accidentally hit send.
(I have allergies) 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? Blah blah blah, --C _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
On Tue, 2015-05-19 at 23:52 -0700, Casey Ransberger wrote:
> I was sitting next to a person who was wearing so much perfume that I sneezed and accidentally hit send. > > (I have allergies) > > 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? > > Blah blah blah, > 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. One caveat: I didn't get to use OMeta long enough to figure out if that's the reality of how it would play out... > --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 |
In reply to this post by Casey Ransberger-2
Hi Folks,
I've used neither OMeta nor PetitParser. But I think it is great that you want them in Cuis. I will be very happy to support your efforts, and to make Cuis a good system for that. So, please, if Cuis ever becomes the problem, _do complain_ ! Cheers, Juan Vuletich On 5/20/2015 3:52 AM, Casey Ransberger wrote: > I was sitting next to a person who was wearing so much perfume that I sneezed and accidentally hit send. > > (I have allergies) > > 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? > > Blah blah blah, > > --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 |
Free forum by Nabble | Edit this page |