On Thu, Mar 17, 2016 at 10:51:11AM +0800, Elias Mårtenson wrote: > On 17 March 2016 at 00:41, David B. Lamkins <[1][email protected]> > 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.
