Proposal: User defined operators about mond HOT 4 CLOSED

That first example is really clever! I never would have thought of doing that.

We don't really need a new keyword for this, it could just be an extension to fun (probably seq too, for consistency). Names can't have parenthesis around them right now so if the parser sees them it knows it's an operator.

How would this work when dealing with multiple files? These would require additional information in the parser, and different files use another instance of the parser. After doing that we would also need the function instance for the operator, which isn't available while parsing.

from mond.

We don't really need a new keyword for this, it could just be an extension to fun (probably seq too, for consistency). Names can't have parenthesis around them right now so if the parser sees them it knows it's an operator.

I like this idea. It also makes it possible to yield from an operator instead of returning a seq first like the range examples.

How would this work when dealing with multiple files?

A problem I haven't quite worked out. Right now the UDOs live in a static List<UserDefinedOperator>, but that's less than ideal. Although, at the moment, it's actually not possible to export UDOs from a require()'d file unless the compiler options are set to make root declarations global and use implicit globals.

After doing that we would also need the function instance for the operator, which isn't available while parsing.

That problem I have solved, kinda. Right now in the PoC implementation, UDO declarations simply get turned into functions; their parselet just returns a FunctionExpression with a unique name generated by the parser so we never need the expression again to use it. The UserDefinedOperator struct contains a Guid the name is derived from, then when the UDO is used elsewhere that really just compiles to a function call using the special name.

In essence, UDOs just look like this in bytecode:

fun $op_4bf154f73e8e452fab01711ea4e1b3b0( str ) {
    return str.toUpper();
}

const shouting = $op_4bf154f73e8e452fab01711ea4e1b3b0( "hello" );

from mond.

The UserDefinedOperator struct contains a Guid the name is derived from, then when the UDO is used elsewhere that really just compiles to a function call using the special name.

If the names were generated in a deterministic way, we could store the function instances in a global and resolve calls dynamically. So the parser wouldn't have any knowledge of UDOs, it would just have a transformation for all valid UDO names:

global.__ops["^"] = fun (str) {
    return str.toUpper();
}

const shouting = global.__ops["^"]("hello");

This way we don't need to worry about multiple files because we just assume everything exists. We lose compile time errors for them but that's what normally happens when you have a dynamically typed language.

from mond.

That could work. That would also allow the binding API to insert UDOs implemented in C# as well by way of a new attribute, which is impossible with the current PoC.

from mond.