Thank you Otto, I had a look and it seems a nice implementation (couldn't load into the image but using the Monticello Browser) Cheers,
Hernán 2016-10-19 0:44 GMT-03:00 Otto Behrens <o...@finworks.biz>: > > 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 > >> >> > >> > > >> > > >> > > >
