[Cuis] OMeta/Cuis?

[Edgar J. De Cleene]

On 6/7/15, 6:58 AM, "Phil (list)" <pbpublist at gmail.com> wrote:

> Having dug deeper into OMeta than I did the last time I worked with it,
> I'm now much more comfortable with both the ins and outs of its syntax
> as well as what's going on behind the scenes.  However, that also means
> I want to 'fix' a few things.  So my dilemma is what to call where I'm
> headed with it and generally get some feedback if anyone has had time to
> play with what's there so far to see what you're thinking about.
> 
> The general idea is to not change anything that is working well.  That
> means the existing syntax and rules (...mostly) wouldn't change as they
> seem to be well thought out and working pretty well.  Here are a few
> examples to give you a flavor for what I'm thinking about:
> 
> 1) Adding a couple of features which will likely require additional
> syntax.  Examples: rule pragmas and down the road possibly an error
> handling and/or debug semantic action.
> 
> 2) Adding a few new base rules and fixing existing bugs.  Examples: the
> fromTo rule looks broken to me if you actually attempt to use what it
> returns by default and I'm convinced that there really should be a
> fromToEnd rule (see what happens currently if you put a comment on the
> last line of your rule without a trailing lf... this will be an issue with
> any grammar that allows lf-terminated comments.  There are numerous
> other use cases as well.)
> 
> 3) Generally trying to polish any other rough edges and make things feel
> more natural.  Example: the [] syntax doesn't behave the way you'd
> expect (it's not actually a block, it takes a single expression so you
> end up needing to do something like [[] value] for multiple
> expressions... ugh.  It should be possible to handle both scenarios
> pretty easily.)
> 
> 4) There are a couple of optimization rules that OMeta/JS has that
> don't appear to have made it to Squeak so I'm planning on adding them.
> There are a couple of new ones I think I can add beyond that.
> 
> 5) Doing some work improving debugging and adding parser tracing (if
> you've taken a look at OMeta3/Ohm... something similar to that.)  While
> this wouldn't alter the behavior/functionality of any code you write, it
> will likely require changing quite a bit behind the scenes in the core
> code to make it work.
> 
> 6) Generally starting to document the code.  As is sadly the case with
> so much Smalltalk code, there aren't many comments that I've seen...
> use the source, Luke!  While it's very clean (and clever) code, it
> took me a while to figure out what was actually going on so I'd rather
> avoid needing to go on that excursion again and plan on writing some
> things down.
> 
> 7) Syntax coloring/highlighting in the editor would be great to have.
> I've still got some research to do to determine the effort involved.
> 
> What that will mean is that the vast majority of any existing
> OMeta/Squeak grammars should work just fine with what I'm planning.
> The biggest issue I can think of is if there's a name collision with
> one of the rules I add which is unlikely (and easy to resolve.)
> However, if you were to write code that expected the behavior some of
> my changes would make and go back to the Squeak version of OMeta, you'd
> run into problems.  (The Squeak version is welcome to use any of my
> changes as they see fit, but I'm not committing to keeping in sync with
> future changes from it at this time as it seems to be pretty much dead
> and I think I'll be moving pretty fast on some this for at least a
> while)
> 
> So the first question is what should I call it?  I'm thinking OMeta/Cuis
> unless there are objections or a better name is suggested.  Next, do you
> want me to keep the vanilla port that I have currently or should I just
> start making my changes on top of it?  Finally, are there any other
> issues you've run into that I've missed?
> 
> Thanks,
> Phil

Great.
Can't wait to examples

Edgar