<div dir="ltr">Also, it is important that all BIFs that have to do with state outside of the process itself (as opposed to e.g. the process dictionary functions) - such as the process registry functions, system time, timers, etc. - can and should be modelled as messages to and from the corresponding VM subsystem. Yes, this implies a lot of possible race conditions - but these already exist in a modern Beam, where multiple threads are working simultaneously and trying to avoid global locks. Best to get those out in the open right away, so you don't paint yourself in a corner by assuming that certain BIFs always will take effect globally, atomically and instantaneously.<div><br></div><div>I think this is an underappreciated (or at least not widely understood) property of Erlang and its implementation. You could in fact have large parts of its runtime system execute on a physically separate machine from the processes that run your Beam code, without having to change a line in your programs.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><br>        /Richard</div></div>
<br><div class="gmail_quote">2017-10-06 20:07 GMT+02:00 Jesper Louis Andersen <span dir="ltr"><<a href="mailto:jesper.louis.andersen@gmail.com" target="_blank">jesper.louis.andersen@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>General rule when trying to build language cores formally:<br><br></div>Every construction which can be written in terms of another construction should be.<br><br></div>* ETS tables are really just processes<br></div>* The Process dictionary is just a state monad in the language<br></div>* You need monads for message passing side effects anyway, so you can probably reuse the work on top<br></div>* The whole exception system can be cast inside the monad as well<br><div>* Ports can be reimagined as special processes and you can use messaging in order to handle them<br></div><div><br></div><div>The reason is that any construction is a formal liability: it needs special handling. It is often more beneficial to generalize the system a little bit in order to vastly simplify the number of cases you have to handle in proofs.</div><div><br></div></div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 27, 2017 at 7:20 AM Karlo Kuna <<a href="mailto:kuna.prime@gmail.com" target="_blank">kuna.prime@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span style="font-size:12.8px">> No - write a new runtime but inspired by and stealing good bits from the old<br><br></span></div><div dir="ltr"><span style="font-size:12.8px">what would you consider good bits here? </span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">i also suspect that mini erlang  would be better off without process dictionaries? <br><br> </span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 26, 2017 at 10:59 PM, Joe Armstrong <span dir="ltr"><<a href="mailto:erlang@gmail.com" target="_blank">erlang@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Sep 26, 2017 at 8:22 PM, Brady Powers <<a href="mailto:powers_brady@yahoo.com" target="_blank">powers_brady@yahoo.com</a>> wrote:<br>
> If we're talking about a new instruction set,<br>
<br>
Yes<br>
<br>
> and removing pieces from the<br>
> runtime,<br>
<br>
No - write a new runtime but inspired by and stealing good bits from the old<br>
<br>
then are we still talking about a minimal Erlang,<br>
or are we talking<br>
<br>
It would be a subset of Erlang - so strictly not Erlang<br>
<br>
> about something new?<br>
<br>
Yes<br>
<br>
<br>
> Because I'm sure we could all think of thing's we'd change given the<br>
> opportunity. Joe's already written Erl2.<br>
<br>
No - erl2 just compiles to erl<br>
<br>
/Joe<br>
<br>
> -Brady<br>
> On Tuesday, September 26, 2017, 12:36:04 PM EDT, Joe Armstrong<br>
<div class="m_-1660259557338679519m_-8569760955391645807HOEnZb"><div class="m_-1660259557338679519m_-8569760955391645807h5">> <<a href="mailto:erlang@gmail.com" target="_blank">erlang@gmail.com</a>> wrote:<br>
><br>
><br>
> On Tue, Sep 26, 2017 at 5:47 PM, Todd Greenwood-Geer<br>
> <<a href="mailto:t.greenwoodgeer@gmail.com" target="_blank">t.greenwoodgeer@gmail.com</a>> wrote:<br>
>> Hi,<br>
>><br>
>> 1. Are there existing TLA+ specifications [1] for Erlang?<br>
><br>
> Not that I know of.<br>
><br>
>><br>
>> Recent discussions regarding the behavior of messages for local and remote<br>
>> processes, the behavior of data in ETS, and the discussion about a new<br>
>> mini-erlang all make me think there would be great benefit in formal<br>
>> specifications of Erlang behaviors.<br>
>><br>
>> For instance, I've been thinking about writing various widgets for<br>
>> distributed applications, each with a well defined TLA+ specification, and<br>
>> then starting to compose larger and more interesting applications from<br>
>> them.<br>
>><br>
>> My workflow would look like this:<br>
>> Write widget spec -> impl widget -> Write application spec (composed of<br>
>> previously spec'd widgets) -> impl application -> profit!<br>
><br>
> Now sure about the profit bit at the end.<br>
><br>
> (write crap, sell it, sell thousands of consulting hours to fix it = profit<br>
> :-)<br>
><br>
>><br>
>> The runtime behaviors such as message passing, process linking, etc. would<br>
>> be the first level that would need specifications... so has this ever been<br>
>> tackled?<br>
><br>
> Years ago - but not in phase with the distribution.<br>
><br>
> There has always been a bit of gap between reality (C code, and what<br>
> it does) and specifications (math, and what it should do). The two are<br>
> not the same.<br>
><br>
>><br>
>> 2. Regarding the mini-erlang, I'd really like to get involved in this<br>
>> project. Perhaps I should be replying to a separate thread, but my<br>
>> questions<br>
>> are:<br>
><br>
> There is no project - just a few people discussion what they would like to<br>
> see<br>
> in a new system.<br>
><br>
><br>
>><br>
>> * What are the goals of mini-erlang?<br>
><br>
> My goal would be a tiny kernel - performance is<br>
> of secondary importance. Tiny run-time footprint.<br>
><br>
>> * How are these goals different from Erlang?<br>
><br>
> The current Erlang is not designed for a small memory footprint.<br>
><br>
>> * What needs to be removed/added from Erlang to make mini-erlang?<br>
><br>
> Remove NIFS binarys ets tables (possibly)<br>
><br>
>> * What is the current VM instruction set, and what would be the Mini<br>
>> instruction set?<br>
><br>
> Current is BEAM - Mini instruction set unknown.<br>
><br>
>> (my reason for posing these questions in this thread)<br>
>> *** Is there any interest in modeling/specifying the behaviors prior to<br>
>> implementing?<br>
><br>
> I dont' think so - the main problem is figuring out how to make something<br>
> with tiny footprint - so for example GC strategy and memory layout is<br>
> very important - I don't think modelling helps. Counting bytes on squared<br>
> paper<br>
> seems the best method (really)<br>
><br>
>><br>
>> Regarding implementation, I'm fairly agnostic. One thought is that a<br>
>> prototype could be written in anything (python, bash, java, go, c, etc.),<br>
><br>
> I disagree - I'd like the final memory footprint to be small.<br>
> c (and friends) are OK but I don't want to have to include an entire JVM<br>
> (or whatever).<br>
><br>
> Could implement it in Forth though ...<br>
><br>
>> and once the design has settled down, then anyone should be able to go<br>
>> back<br>
>> and re-write in their language of choice. Should be fairly simple since<br>
>> there would be design docs, formal specifications, test suites, etc. Then<br>
>> we<br>
>> could have mini-erlang runtime competitions/shootouts ;-).<br>
><br>
> That would be fun.<br>
><br>
> Cheers<br>
><br>
> /Joe<br>
><br>
><br>
>><br>
>> [1] <a href="http://lamport.azurewebsites.net/tla/tla.html" rel="noreferrer" target="_blank">http://lamport.azurewebsites.<wbr>net/tla/tla.html</a><br>
>> ______________________________<wbr>_________________<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/<wbr>listinfo/erlang-questions</a><br>
><br>
> ______________________________<wbr>_________________<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/<wbr>listinfo/erlang-questions</a><br>
______________________________<wbr>_________________<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/<wbr>listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>
______________________________<wbr>_________________<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/<wbr>listinfo/erlang-questions</a><br>
</blockquote></div>
</div></div><br>______________________________<wbr>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>