[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-apl] Feature suggestion: multiple function arguments
From: |
David B. Lamkins |
Subject: |
Re: [Bug-apl] Feature suggestion: multiple function arguments |
Date: |
Wed, 16 Mar 2016 20:43:01 -0700 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
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.
- Re: [Bug-apl] Feature suggestion: multiple function arguments, (continued)
- Re: [Bug-apl] Feature suggestion: multiple function arguments, Elias Mårtenson, 2016/03/17
- Re: [Bug-apl] Feature suggestion: multiple function arguments, Juergen Sauermann, 2016/03/17
- Re: [Bug-apl] Feature suggestion: multiple function arguments, Elias Mårtenson, 2016/03/17
- Re: [Bug-apl] Feature suggestion: multiple function arguments, Juergen Sauermann, 2016/03/17
- Re: [Bug-apl] Feature suggestion: multiple function arguments, Elias Mårtenson, 2016/03/17
- Re: [Bug-apl] Feature suggestion: multiple function arguments, Juergen Sauermann, 2016/03/18
- Re: [Bug-apl] Feature suggestion: multiple function arguments, Elias Mårtenson, 2016/03/18
- Re: [Bug-apl] Feature suggestion: multiple function arguments, Peter Teeson, 2016/03/17
- Re: [Bug-apl] Feature suggestion: multiple function arguments, Elias Mårtenson, 2016/03/16
- Re: [Bug-apl] Feature suggestion: multiple function arguments, Peter Teeson, 2016/03/16
- Re: [Bug-apl] Feature suggestion: multiple function arguments,
David B. Lamkins <=
- Re: [Bug-apl] Feature suggestion: multiple function arguments, Juergen Sauermann, 2016/03/17
- Re: [Bug-apl] Feature suggestion: multiple function arguments, Juergen Sauermann, 2016/03/15