Comparing OCaml and Standard ML

including mythryl, a sml/nj derivative with c-flavored syntax to the comparison would be interesting. see http://mythryl.org/ for further info.

> Have a look at the 'Multicore OCaml' presentation here: https://ocaml.org/meetings/ocaml/2014/

I just watched it. Great to see somebody else trying but this is no more advanced than OC4MC and they are using Fibonacci as an example when I already used a complete parallel ray tracer with shared memory when benchmarking parallelised HLVM code:

http://flyingfrogblog.blogspot.co.uk/2010/01/naive-paralleli...

They've got a lot of catching up to do before they can overtake and I'm concerned that retrofitting a modern GC on a 20th century VM will never work because OCaml has such poor locality of reference due to massive unnecessary boxing.

> TBH I don't miss multithreading in OCaml,

I said multicore, not multithreading. I dot lots of concurrency and parallelism in F# without having to worry about multithreading.

> if you write applications which expose some sort of API over a socket that will scale to clusters not just multicore.

You're proposing deep copying all of your data structures when multicore programming is all about sharing data between cores using shared caches. If you copy then your identical copies of the data compete for space in a shared cache.

> And you can program those kinds of applications quite nicely with Lwt or Async already.

Lwt and Async are for concurrent programming. In particular, they are extremely slow.

> Regarding FFI, ocaml-ctypes is interesting, it allows you to bind to a C library at runtime using pure OCaml (and a wrapper around libffi), or to generate C stubs.

Ctypes looks great. Didn't exist when I last used OCaml.

> Regarding OpenGL there is a new binding called 'tgls' for OpenGL 3.x/4.x (besides LablGL) that is mostly generated from the XML description of the OpenGL APIs.

Has anyone tried to write anything much using it?

So, I think my ideas about syntax are similar in their goals, but different in some details.

1) I experimented with Pratt parsers, and actually made a great, extensible, full-blown parser, but the devil was in the details - if you parse your whole language with a Pratt parser, you have to get the operator/keyword precedence and associativity just right. It's probably possible to get it just right, but the problem with Pratt parsers is that you just don't know it; in particular, you don't know if your syntax has any ambiguities (i.e. things that might not parse the way you want them to).

2) Because of that, I abandoned Pratt parsers and went back to LALR(1) (yacc). It's tedious and complicated, but it has the nice property that it notifies you of all syntax ambiguities, a property that I haven't found in any other parsing system (recursive descent/LL, Pratt, PEG). Of course, some people say that PEG is unambiguous, but these people are either stupid or ignorant; PEG just doesn't tell you where the ambiguities exist, and always takes the first choice. LALR is "not ambiguous" in the same way, in case of shift/reduce conflict it always chooses shift, in case of reduce/reduce conflict it chooses the first choice, but at least it tells you where the choices were made, so that you can examine and fix them.

3) LALR(1) is also quite stupid and limited, which is why Menhir has been a blessing - it's practically as efficient as ocamlyacc (in theory, at least - ocamlyacc produces compiled C code, while Menhir produces OCaml with Obj.magic), but parses LR(1) instead of LALR(1), which makes writing grammars for it much easier, and produces nicer error messages. I've managed to write a very flexible, Julia-like syntax (except with {} instead of begin/end) that supports tuples, arrow function syntax, and pattern matching.

4) Extensibility is important for me, but I intentionally want to limit it - I don't want programmers to be able to (re)define basic language syntax, like ` = `, as that could fragment the code and make the syntax unpredictable/ambiguous. However, I want to include user-defined operators (with custom precedence/associativity), which could be done using an embedded Pratt parser, and Julia-like macros that are always preceded by `@` and can only be used in a few predetermined forms (function calls/statements/blocks). I think that makes the syntax much more manageable and readable. Also, I don't like Elixir's syntax, to many semicolons/`do:` keywords. I haven't actually implemented the above yet, but I think it could be done within my current Menhir parser infrastructure.

Another thing: I too strongly discourage the name Meta, especially for OCaml, because there is already a project that's called MetaOCaml.

The hyrax. A very cute animal that can scale sheer rock faces.

Nope, none of what you describe equates to 'complexity', there just happens to be more 'stuff' (unless you consider other, more popular languages with even more tools/libraries to be even more complex, in which case we have different viewpoints on what that word means in this context).

Sure, not everything is in opam and that can be quite frustrating but the improvements over the last few years have done a lot to reduce the pain that people experience (not increase it). Seriously, would you rather have the old ecosystem back? I know a large number of devs who would be quite hostile to that idea.

The standard library question isn't new and has been going on for some time but the options now are substantially better then they ever have been. Ask around and get feedback from others on what might suit your needs best. Until the community naturally converges on something, this is just how it is.

> "And unfortunately, it didn't work on my particular mac with homebrew."

So what went wrong? The instructions for homebrew are two lines and my experience here was flawless. The slew of instructions you point at are largely for Linux distros and most of those are also only a few lines. Were you trying any of these? It's clear that the install page you point to needs work (who still uses fink?) but in most cases it's just a time-consuming process, rather than a difficult one (i.e you just sit there while things compile). If something goes wrong, then reporting it on the list [1] or issue tracker [2] will help others to fix it.

[1] https://sympa.inria.fr/sympa/arc/caml-list

[2] https://github.com/ocaml/ocaml.org/issues