[erlang-questions] Any Erlang Devs Contemplating Elixir?

[Mikael Pettersson]

Torben Hoffmann writes:
 > 
 > 
 > Mikael Pettersson <mikpelinux@REDACTED> writes:
 > 
 > > [ text/plain ]
 > > Zachary Kessin writes:
 > >  > I for one would love to see an ML-family language on the beam!
 > >
 > > I'm working on a Standard ML (SML'97) compiler targeting the
 > > Erlang/OTP VM.  I hope to have it finished enough to make it
 > > public sometime this year.
 > 
 > I have been thinking about this a bit, so I'll throw in some questions. 
 > 
 > What kind of type system are you using?

The SML'97 one, with minimal extensions for interfacing with Erlang
(see below), and possibly fixes from the Successor-ML effort.

 > I have been told that a type-and-effect system would be the way to
 > capture the effects of statements on the mailboxes.
 > 
 > Have you given any thought to upgrades?
 >
 > The problem is that an upgrade can change the types, so that leads to
 > some thinking about versioning the types. Tricky business.
 > Without some attention to this it will be hard to evolve a distributed
 > system. 

Yes.  Basically, we'd need to redo type checking before allowing calls
to or from a dynamically upgraded module.  Unfortunately the VM doesn't
give us a hook for that.  I'm still thinking about the best way to
address this.  Initially I'll ignore the problem.

In fact, there isn't even a cast-in-stone mapping between SML and Erlang
modules.  While I could compile each functor or top-level structure to
a module (Erlang-like), I could also compile entire applications to
single modules (at least two SML implementations already do that).

 > And then there is interfacing to the external world.
 > My instinct tells me that it would make sense to attach some sort of
 > adapter code that will have the type signature
 > val adapt: binary -> some_type

My plan is to support something like typecase on values of type dynamic,
as I've seen other functional languages do before.  That's enough to
enable safe import of data from the dynamically typed world.

 > Which leads me to... how will you describe binary pattern matching?

Binary matching is already statically typed, so I don't see any
problem there.  binary_to_term would have result type dynamic.