Thank you.

> provide me captcha
Probably, there never will be a CAPTCHA code, as (regularly) we have issues with it myself. Also, I have a stylish (literate programming!!) Robot.txt-file, written in … , of course.

Rainer

this must be Claus, right?

Interesting post. I totally agree that there are strong connections between CHR and petri-nets which have so far been largely ignored. In my opinion and experience, CHR are the cleaner more concise formalism to specify complex, concurrent systems thanks to simpagation (simplification+propagation) and a general form of guards. As far as I know, guarded transitions have only been added to petri-nets later.

Yes, I’m a programmer not a modeler
On top of that, I’m a CHR guy but I’m open to petri-nets and any works which come out of this area.

So why are petri-nets so popular?
Well, many users, engineers in particular, prefer to draw and read ‘pictures’ rather then writing programs (e.g. take the embedded systems area in which I’m currently working in as an example). That might explain why petri-nets have grown that large and why the CHR community is still relatively small.

Modeling versus programming: I can’t see a difference either. Models shall be executable, so there you have your programming.

What can modelers (petri-nets) learn from programmers (CHR and the like) and vice versa?
As you have already indicated, there are many petri-nets application, concepts and methods which are just waiting to be transferred to the language (CHR) setting. On the other hand, programmers (language researchers) have a very good grasp of formal semantics, static analysis (-> type systems) and language concepts (polymorphism).

As a prominent example where modelers and programmers cooperate, take SCADE which is based on LUSTRE.

Cheers,
Martin