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. I'd suggest you rewrite it in a more functional style using only the standard fsharp library. There is no benefit with using stuff like ResizeArray as the only way to support it would be to translate it into a functional equivalent using lists. Also replace Arrays with Lists as there is no erlang equivalent. (well I am thinking we could eventually map byte array to bitstring()).

One of the really really great things about fable is that it replaces all such things and the Sudoku solver just works in Javascript.

My personal dream would be that I can take my domain model code und just compile it to beam. Without mapping all the apis manually. I know that's a very long way. But that would be a nice goal.

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 it being anywhere near complete. It should be easy enough to cover the bits you need on a case by case basis or rewrite code in a functional style. For example mutation doesn't exist in core erlang so code that uses it just won't translate which is the main reason this code does not compile. Any attempt to emulate it are likely to be worse than writing it functionally which makes me reluctant to do it at this point. Same with subtype polymorphism. Although there is some limited support for interfaces and methods already on records and DUs.

I could imagine System being supported through a separate library with System modules being implemented in erlang. Still mutation will be an issue here as well but simple static methods would work ok.

@alfonsogarciacaro could you please comment a bit a out how fable deals with this? Or give some pointers? Thx

Yes fable doesn't support every api in the BCL. But enough to be super useful and to basically allow me to transpile our complete domain model without rewrites.

Yes, we probably need to change how we approach the problems a bit.

Makes it more interesting 😄
One erlang way to write a sudoku solver would probably be to have each cell as a process with their co-ordinates and a set of possible values, and whittle the set down by talking to the others in the same row/column till they converge(or not)?

Just to make this super clear. My problem is not to write a Sudoku solver. This is just some random snippet.

My interest is to use existing domain code and run it in things like Phoenix. This would allow me to use the same domain logic in my Javascript clients, my suave app and if needed I can port it to a different platform when I have good reasons for that

sorry if the following is completely stupid.

Can we use ETS tables to emulate Lists and dictionaries? https://elixir-lang.org/getting-started/mix-otp/ets.html

Maybe something along the lines of:

type List<'a>() =
 let name = createRandomName()
 let self = emit (sprintf ":ets.new(:%s, [:named_table])" name)
 emit (sprintf ":ets.insert(:%s, {\"list\", [])" name)
 with
 member this.Item(pos:int) : 'a =
 let current = emit (sprintf ":ets.lookup(:%s, \"list\")" name)
 current.[pos] :> 'a
 member this.Add<'a>(x:'a) =
 let current = emit (sprintf ":ets.lookup(:%s, \"list\")" name)
 let all = x::current
 emit (sprintf ":ets.insert(:%s, {\"list\", all)" name)

Maybe this is not the nicest thing on earth, but could it work? as a first hacky version?

I think its doable with some caveats.

ets is a bit tricky, the table-names are global to all processes.
So we would need to use name-mangling and manage that internally.

And the table exists till the parent process gets killed, or the table is sent a delete message.
Maybe that could be done using finalize()?

There also seems to be a upper limit on number of tables per erlang node(around 1400 by default).

This seems like a good idea to get around some of the places where it is impossible to do things immutably.
But I'm afraid people might overuse this. 😨

Although having a nice f#ish wrapper around ets for in-memory storage would be fantastic!!
With type providers hooking into ets tables etc.

it was an idea to get things started. maybe someone can implement it and later we improve on it

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 as it is calling a load of unimplemented apis. If anyone feels like it you can compile it and look at the soduku.core file to see what erlang/elixir modules and functions would need to be implemented to make it work.

er ETS - they don't have to be named but it may be better to use the process dictionary to implement List<T>.

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.

dd63391