Tuesday, July 31, 2012

Elalang

I came across Elalang on LtU, which apart from meaning Hi language in Greek, has a lot more in common with my language than I thought. The language is a strict, sometimes lazy, dynamic variant of ML or Haskell. It runs on .Net by compiling to bytecode for the CLI.

The funny thing is that I designed the Hi language to be executable even if you erase all types. Apart from that that gave me the time to experiment with the typechecker while bootstrapping the language, it also means that when you would compare the informal cores of both languages, Ela Core would implement an extended form of the Hi language. Basically, untyped lambda calculus evaluated strictly with some Haskell class like mechanism for dynamic dispatch, where Ela Core would be more expressive since it allows to dispatch on the return type of functions. A good thing for generality, but something I didn't design into Hi since I wanted a simple mechanism to dispatch on the type of values; basically following OO in order to make it possible to bind to C++ libraries without too much problems. Hi has OO like interfaces, not Haskell, or Ela, like type classes.

(The meaning of the above: I could simply translate Hi to Ela with some syntactic transformation on the source code; i.e., almost by copy pasting Hi source code. The OO like interfaces also imply I can typecheck with an adaption of F<:. So I guess I should stop mucking about and just implement a version of that; mind you, not even that is trivial.)

I am not sure about robustness or performance of Ela. I read it emits bytecode for a stack machine, which shouldn't be possible, higher order programming implies you'ld normally want some kind of heap.

(What I forgot to say. I like Ela. The fact that it is a dynamic variant of Haskell is really, really nice. You can do tons of tricks you can't do in a strongly typed language, and the runtime performance penalty can't even be that big, in theory, since it's all tagged graph manipulation abstractly anyway.)

3 comments:

  1. Ela runs on the top of its own virtual machine (stack based), so it is basically an interpreted language (like, say, python). You shouldn't expect rocket speed from it, but, despite .Net, its performance is pretty comparable with other interpreted languages. For example, this article contains a small benchmark of "functional python" vs. ela:
    http://www.codeproject.com/Articles/158068/Ela-functional-programming-language
    That should be quite convincing :)

    If you want to prototype a functional language, Ela (or EIL, Ela byte code) might save you time. You can ask questions, in Ela news group:

    ReplyDelete
  2. A "missing link":
    http://groups.google.com/group/elalang

    ReplyDelete
  3. I didn't notice you posted here. Python speed? As far as I know, Python runs about 20 times slower than most interpreted languages... My current language has about unoptimized Javascript/Lisp speed, so I am not that interested.

    In case of the Hi compiler, speed isn't really the problem, it is the verbose representation of literals and the verbosity of the generated code which makes the language impractical at the moment.

    ReplyDelete