[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Juergen Sauermann
Subject: Re: [Bug-apl] Feature suggestion: multiple function arguments
Date: Thu, 17 Mar 2016 15:24:10 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0


I believe a *⎕FX* wrapper would be a much simpler solution.

Say a function *Z←∆FX**B* which reads your function text *B* (containing non-standard APL syntax) and converts it to some reasonable *B1 *which contains the standard syntax. Finally: *Z←⎕FX B1*.

/// Jürgen

On 03/17/2016 04:43 AM, David B. Lamkins wrote:
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>

      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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]