operator overloads

`lo

i think you have a foundation to close a gap on three fascinating orthoganol programming enablements that will provide an exponent of programming liberties

• aggressive operator overloading
• symbol liberties in unicode
• (lib based) operator precedence overrides and evaluation triggers to enable parser token and direction geometry triggers to change evaluation flavors to forth, algebraic operators, categorical context propagation , and even 2d languages (not a priority)

essentially, the above looks like to me like the tool for any given programming language to most versatiley transcribe expression pasted in from diverse sources and some glue code to patch up the evaluation semantics to match.

a really long time ago the boost c++ team adopted boost spirit to crib a c++ orienttion of weak features in the area above to build parsers in an EBNF look-alike c++ grammar.

having those three things above would enable a snowballing library transcription process from diverse language sources under one join-point.

what is unclear at this time about aa

…

this is a chart with a hint

[jnorthrup]

in java/c98/c++ terms i look at oper precedence as an enum however numerous.

this was forwarded for which I would say my preferences are away from sexp personally https://www.swi-prolog.org/pldoc/doc_for?object=op/3

kotlin has done a few things right that i haven’t seen done since the usenix es shell.

• ````token```` escapes the java legal character limitation of kotlins’ origins. i haven’t gotten around to tweaking kotlin to just go full unicode but it would be more cool.

• kotlin “infix” functions specifier indicates to elide the () around next token parameter which has a generics scope to differentiate overlaps.

• you can write a kotlin infix function that will reverse the immediate order of function evaluation so that you can express f before g but the generics pile up so fast you really can’t make much headway for currying and concatenative expression syntaxes

• finally, no language i care about has shown the option to create confix operators like superceding or extending the meaning of [] {} <> etc.

inherently json, sgml i.e. some html and xml, and graph notations could all be copmiled with overloads instead of parsers.

this example was from textbook https://gist.github.com/jnorthrup/60d1465c29c85b183d502d521a7b9022#file-implication-kt-L145 just to see how far the kotlin legal syntax could be pushed.

im aware of auto-grad techniques that would again benefit greatly from overloads to replace parsers and precompilers to arrive at a function abstraction into self normalizable concepts. the entry point of thier usecases is matrix math, in languages that are not transparent as such.

[cliffclick]

Probably straightforward to extend the parser oper syntax to allow new opers. Would also need a way to specify precedence and uni/bin/trin ops. The actual parsing of such is already implemented (table lookup of precedence ops, binary-vs-pre-vs-post, etc). No promises but should be straightforward enough.