> Do you mean internal or embedded DSL? I am open to write an DSL if > facilitates the job, the thing with the Trevor's paper is that he defines 6 > implementations of FSM's (and in each implementation he considers several > issues leading to sub-implementations) so I would like a DSL which let me > express different implementations for the same FSM. Plus there are FSM > implementations out there: HotDraw, Connectors, MIDIInputParser, XMIReader, > SState, etc. I think a "correct" DSL would enable to define any of them > right?
I just meant some syntactically terse way of expressing a state machine so that one can see the logic clearly. Representing a state machine in a graphical way is ideal. We did this once, but the problem is to make the state machine definition resilient to refactorings and changes to the code. What I mean is that compiling something into code is a one way thing; to keep it maintained, one would like to "reverse compile" and draw the state machine from code. A "correct" DSL would be something like a Harel state diagram, which should be able to express most requirements. I attach our state package, if you're interested. Not directly one of the approaches in Trevor's paper. Perhaps another option. I would like to extend it to use guards and actions and more. > The approach I am using now is a parametrized code generator, using > templates (not in the form of T4 templates), so it's a long way. > Maybe Helvetia could help? Out of my depth here; will have to read a lot more. > > >> >> On Tue, Oct 18, 2016 at 9:29 AM, Julien Delplanque <jul...@tamere.eu> >> wrote: >> > Hello, >> > >> > A generator for the visitor design pattern: >> > - Generate methods in visited objects: VisitedObject>>#accept: (with the >> > selector name configurable) >> > - Generate empty methods (or methods with a "self >> > subclassResponsability" if >> > an abstract visitor is generated) >> > called in #accept: methods of VisitedObjects in the Visitor i.e >> > Visitor>>#acceptVisitedObject: (with the selector >> > name configurable again). >> > >> > Each time this design pattern has to be used, it is annoying to write by >> > hand all these methods. >> > >> > Regards, >> > >> > Julien >> > >> > >> > On 18/10/16 07:24, Hernán Morales Durand wrote: >> >> >> >> Hi guys, >> >> >> >> I am writing a code generator, doing a few iterations right now. >> >> I want your opinion, which most useful thing would you like to be >> >> generated >> >> automatically? It could be a pattern, an idiom, another language... >> >> >> >> For example my own wish (roadmap) list: >> >> >> >> - A "settings framework" settings class generator. >> >> - A state machine generator (based in the excellent paper of Trevor P. >> >> Hopkins) >> >> - A Spec UI generator. >> >> >> >> Let me know your thoughts. >> >> >> >> Cheers, >> >> >> >> Hernán >> >> >> > >> > >> >
Wonka-StateTransition-Core-otto.1645.mcz
Description: Binary data
Wonka-StateTransition-Tests-Core-otto.4385.mcz
Description: Binary data
