[Cuis] OMeta/Cuis?

[Phil (list)]

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