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

[David B. Lamkins]

On Thu, Mar 17, 2016 at 10:51:11AM +0800, Elias Mårtenson wrote:
>    On 17 March 2016 at 00:41, David B. Lamkins <address@hidden>
>    wrote:
> 
>      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.
> 
>    That's the problem. If your rewriter works on the level of the reader
>    (i.e. working directly with the string of characters that make up the
>    code) then your extension would essentially have to reimplement the
>    entire language parser.

Of course. And yes, that is what I was suggesting.

I assume that the parser-in-APL problem would be solved a small number of 
times; those interested could share the work. 

Now, this is obviously not an ideal approach. I assume that the rewriter would 
need to read every executed line of APL code at least once. Even if the 
rewritten code is cached, there'll still be a performance hit due to the 
necessity of the rewriter scanning every executed line using code written in 
interpreted APL.

On the other hand, having the full generality of a rewriter-in-APL would offer 
the ability to create DSLs and not simply extend the semantics of APL-like 
expressions. Kinda like Lisp... ;)

[... snip ...]
>    In Lisp, the custom READTABLE is applied on a single translation unit
>    (i.e. a single .lisp file). Something similar could be implemented in
>    APL as well.

OK. I can see that.

[... snip ...]
>      Clearly quad-AV is necessary for compatibility with legacy APL code;
>      as such, it'd be ill-advised to break that compatibility.
> 
>    I agree. But at the same time, I don't think I've ever run a single
>    line of legacy code in my life. I only started using API a few years
>    ago (with the release of GNU APL), so for me (and possibly any other
>    newcomer to the language) Quad-AV is completely pointless.
>    I'm not sure I agree that holding back the language to benefit legacy
>    code is the best idea. I completely agree that legacy code should
>    continue to work, but preventing obvious improvements because of
>    restrictions introduced in an era where Unicode didn't even exist
>    doesn't make much sense to me.
>    In other words, what I am suggesting is: If you use characters outside
>    of Quad-AV in your code, then Quad-AV will cease to work.

I'm kind of in the same boat. I learned APL on microcomputers in the `80s. The 
nested-array implementations were already in play by then, but not in the 
implementations to which I had access. I'm finding APL2 to be quite a different 
language than APL, in many respects. I didn't save any of my own "legacy" code, 
so haven't had to deal with compatibility issues.

A larger question is: Does quad-AV have any value at all in new code? It's 
inherently non-portable (in that the collation order is unspecified) and 
contains a proper subset of the code points in quad-UCS.