[erlang-questions] Petri nets

[Grzegorz Junka]

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 
message passing?

Grzegorz


On 06/07/2016 15:17, Jörgen Brandt wrote:
> And here the link to the library ...
>
> https://github.com/joergen7/gen_pnet
>
> 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 [1] who happens to have written a paper about implementing
>> Petri nets in Haskell [2] 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
>> aspects.
>>
>> 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 [3]. The author goes on
>> to presents his Petri net programming library in C# and even has
>> proposed a gen_pn behaviour for Erlang [4].
>>
>> 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 (;
>>
>> [1]
>> http://erlang.org/pipermail/erlang-questions/2003-November/010704.html
>>
>>
> [2] http://community.haskell.org/~claus/publications/HCPN.html
>> [3]
>> https://aabs.wordpress.com/2010/03/10/programming-with-petri-nets/
>> [4] https://github.com/aabs/gen_pn
>> _______________________________________________ erlang-questions
>> mailing list erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>