[ragel-users] Re: ragel 5.23 released
thurs... at cs.queensu.ca
Fri Aug 3 17:15:36 UTC 2007
You can make such a machine like this:
later = start: "", "" -> final;
Though using this machine will be difficult. It will create unreachable
states that Ragel removes during compilation. You could give the final
state a label and then reference the label in an action to make sure
that the path from final state onward sticks around, but that's somewhat
I would suggest instead giving it a transition, preferably some
character out of the range of allowable input characters.
later = 0x100;
main := 'm' later '\n';
Steve Horne wrote:
> 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
> 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 ;-)
> You received this message because you are subscribed to the Google Groups "ragel-users" group.
> To post to this group, send email to ragel-users at googlegroups.com
> To unsubscribe from this group, send email to ragel-users-unsubscribe at googlegroups.com
> For more options, visit this group at http://groups.google.com/group/ragel-users?hl=en
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 252 bytes
Desc: OpenPGP digital signature
More information about the ragel-users