Karl Nilsson

@tsloughter yes I am leaning towards using the `array` module for any non-binary types with a `fez` specific `Array.setElement` function that returns the array. The problem is that fsharp arrays...

Erlang (or rather hipe) has mutable arrays but only of immediate types. See hipe_ bif Probably not a practical approach though. On Wed, 27 Dec 2017 at 16:46, Tristan Sloughter...

Yes lots of unsupported/not implemented apis here. In general FSharp.Core is patchily implemented and I wasn't planning on even attempting to support System.* as it is very OO / imperative....

Well we'll see how far we can take it but `System.*` is a .NET thing and fez isn't. I don't know how fable are covering System but I can't imagine...

The problem will always be mutation. Supporting the non mutable subset would be possible but ideally as a separate optional set of erlang modules. On Sun, 18 Jun 2017 at...

And that will be possible the more functional your approach is. Sure we can probably rewrite imperative code using recursion. We may even be able to support local mutable fields...

ok I was playing with this earlier and accidentally committed `soduku.fs` to the master branch. I had to make two minor changes and now it compiles but it won't run...

I hacked up a potential process dictionary backed `List` implementation. Again it suffers the same shortcoming as ref cells and lazy in that there is no gc. https://github.com/kjnilsson/fez/commit/dd633915ff95086c515756eac7fdadeebfcdc3ec

Thanks for the comments. Fsharp async (and c# async for that matter) is mostly a hack around the fact that .NET allows you to block the calling thread when doing...

See my comment in #34