ATTENTION: Call for input on impending API changes

[Alex Stewart]

Hi all,

Modgrammar is currently still technically in beta.  That can mean a lot of different things to different people (and different projects), but primarily what it means to me (here) is that the project is mostly stable, has few or no known issues, but has not been tested as thoroughly as it could be yet.  What it also means is that the API is fairly stable but is still theoretically subject to non-backwards-compatible changes if they turn out to be desirable prior to official release.

At this point I see Modgrammar as bearing down on an official 1.0 (non-beta) release within the next year.  There are a couple of API changes I'm considering for upcoming releases of Modgrammar before that happens, however.  Unfortunately, I'm left with a couple of questions which only you folks out there in Internet-land can answer:

1.  Who out there is currently using (or considering using) Modgrammar?  Also, does anybody in this group know of somebody who might be using it but isn't subscribed to this?  If you don't want to speak up here, that's fine, feel free to send me an email directly instead, but I really want to try to get an idea who (if anybody) is likely to be impacted if I make changes at this point, so I can try to make sure they don't come as too much of a surprise to anyone.

2.  Does anybody out there have any input on the following planned API changes?

• Change parse_string to behave as if "reset=True, eof=True" and throw an error if there's a remainder (the plan is to move the current parse_string behavior to be called "parse_text" instead, so it'll still be available, just under a different name).  The idea here is to make the behavior a little more intuitive for folks who just want a quick-and-dirty "parse this self-contained string" function. [http://code.google.com/p/modgrammar/issues/detail?id=11]
• Change grammar_whitespace to be False by default.  This means any grammar which actually wants to skip whitespace between tokens will need to turn this on explicitly (which may affect some existing grammars who didn't set it explicitly one way or the other before) [http://code.google.com/p/modgrammar/issues/detail?id=15]
• Change SPACE to only match non-newline whitespace (currently it matches all whitespace, including newlines).  The plan is to also add a new WHITESPACE grammar which can be used if people want to match newlines as well, so for any existing grammars which use SPACE, they would need to be changed to use WHITESPACE instead. [http://code.google.com/p/modgrammar/issues/detail?id=16]

Basically the aim of all of these changes comes down to trying to make the API more intuitive (or at least less likely to do subtly-wrong things if people haven't read the docs that carefully).

Anyway, if anyone has any feedback on any of this, please let me know.

--Alex

[Nekroze Embrace]

Heyo, I am planning on using modgrammar for my upcoming DSL language that converts to c++ code. I particularly approve of the change to space and in general don't see a problem, at least for me with the others.

-Nekroze