Sorry, I see there are some unresolved dependencies on our code. Let me know if I should work on that.
On Wed, Oct 19, 2016 at 5:44 AM, Otto Behrens <o...@finworks.biz> wrote: >> 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 >>> >> >>> > >>> > >>> >>
