[Cuis] OMeta/Cuis?

[Juan Vuletich]

Hi Phil,

(below)
On 6/7/2015 6:58 AM, Phil (list) 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

I think OMeta/Cuis is a perfectly reasonable name for your project.

WRT keeping the 'vanilla port', asking you to mainain two forks of the 
same project is too much. I think the best would be to call OMeta/Cuis 
1.0 what you have right now, and start calling it OMeta/Cuis 2.x when 
you make anything but bugfixing or small tweaks. Like in Semantic 
Versioning: http://semver.org . (Although in Cuis packages we currently 
don't have PATCH version, just MAJOR and MINOR). Maybe you can have a 
'Version1.0' folder in your GitHub repo, and store it there. Most 
likely, everybody will be using the latest version, and you'll be 
focused on it. But, if for any reason, anybody wants to use 1.0, doing 
as I suggest, there's no need to browse repo versions, etc.

HTH.

Cheers,
Juan Vuletich