I've been thinking about this as well because functional languages should provide a great basis for exploiting multi core systems. You can run the evaluation of a "top level" function like `update` in a bump arena allocator — and can even re-run the function safely if the arena turns out to be too small — and then copy the results out to RC space. This helps with passing data to parallel evaluators. It provides rapid collection for large external resources like images. All really nice.
But Elm can produce circular references in the form of mutually recursive functions. In fact, a self-recursive function has a circular reference albeit a special case one that could probably avoid a reference count addition. An ability to recognize function free data structures — useful for safe equality checks as well — could help but consider that effects manager states are not function free nor are Html node structures. So, now you have to partition the persistent world into GC data and RC data. There might still be benefits in terms of handing off RC data between processors but the introduction of GC eliminates the possibility of rapid collection. What I haven't dug into us whether the mutual references in functions can be managed by having all of the functions belong to a let context object that they know about and which gets special handling in the reference count design. If that could be made to work, we'd be back into a reference counting friendly space. Mark > On Mar 17, 2017, at 3:26 PM, 'Rupert Smith' via Elm Discuss > <[email protected]> wrote: > >> On Thursday, March 16, 2017 at 5:06:59 PM UTC, Rupert Smith wrote: >> I am guessing the answer is no. >> >> type alias Reader { borrowing : List Book } >> type alias Book { reader : Maybe Reader } > > My observation about this is that with statically typed languages, the > underlying programming language is usually prevented from doing things by the > type system to make it more safe. > > In this case, the type system will happily accept something, but it is the > operational specification of the programming language that restricts what the > type system allows. > -- > You received this message because you are subscribed to the Google Groups > "Elm Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
