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

[David B. Lamkins]

On Wed, Mar 16, 2016 at 01:17:36PM +0800, Elias Mårtenson wrote:
>    On 16 March 2016 at 09:23, David B. Lamkins <address@hidden>
>    wrote:
> 
>      On Tue, Mar 15, 2016 at 11:35:59AM +0800, Elias Mårtenson wrote:
> 
> 
>      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.)
> 
>    It does indeed sound a lot like Lisp form rewriting. I'm all for this
>    idea, and I'd be willing to make a test implementation of it, as long
>    as someone (else) can can come up with a decent way of actually create
>    a way to unambiguously state the input to be transformed (the
>    equivalent of the DEFMACRO destructuring form in Lisp).

I'm not sure what you mean by this. Were we to follow the model of Lisp's 
macroexpansion, the expander would simply be an APL program that reads some 
program text -- possibly but not necessarily containing local syntax extensions 
-- and rewrite that text in APL2/GNU APL code without the syntax extensions. 
It'd be up to the rewriter to handle any necessary lexical and syntactic 
analysis necessary to perform the program tranformation.

> 
>      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 extensions would be part of the program itself, just like in Lisp.
>    I don't see a problem here.

I anticipated that a system variable or function would hold the program that 
does the rewriting. Were I to load two programs (e.g. a main program and a 
library) that used this facility in different ways, there'd be a conflict.

>    I'm not entirely sure why Quad-AV even needs to exist in a modern
>    program? We should be able to use all of Unicode to name our functions.

Clearly quad-AV is necessary for compatibility with legacy APL code; as such, 
it'd be ill-advised to break that compatibility.

Extending the GNU APL lexer to accept additional code points in names would be 
an extension to the language. It'd break backward compatibility (you could 
write GNU APL programs that APL2 wouldn't be able to load), but legacy APL2 
programs would still run in GNU APL.

>    Regards,
>    Elias
> 
> References
> 
>    1. mailto:address@hidden