[self-interest] goals (was: dynamic deoptimization)

[Casey Ransberger]

PEGs are painful to debug. All that memorization creates a lot of instance state. This is presently a given. I've experienced the same problem with OMeta, PetitParser, and Treetop. 

I would offer: PEGs are relatively new, at least compared to CFGs. They make a lot of things that are hard to do with CFGs really easy. It's likely, given that they provide a different set of trade-offs from what one gets with traditional compiler design, that we'll eventually find better ways to deal with debugging them.

Another way of saying this is: test methodology will always follow at least slightly behind development methodology. 

But yeah, debugging an OMeta grammar is a pain in the ___:)

On Dec 13, 2011, at 9:46 PM, ungar at mac.com wrote:

> Have you ever used OMeta and tried to debug your OMeta program?
> 
> I tried, very briefly, and was put off by the debugging experience.
> But maybe you've had better luck.
> 
> - David
> 
> 
> 
> On Dec 12, 2011, at 5:48 PM, Casey Ransberger wrote:
> 
>>  
>> 
>> Top post: nested interpreters makes me think about OMeta. Just a thought. 
>> 
>> On Dec 12, 2011, at 3:28 PM, "Jecel Assumpcao Jr." <jecel at merlintec.com> wrote:
>> 
>>>  
>>> Thorsten Dittmar wrote:
>>> 
>>> > I'm interested in general , to get self more selfish. If we would be able to
>>> > manifest the principles of self even more accurate and more evident, that
>>> > would be something great. For that reason I thought that the Klein VM would
>>> > be one of the right steps.
>>> 
>>> It is a very good idea to be able to use what we have learned. That is
>>> how we got Self in the first place, and before that Smalltalk-80 from
>>> -78/-76 and those from -72/-74. Commercialization from Smalltalk-80 as
>>> it was, so the lessons from Ark couldn't be applied.
>>> 
>>> Klein tried to implement the stuff learned after Self 1, 2 and 3 and
>>> then Squeak. My main problem with that project is that it uses
>>> generative coding (think macros) to get more done with less but this is
>>> done in a system that is unaware of this. So you get generated code side
>>> by side with hand written stuff and it takes a very long time to figure
>>> out which is which if you weren't the one who created them in the first
>>> place. This also tends to create many copies of the same stuff (made
>>> worse by the fact that there are several parallel experiments in the
>>> same code) and it takes a while to figure out which ones are used where.
>>> 
>>> Since Klein has not been touched since 2006, my own strategy will be to
>>> try to include what I can learn (and have already learned) from it in a
>>> new system. My PhD project is to implement a self sustained system in a
>>> way that is understandable by generating code from nested interpreters
>>> (which are easy to write and understand) with partial evaluation (even
>>> if a mostly faked one, like in Pypy where tracing does the job a partial
>>> evaluator would do). One way a system can be defined in itself is
>>> through reflection - meta-objects. That leads to the problem of an
>>> infinite tower of interpretation, but as I just said nested interpreters
>>> are exactly what I hope my system will be able to handle.
>>> 
>>> The metric to measure the success of my PhD project will be how much of
>>> Klein's funcionality it will have compared with how much smaller it will
>>> be to do it.
>>> 
>>> The language I have been using is Squeak in order to play nice with
>>> several projects that are interesting to me. But I think it might be
>>> better to include more options, like Self 4 and some even simpler
>>> version.
>>> 
>>> -- Jecel
>>> 
>> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.selflanguage.org/pipermail/self-interest/attachments/20111213/da0e1692/attachment.html>