Re: [Bug-apl] Feature suggestion: multiple function arguments

[David B. Lamkins]

On Tue, Mar 15, 2016 at 11:35:59AM +0800, Elias Mårtenson wrote:
>    I was thinking of something similar, but the problem is that creating a
>    plugin API that lets you implement trains is incredibly difficult,
>    since you need to hook deep into the parser.
> 
>    As for more simple extensions, we already have almost all that is
>    needed in the plugin API, with the exception of being able to define
>    new function symbols.
> 

First of all, I'm not volunteering for this task, but...

While I agree that adding hooks to allow arbitrary special cases in the parser 
would be an architecturally weak approach, it might be useful to add a single 
hook that would support code to perform a lexical rewrite before handing an 
expression to the APL2-compatible built-in parser.

The lexical rewriter could be a plugin, but it could also be an APL function. 
Imagine being able to assign an APL function to quad-SOMETHINGOROTHER to define 
your own local syntax. You'd still be running APL2 code under the covers, but 
you'd be able to define your own syntax for anything that can be rewritten 
(presumably less conveniently) in APL2. Remember that the rewriter would have 
full access to the underlying APL2 interpreter, so you'd be able write entire 
programs to support the processing of some new syntax.

(If the above sounds familiar, it's probably because it's an amalgamation of 
ideas from Lisp.)

I don't know whether this would help or not w.r.t. function trains.

Also, quad-SOMETHINGOROTHER would be a nightmare in shared code unless there 
was a good way to support localization (in the APL sense, not the I18N sense).

>    The latter is something that I would like very much. In other words, I
>    would like the ability to define functions (single-letter ideally)
>    using characters outside of quad-AV.
> 
>    Jürgen has previously explained that there are technical difficulties
>    in expanding the character repertoire outside 255 characters, but I
>    still feel this is one old limitation that deserves being eliminated.

I understand why we need to limit quad-AV to 256 elements. But what about 
composed characters? Would it be enough to alias the Unicode "compose" 
codepoint to the ASCII "backspace" (that is already, I'm assuming, in 
quad-AV...)?

Of course, you'd need a terminal that's able to compose glyphs on-the-fly. :\