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

v0.1 - OCaml on the BEAM #6

Closed
61 tasks done
leostera opened this issue Oct 9, 2020 · 1 comment
Closed
61 tasks done

v0.1 - OCaml on the BEAM #6

leostera opened this issue Oct 9, 2020 · 1 comment
Assignees
Labels
compiler Related to the OCaml to Erlang compiler tracking

Comments

@leostera
Copy link
Owner

leostera commented Oct 9, 2020

Summary

I have not found an easy way to lay out what a release for Caramel should look like, so I'm sketching out this issue with a a big checklist of stuff that I think could be somewhat usable for pure-OCaml modules.

To do this we need:

  • the core type language, excluding support for the fancier features of the type system (like GADTs, or universal quantification in records), so variants, records, tuples, and type parameters.

  • immutable, functional ocaml, excluding all the imperative and object-oriented features, and some features like recursive let bindings which have no direct translation to Erlang

  • enough pattern matching so we can work with all the values allowed by the core type languages

  • support for modules, but not as first class values, and without functors or inclusions

This could already be enough to write some OCaml on the BEAM successfully. We'll see once we get there.

Checklist

To make it easier to keep track of what's what and where we currently are, here's a list of the features that are currently working and missing. Where necessary I'll try to make separate issues and link them here.

Idioms

  • Empty tuple () is a common value in OCaml, this is translated to the atom ok in Erlang. This is not entirely idiomatic, since some functions are generated that take for last argument the atom ok, but it is much nicer for the returned values.

  • OCaml let rec's inside of a module-level function definition should be reported as errors. It is common in OCaml to define a recursive helper function to traverse a value using a default accumulator that is hidden from the user, but we can ask the programmer to move this outside for now. See Forbid let rec inside of a let binding #13

  • OCaml allows ' (prime) to be used as part of variable names, so it's not uncommon to see x and x' and x''. The equivalent Erlang would be X, X1, and X2, primarily because the single quote is not a valid character to have in a name. See Ensure OCaml variable names are translated to valid Erlang #15

  • OCaml allows shadowing of names, which is not supported in Erlang. so that let x = 1 in let x = x + 1 in x yields 2. The equivalent Erlang would crash. See Forbid name shadowing through let binding  #16

Module System

The goal here is to support the basic OCaml module system, with its nesting and aliasing to provide a flexible and safe way of structuring large amounts of code. Module interfaces should be allowed to dictate what is exported and what isn't.

  • Modules definitions -- we treat files as modules, and we can create nested modules. Nested modules will be flattened out into separate Erlang modules namespacing the module names. Modules without exports should generate no Erlang sources.

  • Module interfaces -- interface files will be respected and anything that is not exported there will not be exported in the generated Erlang source. This applies to both types and functions.

  • Module Declarations -- only functions will be allowed at the module level. Defining values should be an compilation error.

Type Language

These are the features of the type-language that I'm aiming to support and compile to Dialyzer specs.

  • Type variables
  • Phantom types -- should be turned into an unused type-variable that will be properly named with an underscore.
  • Variants -- compiled into constructor_atom or {constructor_atom, arg0, arg1,...}
  • Polymorphic Variants
    • Explicit constructors -- compiled into constructor_atom or {constructor_atom, arg0, arg1,...}
    • Inherited constructors
  • Tuples
  • Aliases
  • Records
  • Function types
  • Interface files constrain exports of types

Expressions

The following expressions will be supported on the OCaml side

Patterns

These are the patterns that we can use on the left side of match branches and function headers.

  • Ignore value
  • Binding to variables
  • Tuple
  • List
  • Records
  • Variants
  • Polymorphic variants
  • Exact match

Foreign Interfaces

  • Support for external
    • without a name override
    • with name overrides
@leostera leostera added this to the OCaml on the BEAM v0.1 milestone Oct 9, 2020
@leostera leostera self-assigned this Oct 9, 2020
@leostera leostera added the compiler Related to the OCaml to Erlang compiler label Oct 9, 2020
leostera added a commit that referenced this issue Oct 14, 2020
In order to continue building the standard library of FFIs to Erlang, I
had to add support to replace the name of a function for the appropriate
external name.

For example, the function `maps:new()` in Erlang would mean that we need
a function `Maps.new ()` in OCaml. This unfortunately won't work since
`new` is a reserved word.

However, by allowing the programmer to choose the final name to be used
by the FFI during the translation process, we can make the OCaml
function have a different name.

```ocaml
(* file: maps.ml *)
external make : unit -> map = "new"
```

Using `Maps.make ()` will compile to `maps:new()` in Erlang.

Works on #6
@leostera
Copy link
Owner Author

Aaand we're there. Closing this now.

I'm thinking that the next milestone will include no more work on this particular compilation chain, but rather on the inverse process: parsing and type-checking Erlang.

Thanks @nyaray for the push there to scope things more clearly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler Related to the OCaml to Erlang compiler tracking
Projects
None yet
Development

No branches or pull requests

1 participant