Writing a new ML

[Jon Harrop]

 

I recently started writing a new ML-based programming language. I’d like a really simple implementation so I’ve started collating neat examples. Thought I’d share them.

 

Beautiful introduction to parser combinators by Scott Wlaschin (F#):

 

https://fsharpforfunandprofit.com/posts/understanding-parser-combinators/

 

Lovely articles on simple pattern match compilation by Neelakantan Krishnaswami  (OCaml):

 

http://semantic-domain.blogspot.co.uk/2012/08/pattern-compilation-made-easy.html

http://semantic-domain.blogspot.co.uk/2012/08/an-ml-implementation-of-match.html

 

Algorithm W step-by-step covers implementing the Damas-Milner type inference algorithm in Haskell:

 

https://github.com/wh5a/Algorithm-W-Step-By-Step

 

Ironically, this problem can actually be solved much more neatly in ML using mutable references. I’ll post a solution when I have one. Reminds me of Conchon’s persistent union find:

 

https://www.lri.fr/~filliatr/ftp/publis/puf-wml07.pdf

 

--

Dr Jon Harrop, Flying Frog Consultancy Ltd.

http://www.ffconsultancy.com

[Malcolm Matalka]

What's the long term plan for the language?  Recently I've been thinking a statically typed equivalent of Lua could be kind of nice.  I'm not sure if it's just reputation but there is something pleasant about Lua and I'd like that with a good type system.

--
You received this message because you are subscribed to the Google Groups "Pragmatic functional programming research" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pragmatic-functional-progr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jon Harrop]

Ø  What's the long term plan for the language?

 

Maybe make it a language for writing microservices in. And I’d like a simple language that is designed from the ground up to be developed in an IDE.

 

Here are some of the problems I am having at the moment:

 

·       Server (currently JSON over HTTP but will be FIX over TCP).

·       Low latency. The .NET GC's latency is problematic. OCaml's is insignificant, at least for now. I don't think my application (or perhaps many server applications) actually needs a GC. I've got requests coming in, processing being done and responses sent back with state maintained between messages. Requests and responses should be immutable (Erlang-style deep copy of messages). State could be retained in C++-style collections. Everything else allocated during the handling of a request could be put into a pointer-bump heap and deallocated en-masse when the response goes out to minimize latency.

·       Serialization. Hopelessly inefficient with both OCaml and F# and the performance bottleneck in my app. Data is read into a ring buffer efficiently at the OS level. Then it is copied out inefficiently by the VM. Then substrings are copied out by the library in order to parse them into ints inefficiently. I'm currently even going via an explicit OCaml representation of JSON too, which is crazy inefficient. The language should provide in-line parser generation targeting asynchronously-filled ring buffer of bytes.

·       Data structures. The core is an in-memory database. Each row is a record. The database is currently a bunch of Maps and Sets that let me add, remove and search for rows efficiently. I have to write and maintain all of this by hand (it is most of the code now!) but it is robotic. The language should be able to maintain a database of values indexed accordingly on my behalf and I should be able to update it and backtrack at will.

·       OS. I have Ubuntu boxes in the cloud, Debian on my desktop and Raspbian on Raspberry Pis. Latency to the cloud is too long so it makes development painful. Rebooting my desktop into Debian is painful. So I want my entire development environment running on a Raspberry Pi and I also want to use this language to teach my son programming.

·       IDE. The OCaml development environment sucks. The problem is that the OCaml language and tool stack was never designed to facilitate a modern graphical development environment. So I want this new language to be designed to support an IDE from the outset.

 

I’m thinking of features like:

 

·       Simple ML-like language: tuples, unions, pattern matching, parametric polymorphism, type inference with Algorithm W.

·       Fix OCaml's type system flaws: Per-type equality, comparison, hashing, pretty printing and serialization with generic type constraints

·       Fix OCaml's major ugly syntactic corners: match...with...end.

·       Overloaded arithmetic operators like F#.

·       Self hosting: the language should be able to parse and interpret itself using code as similar to the original as possible.

·       IDE

·       Easy to build. No bespoke command-line builds like the F# compiler.

·       Inline lexing and parsing like Camlp4 parsers

·       Reflection

·       View patterns (aka active patterns in F#)

·       JIT compiled REPL. Rather than having separate REPL, bytecode compiler and native code compiler the language should just use one single evaluation engine: a JIT compiled REPL.

·       Documentation shouldn't be limited to ASCII art. I want multimedia documentation.

·       Libraries shouldn't be obtained from a package manager like opam or Nuget but, rather, directly from Github.

·       Purely functional data structures aren't particularly good at anything except persistence. So the core collection shouldn't be something specific like a single-linked immutable list but, rather, some kind of jack of all trades and master of none collection type that allows all sorts of different operations (random access, concatenation etc.) in log time.

[ma...@elmalabarista.com]

I will love to see this working.

I'm already doing something like, however I'm new at language design. My idea is a relational language, oriented at data /crud/ database work. My goal is try to resurrect the "spirit" of the xbase family (where working with data/tables was natural and not something to fear or consider "boring").. 

Do you plan to do this open source? Make a kind of conversation around? 

I have research a lot for this (https://gist.github.com/mamcx/e1743571b9a1ea163a7f9f07aa6a8ae2) but moving form a basic calculator and lambda interpreter to the next stages (where exist try/catch, AGDT, match clauses, etc) is hard. 

[Michael Robin]

>  The .NET GC's latency is problematic

I'm surprised to hear you hear that -- I thought I recall you defending .Net GC (and GC in general) in your blog. (Though may be in a different context.)

> Self hosting: the language should be able to parse and interpret itself using code as similar to the original as possible.

Good meta-programming support would be great.

Are you talking about a fully homoiconic language, or something reasonably regular?

A base/level-0 language with a nested tuple/term/s-expr structure and a Prolog-like operator precedence parser to add syntax with system- and user-definable precedence and fixity, etc., for operators would be great. 

Macro/transformation/eval-when  support. Mini-language embedding, using syntactic and/or generalized F# workflow-style constructs.

Support for custom literals. Self-evaluating literals/atoms/keywords.

> Purely functional data structures aren't particularly good at anything except persistence....some kind of jack of all trades and master of none collection type that allows all

Doesn't a clojure-style Vector give you persistence as well as the other qualities your looking for? (a la http://hypirion.com/musings/understanding-persistent-vector-pt-1)  

To unsubscribe from this group and stop receiving emails from it, send an email to pragmatic-functional-programming-research+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Pragmatic functional programming research" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pragmatic-functional-programming-research+unsub...@googlegroups.com.