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.