On Mon, May 13, 2002 at 12:01:33AM +0200, [EMAIL PROTECTED] wrote: > [introduction to Coloured Petri Nets]
> There are quite a few differences between the nets that use ML and this > implementation. Perl hasn't got a real type system nor is it a functional > programming language. Therefore arc expressions must determine the tokens > on _their_ place that could be part of a step (and determine the bindings). > Guard expressions need to check equality of bindings explicitely, there > can be no real implicit check because you cannot automatically compare without > types. Outgoing arcs just produce tokens. A lot of state transitions depend on matching input token types and/or values. This almost seems like a form of polymorphism (if I'm using the proper term). Would it be possible to create a type system within the network? For example, by passing values as [ TYPE, VALUE ] pairs or abusing bless() and ref() to associate types with values and query them? > There are no docs (there are detailed design plans but not in digital form) > yet. API might change. Work on libraries has just started. Embedding the > net in POE sessions has not been tested, but this is not a lot of code so > this should work I guess. Fortunately the core CPN code (PetriNet::Coloured, > PetriNet::Coloured::(Place,Transition)::* should work, although I have > just tested it with t/test1.pl. More testing will follow once cpne can > be used. Maybe hierarchical nets. I do not plan to implement analysis > functions for nets right now. If it will help, you can write a specialized session that understands Petri nets. Matt Cashner's work to make POE::Session subclassable has made it a lot easier to create new session types. > Please tell me if you are interested in more information or would like to > contribute, e.g. with the java stuff ;) I'm interested in more information. Coloured Petri Nets still confuse me. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sf.net
