|Subject:||Re: [Bug-apl] Fwd: A couple of bugs, and a question on the power operator|
|Date:||Sun, 14 Aug 2016 17:04:44 +0200|
|User-agent:||Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0|
my argument in this case would not be the limited size of ⎕AV but a concern regarding portability.
In the past some APLs (and also J) have tried to improve APL.
IMHO most of these attempts have failed because they provide very minor conveniences in some
very special cases but create incompatibilities in the workspaces that use these features. From an
free software perspective I would rather accept the inconvenience of a lacking feature than introduce
new incompatibilities (there are already enough incompatibilities in existing interpreters).
⎕-functions are an exceptions because they have historically been the place where interpreter-specific
functions were provided. Adding a ⎕-function to GNU APL is, in my eyes, very different from changing
the syntax of GNU APL. I wouldn't completely reject an approach to control locality in lambdas. But so far
there are two proposals on the table, both using ⎕-functions:
1. A ⎕-function that converts a lambda into a different one which has the same body but a different
header with more local variables. This would happen when the function is being fixed.
2. A ⎕-function that assigns a global variable instead of its local referent. Needless to say that this
has a run-time penalty for searching the variable in the )SI stack and is also not very orthogonal
because you cannot read the (global variant of) variable back.
None of these approaches is entirely convincing, but I could do it if a significant number of GNU APL
users would ask for one or the other (but not both, please).
Looking backwards, I believe the introduction of lambdas into GNU APL was the biggest mistake
that I made and I do not really feel like driving that mistake any further.
And for what I would call a "proper function" (one defined with ⎕FX or ∇) the issue of variable locality
does not exist at all. I also believe that it is a bad language design if you introduce two types of
functions with different execution semantics (and that is the main reason for not having multi-line lambdas).
Deviations in the variable scope would be such a difference.
On 08/14/2016 08:22 AM, Elias Mårtenson wrote:
|[Prev in Thread]||Current Thread||[Next in Thread]|