<html><head></head><body bgcolor="#FFFFFF"><div>Thanks, glad it wasn't just my own obtuseness. </div><div><br></div><div>When I need a parser, I write my own using a particular pattern that works well for me: easy to debug, easy to generate clear error messages for the user, easy to map the generated stuff back to source and v/v. <br><br>-- David (tapped out on my iPhone; blame it for any typoze;-)</div><div><br>On Dec 13, 2011, at 10:24 PM, Casey Ransberger <<a href="mailto:casey.obrien.r@gmail.com">casey.obrien.r@gmail.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div>
<span style="display:none"> </span>
<div id="ygrp-text">
<p></p><div>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. </div><div><br></div><div>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.</div><div><br></div><div>Another way of saying this is: test methodology will always follow at least slightly behind development methodology. </div><div><br></div><div>But yeah, debugging an OMeta grammar is a pain in the ___:)<br><br>On Dec 13, 2011, at 9:46 PM, <a href="mailto:ungar@mac.com">ungar@mac.com</a> wrote:<br><br></div><div></div><blockquote type="cite"><div>
<span> </span>
<div id="ygrp-text">
<p>Have you ever used OMeta and tried to debug your OMeta program?</p><div>I tried, very briefly, and was put off by the debugging experience.</div><div>But maybe you've had better luck.</div><div><br></div><div>- David</div><div><br></div><div><br></div><div><br><div><div>On Dec 12, 2011, at 5:48 PM, Casey Ransberger wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div style="background-color: #fff;">
<span> </span>
<div id="ygrp-text"><div><br class="webkit-block-placeholder"></div><div>Top post: nested interpreters makes me think about OMeta. Just a thought. <br><br>On Dec 12, 2011, at 3:28 PM, "Jecel Assumpcao Jr." <<a href="mailto:jecel@merlintec.com"></a><a href="mailto:jecel@merlintec.com">jecel@merlintec.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div>
<span> </span>
<div id="ygrp-text"><p>Thorsten Dittmar wrote:<br>
<br>
> I'm interested in general , to get self more selfish. If we would be able to<br>
> manifest the principles of self even more accurate and more evident, that<br>
> would be something great. For that reason I thought that the Klein VM would<br>
> be one of the right steps.<br>
<br>
It is a very good idea to be able to use what we have learned. That is<br>
how we got Self in the first place, and before that Smalltalk-80 from<br>
-78/-76 and those from -72/-74. Commercialization from Smalltalk-80 as<br>
it was, so the lessons from Ark couldn't be applied.<br>
<br>
Klein tried to implement the stuff learned after Self 1, 2 and 3 and<br>
then Squeak. My main problem with that project is that it uses<br>
generative coding (think macros) to get more done with less but this is<br>
done in a system that is unaware of this. So you get generated code side<br>
by side with hand written stuff and it takes a very long time to figure<br>
out which is which if you weren't the one who created them in the first<br>
place. This also tends to create many copies of the same stuff (made<br>
worse by the fact that there are several parallel experiments in the<br>
same code) and it takes a while to figure out which ones are used where.<br>
<br>
Since Klein has not been touched since 2006, my own strategy will be to<br>
try to include what I can learn (and have already learned) from it in a<br>
new system. My PhD project is to implement a self sustained system in a<br>
way that is understandable by generating code from nested interpreters<br>
(which are easy to write and understand) with partial evaluation (even<br>
if a mostly faked one, like in Pypy where tracing does the job a partial<br>
evaluator would do). One way a system can be defined in itself is<br>
through reflection - meta-objects. That leads to the problem of an<br>
infinite tower of interpretation, but as I just said nested interpreters<br>
are exactly what I hope my system will be able to handle.<br>
<br>
The metric to measure the success of my PhD project will be how much of<br>
Klein's funcionality it will have compared with how much smaller it will<br>
be to do it.<br>
<br>
The language I have been using is Squeak in order to play nice with<br>
several projects that are interesting to me. But I think it might be<br>
better to include more options, like Self 4 and some even simpler<br>
version.<br>
<br>
-- Jecel<br>
<br>
</p>
</div>
<!-- end group email -->
</div></blockquote><div><br class="webkit-block-placeholder"></div>
</div>
</div>
<!-- end group email -->
</blockquote></div><br></div><p></p>
</div>
<!-- end group email -->
</div></blockquote><p></p>
</div>
<!-- end group email -->
</div></blockquote></body></html>