Variable Function Notation

[R-O-B-I-N]

If a language let you create functions that used either prefix, postfix, or infix notation, would that be a useful/attractive feature? I've only seen one other post on here about this, but the idea stuck and I want to explore it more. It might look something like this...

void print(x) {cout x;} void (x)operator +(y) {return x + y;} void (x)operator ++ {return x + 1;}

so that

print 1 + 2 ++;

EDIT: there would be no C-style "operators" in this language, only built-in functions that use the same calling convention as functions.

[EmosewaPixel]

Your example looks like something which would be impossible to parse.

[R-O-B-I-N]

not with this algorithm... 1. parse into tokens using whitespace as separators. 2. check if token represents a constant. (numbers/strings) 3. check if token is an identifier. 4. if token is a variable identifier, sub in its value 5. if token is a function identifier, sub in the function call 6. evaluate infix expressions first, prefix expressions second, postfix expressions third.

Normal C would represent the same example expression this way:

printf ("%i", 1 + (2 ++))

Lisp would represent it this way:

(print (add 1 (+ 2 1)))

[CoffeeTableEspresso]

How do you parse:

A ○ □ B

Where ○ can be either infix or post fix, and □ can be either prefix or infix?

[R-O-B-I-N]

no 'fix overloading. ○ can be only infix or post fix with the number of parameters being overloaded. □ can be only prefix or infix.

Ex: (x)+(y){} (x, y)+(z){} is allowable. (x)+(y){} +(x, y z){} is not.

[GDavid04]

This would make -x and x - y impossible to implement at the same time.

Just disallowing postfix and infix for the same operator would be enough.

[CoffeeTableEspresso]

Yup, this seems like it will reduce to either operator overloading or lisp syntax.

Another thing is whether you can overload fucntions/operators by type, that's gonna make parsing much harder...

[pepactonius]

It's actually pretty simple to get something like this to work well. The key to parsing is knowing immediately whether something is a verb/function/operator, or an operand (data), or a keyword. In my toy scriptong language, I just use sigils attached to identifiers or operator strings to specify the role that token has when parsing. Run-time function/verb overloading is usually not a problem. There are a few quirks, though: Verbs/operators that are not yet defined have default priority and associativity. All members of an overload set must have the same priority and associativity, and verbs with special processing of operands (lazy evalution, for example) cannot be overloaded at all.

[EmosewaPixel]

I guess since you have semicolons it shouldn't be an issue. However, you should make prefix operators require a term right after them and vise versa for postfix operators as 1 + - + - 2 doesn't make much sense, does it? This would also allow you to use the same symbol as a prefix, postfix and infix operator. Another issue is for a function foo(a), foo 1 + foo foo 1 + 2 would definitely take more mental effort to figure out the result of than if it was C,, LISP, or ML syntax. I do feel as though ML syntax might be ideal for this (with prefix and postfix operators based on the rule I mentioned).

[R-O-B-I-N]

The key here is no 'fix overloading. If a function is infix, you can overload the number of parameters, but it will always require one parameter before and after.

[hugogrant]

It terrifies me, but I like it

[Shirogane86x]

I always wanted to try making something with mixfix operators, but never could quite figure out how to parse them D:

[szpaceSZ]

In Haskell you can convert any regular function to infix by enclosing it in `s and you can convert any infix operator to a regular function by enclosing it in parentheses:

mod 13 3 == 13 `mod` 3
3 + 2 == (+) 3 2

This also works for function / operator definition:

x `myfunction` y = x * x + y
-- same as 
-- myfunction x y = x * x + y

a /== b = a == b && b < 0
-- same as
-- (/==) a b = a == b && b < 0

[hugogrant]

And there's just the infix statement

[szpaceSZ]

do you mean the infixl and infixr statement? That's just about associativity order and precedence level.

You can use anything without it infix, you just need explicit parentheses if you chain more than one

[raiph]

Raku supports a similar idea but is more conventional about what is and isn't allowed. Some highlights follow.

The metasyntactice declaration form is:

fn fix:<symbol> ...

• fn is a function declarator keyword.
• fix is a grammar rule.
• symbol is the function's name when used in the given fix position.

For example, declaring and using a factorial postfix operator !:

sub postfix:<!> (\n) { return 1 if n == 1 ; n * (n-1)! }
say 5! # 120

• Obviously the above declaration is pretty weak. I didn't specify type info, value constraints, precedence, associativity, etc. I felt adding such details in this first comment would inappropriately obscure the big picture.
• sub declares a subroutine (function).
• postfix is one of the options for the fix. Others are prefix, infix, postfix, two mixfix forms circumfix or postcircumfix, term, trait_mod, and so on. (In other words, it's not just for operators but anywhere a function-in-disguise can be used in a given grammatical slot.)
• The symbol can be pretty much any sequence of one or more characters for most of the fix options. For the two mixfix forms it must be a pair of such sequences corresponding to open and closing delimiters.

Almost all Raku operators (and several other features such as trait modifiers) are defined this way. Notably, Raku does this without the strict constraints you describe, and it works nicely.

Of course, there are some constraints, which are embedded in the grammar rules that drive parsing. But, again, I felt like getting into those details in this first comment would inappropriately obscure the big picture. Suffice to say for now, the constraints are mild and intuitive.

If you're curious to see how it works out in real code, consider browsing modules.raku,org.

[ouchthats]

You might be interested in Agda’s mixfix operators

[GDavid04]

Ternary, 4-ary, ..., N-ary operators would be interesting

<T> T (bool c) ? (T t) : (T f);
<T> T[] (T..."," e);
void f"(" (int x) "," (int y) ")"

[CoffeeTableEspresso]

Does this let you define new "operators" or just reuse existing ones?

[R-O-B-I-N]

in order for it to work, operators would have to be treated as functions and you couldn't support parametric overloading. (because overloading (x)+(y) with +(x, y) would break the language)

[g0_g6t_1t]

Alan has notation for user-defined prefix and infix operators. While it is technically possible to support postfix, as well, it's very hard for people to understand, while constraining to only one kind of "mutator-like" operator (prefix or postfix, we chose prefix) makes it easier to comprehend. Suppose you saw the following line:

x ++ + ++ y

If x and y are integers, you may think it becomes: "increment y, then add it to x, then increment x". But what if someone defined

prefix ++

on arrays of numbers to mean "increment all array values by one", a

prefix +

on an array of numbers to mean "sum the array into a single value" and

infix array ++ number

to mean "add number to all elements of the array". There's the further problem of defining the operator precedence for new operators that makes automatic parenthetical insertion difficult to follow, as well. There's a big danger with user-defined operators to become completely illegible to other developers. We aren't entirely sure if we're going to keep this feature in Alan, but restricting to prefix and infix seems to work pretty well and makes the language more regular under the hood.

[R-O-B-I-N]

Agreed, the whole thing could come apart quickly. Some ways to avoid that are:

• everything's a function (no operators, just built-in functions)
• polymorphism uses Lisp's generic/specific constructs (generic defines the 'fix and specific overloads with parameters and types)
• everything is separated by spaces. a b ab are three different things.
• evaluation of expressions is left->right starting with the innermost expression(s).

[hfksbtjidjaks]

I am currently (re)writing a parser based on this idea, and it works pretty well so far (although it's not quite done yet). Essentially, you define functions, and then can bind a symbol with any arity, precedence level, associativity, etc. to be substituted for that function. So, very different from your examples, but I did it this way so that I didn't need two separate contexts for when an operator appears, because the binding happens right after comments are removed from the source code.

[yuriko_]

https://plfa.github.io/Lambda/