[erlang-questions] Petri nets
Wed Jul 6 19:24:58 CEST 2016
In my view Petri nets somehow share the fate of expert systems. They are
just theoretical tools that's great to know about but not very practical
to solve real-life problems. This is because any problem one need to
solve would need to fit in the domain in which that tool operates.
In case of expert systems it is the inference based on facts, but how do
you add new facts, validate them, remove obsolete, etc? In real life
scenarios the knowledge is already somewhere and one only need to write
the inference on top of it. Trying to squeeze the whole application into
the tool that solves the specific problem is someone counterintuitive
(e.g. implementing all IO and adding, validating and removing facts in
Prolog only because Prolog is great as inference machine).
In my opinion the same can be said about Petri nets. When I have to
write an application solving a specific problem, trying to solve some of
its parts using Petri nets may not give me the required benefit because
of the required shift between different domains.
Having said that, it maybe just a matter of integrating Petri nets into
the language at the correct level, similarly to how Erlang integrated
message passing and green processes into the language.
But can you think about a problem that could be better solved by having
multiple gen_pn representing nodes of concurrent computations in a Petri
net rather than green Erlang threads communicating with each other using
On 06/07/2016 15:17, Jörgen Brandt wrote:
> And here the link to the library ...
> On 06.07.2016 17:16, Jörgen Brandt wrote:
>> Dear all,
>> recently I was curious about programming with Petri nets. I have
>> the impression that concurrent nature of Petri nets would be
>> extremely useful for many types of applications.
>> Also, with the gen_fsm and the gen_statem being part of Erlang's
>> standard library the idea of implementing application models in
>> terms of behaviours filling in the missing callback functions
>> while abstracting away the brittle parts concurrency and
>> communication would have a strong appeal. Imho, Petri nets can be
>> defined in exactly the same way.
>> This idea has also been discussed in a mailing list entry by Claus
>> Reinke  who happens to have written a paper about implementing
>> Petri nets in Haskell  in which he observes that functional
>> languages are well suited for implementing Petri nets and points
>> out Erlang as a potential candidate also with regard to concurrency
>> In addition, I stumbled over a compelling blog post which
>> motivates the use of Petri nets for application design in the
>> context of telecommunication applications . The author goes on
>> to presents his Petri net programming library in C# and even has
>> proposed a gen_pn behaviour for Erlang .
>> However, the aforementioned gen_pn library has not been touched
>> for six years and the email from Claus Reinke has been sitting in
>> the Erlang mailing list archives for 13 years (unanswered).
>> My question is, in your opinion, is the idea of using Petri nets as
>> a programming model in Erlang just a bad idea? Or has the right
>> library just not been conceived to date? Do you use Petri nets to
>> sketch out an application's behavior but then translate it to a
>> different model prior to implementation? How can a
>> telecommunication-focused programming ecosystem have avoided Petri
>> nets for such a long time while readily absorbing ever more flavors
>> of state machines?
>> That said, I would be very glad to receive your feedback on a
>> Petri net library I recently came up with. So you have something to
>> base your criticism on (;
>  http://community.haskell.org/~claus/publications/HCPN.html
>>  https://github.com/aabs/gen_pn
>> _______________________________________________ erlang-questions
>> mailing list
> erlang-questions mailing list
More information about the erlang-questions