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

[Elias Mårtenson]

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.

What is needed is an API that allows an extension developer to work on a higher level. My question was mainly about what that API should look like.

>    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.

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.

 

>    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.

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.