Support infix functions

[lepoetemaudit]

It would be great if we could define infix functions, such as the usual suspects (>>=), <*> etc., and even |> can be implemented this way as a function (such as it is in Ocaml and Elm) instead of hardcoding it in the Elixir manner.

I had a bit of a go at hacking on the parser to allow for infix definitions and had some partial success: master...lepoetemaudit:master but it fell over when parsing any usage of the symbols as a function (it expects 'symbols' which do not include the operators, and this approach was a really inelegant hack to begin with).

I went and looked at the Elm source, which as far as I can tell distinguishes between normal symbols and operator only symbols and realised that to implement this properly we'd probably need to do the same, i.e. remove all the hardcoded infix operators in the lexing phase (and the binary << and >> delimiters are problematic too - perhaps python's b"" style of binary string quoting could be used instead?). Then we could have 'operator' strings defined in the lexer which can go into the environment map as functions, and are recognisable at definition and in usage as infix. It would be fairly easy to either provide the existing math ones as 'built-ins' that wrap the Erlang ones, or switch them out directly as of now in the parser.

I'm willing to give this a go if it is of interest. I'm in awe of the potential of having an ML on the Erlang VM.

[j14159]

Thanks for digging into this! I'd like something different than b"" for binaries as they're not just strings (initial bad idea is b{} but that's kind of gross maybe?) but otherwise I think it'd be nice to have the opportunity to jettison the notion of bif function AST nodes entirely.

[yurrriq]

FWIW LFE uses #"" for binaries. Not sure if that'd be any good here.

[j14159]

I think I'm getting hung up on overloading quotes for this but I don't have a particularly strong opinion and it's relatively easy to change I think so whatever works.

[lepoetemaudit]

What about triple angle brackets, i.e. <<< >>> - that keeps it closer to the original and it's easier to live losing that as a reserved symbol. It's true that the final decision can be postponed, though.

[j14159]

Doesn't bother me. Or use a prefix here too? Maybe # is not permitted as an operator and is reserved for prefixing other things, e.g. #{} for maps, #<<>> for binaries. Not entirely convinced of the aesthetics there, I'd say roll with what you think looks good for now and we can argue the looks later :)

[lepoetemaudit]

Definitely - I think the binary change is going to be the easier aspect anyway.

So far I've based the list of allowed operators on OCaml's: https://caml.inria.fr/pub/docs/manual-caml-light/node4.9.html - # is not among them so we would be safe using that. This is what I'm using to match the operators:

OP = [!\?=<>@\^\|&~\+\*/\$%]

[j14159]

OK, that suggests we'd still need some sort of BIFs for -, -., etc?

[lepoetemaudit]

Good point - I missed those. I'll add - and ..