Re: [Bug-apl] Revisiting the APL 2 empty-array display behavior

[Blake McBride]

Dear David,

Interesting observation.  More interesting is how GNU APL correctly handles it.  i.e.:

      ∇test[⎕]∇

    ∇

[0]   test

[1]   '1'

[2]   ⍎0/'test2'

[3]   '2'

[4]   ''

[5]   '3'

[6]   ⍎1/'test2'

[7]   '4'

    ∇

      ∇test2[⎕]∇

    ∇

[0]   test2

[1]   'test2'

    ∇

      test

1

2

3

test2

4

The problem you bring up, which would be very significant, isn't a problem.  I'm uncertain of the logic used, but GNU APL (correctly) produces the expected and standard behavior - a behavior that doesn't have the problem you mention.

Am I missing something?

Thanks.

Blake

On Wed, May 28, 2014 at 1:19 PM, David B. Lamkins <address@hidden> wrote:

Now that I can see how printing '' as CR affects a larger program, I've
gotta say that I'm stumped as to how this behavior can be considered
usable.

Specifically, it's now (unless there's a trick I haven't yet discovered)
difficult (see below) to silently (i.e. without affecting the display)
execute an arbitrary _expression_ that may, depending upon the _expression_,
return either '' or nothing at all.

I dunno... maybe that's not something that anyone else has ever done.

But here's an extremely common idiom that breaks badly under the new
print behavior:

      ⍎test/'_expression_'

This is just a conditional execution of an _expression_. The problem with
the new print behavior is that this line will print a CR whenever the
test is false. Not OK...

If we're going to stick with this new behavior, I can adapt. I've even
discovered a (rather tortured-looking) solution to the use-case I posed
in the second paragraph:

∇sink v
 ⍝ Consume value; no display
∇

sink '0' ⎕ea ',⍎l'

On the other hand, it's surprising to me how this new behavior affects
so much else.