On Mon, May 13, 2002 at 02:35:27AM -0400, Rocco Caputo wrote:
> 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).
Yes, but it isn't that much about interfaces. The transitions that handle
the various cases would be connected to the place and various arcs from
the place to the transitions would only "let through" tokens of the real
type.
> 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?
I thought about this quite a lot. The things I would try to gain from using
a type system are type checking and automatic compares. At least for the
second one I would need some sort of operator. I thought about using
attributes to attach the types, but that seemed like a lot of work to do it
properly. And Perl is still no functional language, so I decided to keep
it perl-like.
The arcs from places to transitions can be of three types: single, permutation,
all. That describes the amount of tokens from the place that they get passed
as arguments. The expressions then have to return the possible binding
elements (it kind of extracts valuable information from the token into a
name=>value hash). If the tokens don't match, they just return nothing.
Afterwards the transition's guard expression is called with all combinations
of the binding elements from all the arcs. The implicit check is then done
like this: $h->{arc1}->{my_name} == $h->{arc2}->{my_var}. If the guard
returns true, the transition is enabled and gets executed (code is run,
arcs from the transition to other places produce new tokens). So the check
shouldn't be too annoying. When using the original versions variables on
arcs with the same name must contain the same value, so this check is implicit
and reduces the number of enabled combinations.
The single type expressions should be the ones most often used. The token
should be passed as some sort of local(), so if $t has the token the ftp
client could process error msgs with an expression like
sub { return ($t =~ /^220/ ?
({type=>"notification1", line=>$t}, {type=>"note2", line=>$t})
: () ); }
I will try to support some shortcuts so that the needed code can be small in
most cases and thus easy to read and view in a diagram. The above arc would
either return 2 or no binding element. So I thought it would be alright for
Perl programmers. If I'm wrong and real use shows that it leads to unreadable
nets then I will try to improve it, but first it needs users and therefore
a working release :)
>
> > 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.
Fortunately I don't really need special features. All that has to be done
is enable the net to send and receive events trough subclasses places
processing the incoming/outgoing tokens. And a loop that lets the net
process enabled transitions without locking (so it posts "CPNwork" events
when there could be enabled transitions). As I said, not a lot of code.
I just wanted to have an early announce so potential users can get used to it
before testing.
> > 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.
A good site about CPNs is http://www.daimi.au.dk/CPnets/. Has some longer
introductions as well. Information about Petri Nets can be found at various
places, I can't really give a recommondation. I hope to produce an usable
editor soon. It all gets a lot easier if you can write nets or do the token
game (testing your nets, place tokens, fire the transitions of your choice).
The theoretical stuff can be a bit hard, but modelling should be rather easy.
I will announce new working features on the list and try to write docs about
them. Looking at the POE code part could be as good. Using the core CPN code
to try out petri nets is probably not really useful, you need to debug it
and it is probably better to wait for the GUI frontend.
Torvald
