On Fri, May 31, 2002 at 11:18:18AM -0400, Peter Chen wrote: > > Is this ready for public consumption? I downloaded the first snapshot > and took a peak. The code is well organized. I like what I see. It > seems to be a very promising tool for describing and coding a state > machine. It would make my tutorial as simple as writing down the steps > as you mentioned.
Well, the design of the core simulation engine should not change a lot. At least not the API. Actually, this is just used when creating a new instance of a net and thus not really important. The formalism one uses to describe the net could show to be insufficient. But at the moment I don't see any way that would be a lot better and easy to do. Several other tools use functional programming languages or an own grammar for expressions, mainly to better match token parts to variables (so if you have two incoming arcs with expressions "x" and "x+1" than the transition would be only enabled with tokens that differ by 1, and x would be bound to the smaller value). This is better, but not really Perl-ish. Unfortunately, this requires parsing the expressions or working with the op tree somehow, and having some sort of type system. So I chose to take the way that is easier to do, requires more work (explicit guard expressions checking equality), but isn't more complicated than common Perl coding. The good thing is that if there should be a new way to write nets, there would be no problem to run old and new version nets, even when put together. The new stuff would just have to be marked as such. If the new nets are more powerful, it even should be possible to automatically translate nets. The code needs clean-up, and most important, testing. My plan was to first get a working editor (and simulator frontend) so writing nets and testing would be easier. Then to let the editor talk to environments for the core (POE::CPN) and the library. The design of the library is not done yet. I intented to use the libraries as an abstraction layer, so that the core would be without net management facilities and one could more easily use different libraries. Additionally environments should use the library as information point when nets are simulated in the editor. The user should use libraries when creating new net instances (maybe hierarchical nets in the future?). So what could or will change ? -libraries -environments (although the POE stuff should change a lot, when talking to the editor a new, more bloated env will be attached, so the one used usually keeps more light-weight) -the way expressions are written: maybe some more abbreviations, local() for tokens instead of passing them -work delegation between places and the net (depends on future developments, but is mostly internal) -i don't have a real experience regarding CPNs, so I make / might have made mistakes. there might be several better ways, or more likely, missing features Most of the things above requires more user input to find the good way. This isn't good, I know, but I'm just not sure about some requirements. CPN's provide a very compact way to model a problem. I don't want to bloat that, so I will change things if they are not as useful/comfortable as I thought. > The only barrier is the initial learning curve of CPN. Then again, > having a clearly defined procedure to convert a state machine into code > makes it well worth the effort. I don't know to what extends you'd like to use it, so I can't give you a real answer. It is not ready for prodution use, of course. But the core parts are not that far away, I hope. I you want to use them now and participate (coding, testing, ...) you are really welcome :) If you want to use them now, I will work more on stabilizing the core parts and less on the editor stuff. I agree that CPNs or Petri nets in general require some effort in the beginning, and the theoretical background even more. But the probabilty that you will be able to use Petri nets in the future should be much higher than in the case of a lot of technologies. So it could be like learning functional programming once and <your favourite API> every time it changes. Torvald
