Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Sudoku solver #10

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

[WIP] Sudoku solver #10

wants to merge 1 commit into from

Conversation

forki
Copy link
Contributor

@forki forki commented Jun 17, 2017

after applying #9 I tried to compile my sudoku solver. but no luck:

image

@kjnilsson
Copy link
Owner

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()).

n * count + m

let boxes (sudoku:Sudoku) =
let d = sudoku |> Array.length |> float |> System.Math.Sqrt |> int
Copy link
Owner

@kjnilsson kjnilsson Jun 17, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

instead of System.Math.Sqrt we can implement sqrt in Microsoft.FSharp.Core.Operators.erl (or whereever that lives in FSharp.Core).

let start = System.DateTime.Now
let solution = getFirstSolution sudoku

printfn "%As" <| System.Math.Round((System.DateTime.Now - start).TotalSeconds,2)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of System.DateTime use interop to call the erlang equivalent (erlang:system_time/1).

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternatively you could try creating an erlang module named System.erl with a DateTime.Now/0 function in it. That might work as well as fez will translate calls in that way. (check .core output for what it actually worked out).

@forki
Copy link
Contributor Author

forki commented Jun 17, 2017

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.

@rascala
Copy link
Contributor

rascala commented Jun 17, 2017 via email

@kjnilsson
Copy link
Owner

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.

@forki
Copy link
Contributor Author

forki commented Jun 18, 2017

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

@forki forki closed this Jun 18, 2017
@forki forki reopened this Jun 18, 2017
@rascala
Copy link
Contributor

rascala commented Jun 18, 2017 via email

@forki
Copy link
Contributor Author

forki commented Jun 18, 2017

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.

@kjnilsson
Copy link
Owner

kjnilsson commented Jun 18, 2017 via email

@rascala
Copy link
Contributor

rascala commented Jun 18, 2017

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)?

@forki
Copy link
Contributor Author

forki commented Jun 18, 2017

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

@kjnilsson
Copy link
Owner

kjnilsson commented Jun 18, 2017 via email

@forki
Copy link
Contributor Author

forki commented Jun 18, 2017 via email

@forki
Copy link
Contributor Author

forki commented Jun 19, 2017

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?

@rascala
Copy link
Contributor

rascala commented Jun 19, 2017

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.

@forki
Copy link
Contributor Author

forki commented Jun 19, 2017

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

@kjnilsson
Copy link
Owner

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>.

@kjnilsson
Copy link
Owner

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants