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