OMeta/Cuis?

> 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

> 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

> 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.
>

> On Sun, 07 Jun 2015 21:04:11 -0400
> "Phil (list)" <[hidden email]> wrote:
> >
> > OMeta/Cuis it is... it now lives at https://github.com/pbella/OMeta-Cuis
> >
>
> Any chance of changing the GitHub dir to https://github.com/pbella/Cuis-Smalltalk-OMeta ?
>
> The Cuis-Smalltalk-* makes it much easier to search GitHub.
>