kjnilsson/fez

F# to core erlang compiler experiment

fez's Issues

Strings Module and repl questions

Hi Karl,

I have been adding some more wrappers to the String library.
Plan start working on some basic regex after that.
I have some experience with elixir and not much with erlang, but so far so good.

Have you had any thoughts about a repl with code-loading and inspection?
Connecting to a running process would imply marshalling/unmarshalling erlang data.
I think type-providers would probably work very well there(especially with remote processes)

Char module and FFI

Hi,

I have been working on a rudimentary System.Char module.
But the method names are all capitalized.
I have uncapitalized(?) them for now, but that raises a question.

Do we have any ideas on an FFI for this?
It would also solve the string() operator issue #6 (dispatch to different functions with same arity but different type signatures) without having to make it a special case in the compiler.

Problem compiling with OTP 20

Hi I'm getting a lot of error in sys_core_dsetel when trying to compile the core code.
I'm not sure if it's a bug in OTP 20 or the outputted code. Here is an example.

Function: let_rec/1
basics.core: internal error in sys_core_dsetel;
crash reason: {case_clause,
    {'EXIT',
        {{case_clause,
             #{'__arg10' => 5,'_acc0' => 0,'_h0' => 0,'_l0' => 0,
               '_tail0' => 0,
               {'_filter0',2} => 0}},
         [{sys_core_dsetel,visit,2,[{file,"sys_core_dsetel.erl"},{line,99}]},
          {sys_core_dsetel,visit,2,[{file,"sys_core_dsetel.erl"},{line,153}]},
          {sys_core_dsetel,visit,2,[{file,"sys_core_dsetel.erl"},{line,132}]},
          {sys_core_dsetel,visit,2,[{file,"sys_core_dsetel.erl"},{line,145}]},
          {lists,mapfoldl,3,[{file,"lists.erl"},{line,1354}]},
          {sys_core_dsetel,visit,2,[{file,"sys_core_dsetel.erl"},{line,189}]},
          {sys_core_dsetel,visit,2,[{file,"sys_core_dsetel.erl"},{line,132}]},
          {sys_core_dsetel,visit,2,
              [{file,"sys_core_dsetel.erl"},{line,136}]}]}}}

  in function  compile:'-select_passes/2-anonymous-2-'/3 (compile.erl, line 578)
  in call from compile:'-internal_comp/5-anonymous-1-'/3 (compile.erl, line 342)
  in call from compile:fold_comp/4 (compile.erl, line 369)
  in call from compile:internal_comp/5 (compile.erl, line 353)
  in call from compile:'-do_compile/2-anonymous-0-'/2 (compile.erl, line 177)
  in call from compile:'-do_compile/2-anonymous-1-'/1 (compile.erl, line 190)

Object constructors

Currently object constructors return unit as is their signature. We need to intercept this to instead return an appropriately object formatted tuple containing the appropriate fields.

How to gauge possibility of using?

Let's say I wanted to compile Logary (the core library) with Fez; can it be done? It depends on NodaTime and Hopac and FSharp.Core so it has minimal dependencies IMO.

Compete MapModule

Only a few functions left.

https://github.com/kjnilsson/fez/blob/master/src/Microsoft.FSharp.Collections.MapModule.erl

string() operator should only work for non-strings

Hi,

There is a mismatch between the behaviour in fsharpi and fez for the string() operator.
fsharpi does not escape and stringify if the input is string("abc" -> "abc"), but fez does("abc" -> "\"abc\"").

Looks like we can't call different functions based on the type signature as the erlang wrappers don't have access to the types.(or can we?). And even if we could switch based on types, data received from other erlang processes wouldn't have that info, so are they supposed to be strings or just happen to be printable?

I have an implementation of string() which uses printable_unicode_list() and printable_list() and does not re-stringify them.
Should we go with that for now?

-- Siddarth

Complete SetModule

https://github.com/kjnilsson/fez/blob/master/src/Microsoft.FSharp.Collections.SetModule.erl

Currently it uses a map internally. Perhaps it would be quicker to just use erlang's sets module instead although it is likely to be less efficient. Alt finish module using maps.

Handle tuple function arguments

When we've got a function like this for example:

let f (x:int) (y:int * z:string) -> ... it gets translated into a function of arity 3. This works fine for fez to fez function calls but breaks in interop scenarios where one of the arguments is a genuine tuple. Eg ets:insert/2.

To fix we should make functions with tuple args use the correct arity. This means that methods now will take a tuple with the method args rather than straight method arguments. This is a micro-inefficiency I am prepared to take for the sake of simplicity.

Option for correctly bounded numerics

Currently all fixed size fsharp numerals map onto erlang integers and floats. We should provide either a compiler option or a custom compiler directive to insert the appropriate bit masks where arithmetic operations are performed.

Correctly flatten lambdas passed to lesser arity functions

Consider a function: f int -> int -> int being passed as a higher order function requiring fewer arguments. This fails as we flatten the lambda into a function with the same arity. Can we inspect the required type and only flatten "as much as needed"?

erlang.mk plugin

See the same task for rebar3

#31

Functions returning objects or records

Hi,

I have been looking at implementing the Regex module.
How would I go about returning objects?
(ex: Match object, with .Success, .Groups, .Captures etc.)

Do I just return a map or a record?

RFC 1: Arrays

Arrays have no direct equivalent in core erlang. A lot of code that uses arrays can be quite directly translated to using lists instead (fsharp Lists or Seqs). The exception to this is code that mutates the array directly. That said a lot of code may use arrays and it would be good to cover arrays in some shape or form.

The most direct equivalent of erlang's binary() type is the byte array so it would make sense to translate operations on byte arrays to operations on binaries.

Arrays are generic so this leave a lot of types uncovered. Should the non mutable aspects and apis of Array.* that aren't byte arrays simply be translated as erlang lists? Are there any other options?

Implement FSharp List module

Current Definition of Option Type

I have seen that the current implementation of the option type in the erlang modules is defined as follow :

-type option() :: term() | undefined.

I do understand that you want options to be erased however when I then see the implementation of the get method :

get(O) when O =/= undefined ->
    O.

Then for me the type is more :
-spec get(option()) -> option()
than what is specified which was :
-spec get(option()) -> term().

Is there something I am missing there?

P.S :
What I would have thought was to design the option type as a couple as follow :
-type option() :: {some, term()} | undefined

Alpaca

The primary aim is to implement enough of the language to evaluate what how well an ML type of language could become a practical language for writing code to be run on the beam.

https://github.com/alpaca-lang/alpaca

rebar3 plugin

Not sure exactly what form this would take but I see there are other language plugins available, e.g. for LFE and it would be nice to provide something similar.

Part of this task may involve changing the compiler api to make it better support working as a plugin.

https://github.com/lfe-rebar3/compile

Allow to set out folder in fezc

RFC 2: Async

All IO in erlang is "async" (non blocking) so for that kind of code async can effectively be erased.

In the case of Async.Start* we could potentially compile these to spawn new processes to provide parallelism. It would require careful design but may be worthwhile.

Highlight stuff that already works in the readme

it's hard to find it in the samples right now.

Add module_info to generated modules