An idea about infix functions.

[AnthonyJacob]

Infix functions as a syntactic sugar can be burden for the compiler. On the other hand they make code much more readable.

So what if we allowed only infixr, infixl and infix (you could not specify precedence) and the type would be inferred by compiler (you cannot specify it yourself):

• contains > => it is infixr
• contains < => it is infixl
• contains both or none => it is infix

So for example $> and >>= is infixr, <$ is infixl, <$> and == is infix.

listL = cons => nil => (cons 1 (cons 2 (cons 3 (cons 4 nil))))

listL = (:>) => nil => 1 :> 2 :> 3 :> 4 :> nil

listR = cons => nil => (cons (cons (cons (cons nil 4) 3) 2) 1)

listR = (<:) => nil => nil <: 4 <: 3 <: 2 <: 1

[VictorTaelin]

Two problems:

1. What exactly are infixr and infixl in terms of ADT? If they're not ADT additions, just part of a syntax, then how do you recover the original syntax after translating to binary Moon?

2. Are they global modifications of the syntax (i.e., as soon as they're typed, the whole syntax changes)? There is no similar mechanism for that in Moon currently. Is it OK? Will it mix well with the self-contained imports we currently have? How to implement it safely?

[AnthonyJacob]

1. I think it should be just syntactic sugar. Moon also does not keep new lines, so your pretty formatted file ends up as one liner. Unless you add some pretty printer which puts every expression on new line - this pretty printer should also rewrite ((:>) 2 ((:>) 1 nil)) as (2 :> 1 :> nil).

2. I am not exactly sure what you mean. We would just need to change the parser to read (/ 2) as (x => x / 2) instead of current (x => 2 / x) which can be expressed as ((/) 2) or (2 /).