ragel 5.23 released

[Steve Horne]

None of the issues are all that important (esp. the underscores thing,
of course ;-) ), but...

On Aug 1, 11:41 pm, Adrian Thurston <thurs... at cs.queensu.ca> wrote:
> Steve Horne wrote:
> > First, any chance of a new built-in machine? - one that never matches
> > anything? The idea is to use it in placeholder rules, that will be
> > filled in later - options that aren't implemented yet.
>
> I don't understand this, filled in at what time? Could you please be
> specific in terms of the compilation of a Ragel program.

It's a development lifecycle thing, rather like being able to declare
methods as deprecated in some programming languages but for use mainly
at the beginning of the lifecycle rather than during maintenance.

I want to be able to reference a machine in higher level machines that
I have defined, but not necessarily define what that new machine
contains quite yet - top-down functional decomposition IOW. Declaring
the new machine as not matching anything sounds like the easiest way
to do that.

It's my view that any DSL should make life as easy as possible for
users who are not particularly familiar with them, since DSLs are
mostly used only occasionally. Ragel already does pretty well in this
respect - e.g. the ability to generate dot visualisations means that a
lot of initial development can be done without worrying about actions
etc.

In implementation terms, it should just be a matter of having two
states (a start state and an end state) that are disconnected from
each other. Then, the only obvious new issues compared with what you
already have would be elimination of unreachable states and
elimination of states from which it would be impossible to reach an
end state - FSM minimisation doesn't necessarily handle this. Since
this is just an initial development thing, even these may be
considered non-issues.

> > class classname
> > {
> >   static const int membername;
> > };
> > ...
> > static const int classname::membername = 5;
>
> Is there a particular reason to want table data in a class? I can
> imagine wanting variables that identify states (such as start_state) in
> the class, but I can't see a reason to want table data.

It's entirely about programming style and habits.

Data that is only used by a particular class should in principle be
member data, if only to express the intent that the data should not be
accessed from outside the class. That won't be appropriate in every
case, even assuming that a class is used at all, and its not that
important since the static flags already tell both the user and
compiler not to allow access from other source files, but it is not a
good idea to get between a programmer and his good-style ideology ;-)