Hi,
after some more thinking and considering Elias' comment I have
come to the
conclusion that it is cleaner to parse ⍬ as a constant than as a
niladic function.
In particular since otherwise ⍬ (the empty numeric vector) and ' '
(the empty
text vector) would bind differently and therefore an unexpected
inconsistency
between ' ' and ⍬ would occur.
The new parsing is effective as of SVN 1212.
The change only makes a difference in the following situation:
A. There is an APL literal that contains ⍬, and
B. That literal is the left argument of a dyadic function, and
C. The literal is not enclosed in parentheses.
For example:
1 ⍬ 3 + 4
If ⍬ is parsed as a niladic function (the old scheme) one gets:
4⎕CR 1 ⍬ 3
+ 4 ⍝ 1 ⍬ 3 + 4 ←→ 1 ⍬ (3 + 4)
┏→━━━━━━┓
┃1 ┏⊖┓ 7┃
┃ ┃0┃ ┃
┃ ┗━┛ ┃
┗∊━━━━━━┛
If ⍬ is parsed as a constant (which binds stronger to other
constants) then
the new scheme gives:
4⎕CR 1 ⍬ 3
+ 4 ⍝ 1 ⍬ 3 + 4 ←→ (1 ⍬ 3) + 4
┏→━━━━━━┓
┃5 ┏⊖┓ 7┃
┃ ┃0┃ ┃
┃ ┗━┛ ┃
┗∊━━━━━━┛
Best Regards,
Jürgen
On 12/24/19 4:36 PM, Dr. Jürgen
Sauermann wrote:
Hi,
yes. In some sense. Actually
1 2 X 4
is the same as 1 2 (X) 4
because there is a rule that says so. However, the point here is
that
1 2 X 4
can be (very) different from
(1 2 X 4)
The difference does not occur in simple examples, but may in
more complex ones.
1
2 X 4 + 1
is generally different from
(1 2 X 4) + 1
simply because the order of evaluation differs between X and
+. More generally, if
you put the left argument of a dyadic function in parentheses
then that most likely
(though not neccessarily) changes the valuation order (and
hence the result). I know
that this is odd, but so are niladic functions when it comes
to parsing. According to
the IBM APL 2 parentheses rules, the parantheses around (⍬)
are redundant (and
make no difference while the parentheses around
(⍳0) are not redundant. As a
consequence, even though ⍳0 yields essentially ⍬ they are not
entirely equivalent.
Best Regards,
Jürgen Sauermann
On 12/24/19 3:16 PM, Elias Mårtenson
wrote:
I think such a change would make sense. A
niladic function is in some sense a shortcut to writing a
specific value, so it should probably be treated as such.
It a little odd that:
1 2 X 4
is different from:
1 2 (X) 4
Regards,
Elias
Hi David,
not sure either if this is a bug. The APL standard has
quite a specification gap
when it comes to binding strength. In GNU APL, the
binding between values
(aka strand notation) is stronger than the binding
between values and functions.
For example:
V←⍳0
∇Z←F
Z←⍳0
∇
Both V and F result in the same value ⍬:
V≡F
1
However, they are parsed differently:
2
V 3⊃a
3
2 F 3⊃a
2 99
In the first case: 2
V 3⊃a the value V binds strongly to 2
and 3 so that value (2 V 3)
becomes the left argument of ⊃. In the second
case: 2 F 3
the value 3 binds
stronger to ⊃ than to F so that first
is evaluated
3⊃a and then the result of ⊃ is
tied to the F and 2.
In GNU APL ⍬ is a niladic function, so
it behaves like F above.
This behaviour could be changed, but I hesitate
to do that since it might break
existing code. The impact of such a change would
not only affect ⍬ but all niladic
functions.
Best Regards,
Jürgen Sauermann
On 12/24/19 2:49 AM, David Tran wrote:
Ooops, missing something on my examples,
correction: ( missing ⊂ on ⍳3 )
a ← 'abc'(⊂⍳3)99
the 3 examples are the same:
2(⍳0)3⊃a
2⍬3⊃a
(2⍬3)⊃a
Hi,
Not sure this is a bug or not, for me, (⍳0) ≡
⍬, so it seems that both can be replaced each
other; consider below example:
a←'abc'(⍳3)99
2(⍳0)3⊃a ⍝ ≡ 3
2⍬3⊃a ⍝ ≡ 2 ⍬ 99
(2⍬3)⊃a ⍝ ≡ 3
Doesn't the second example should return 3 as
first example, without the need parentheses as
third example?
(btw. my version is build from SVN around Oct
)
Thanks,
Dave
