bug-apl
[Top][All Lists]
Advanced

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

Re: Bugs in extended transfer form


From: Dr . Jürgen Sauermann
Subject: Re: Bugs in extended transfer form
Date: Mon, 27 Apr 2020 20:02:36 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

Hi Kacper,

I believe this is fixed now, SVN 1273 .

All GNU APL users please note the following.

The fix for 2 ⎕TF also affects the )IN and )OUT commands (they use 2 ⎕TF internally).
I have tried my best to keep everything backward compatible but I am not sure if I succeded.
Therefore, if you store your workspaces as .atf files (not a good idea in the ffirst place) then
please also store them as )DUMP or )SAVE files to prepare for the case that the new )IN
command after the SVN update has problems with the output of the old )OUT command.

E.g.

)CLEAR
)IN wsname
)DUMP wsname

Best regards,
Jürgen


On 4/21/20 6:46 PM, Kacper Gutowski wrote:
Hi.

1° Enclosed value is incorrectly rendered using only parentheses as if it were part of a strand _expression_ even if it's not.  The generated representation is wrong, and then parsing it back correctly gives the same value as ⍎ would.

      XX←X←⊂,1
      2⎕TF ⎕← 2⎕TF'X'
X←(,1)
X
      XX≡X
0
      YY←Y←(⊂1 2)3
      2⎕TF ⎕← 2⎕TF'Y'
Y←((1 2)) 3
Y
      YY≡Y
0

If I understand the Appendix B of APL2 Language Reference correctly, these representations should be “⊂1⍴1” for X and “(⊂1 2)3” for Y.  According to that Appendix, using “,1” for one-element vector in transfer form isn't correct either, but I have no idea what APL2 does.


2° Some parentheses seem to confuse the parser.  I took the “A” below from an example in APL2 Language Reference and I believe in this case the transfer form generated is correct, but then parsing it back with 2⎕TF gives incorrect nesting.

      8⎕CR AA←A←('' (⍳0))('Q' 3.2)(2+3×⍳4) 'Don''t'
┌→────────────────────────────────────┐
│┌→──────┐ ┌→────┐ ┌→────────┐ ┌→────┐│
││┌⊖┐ ┌⊖┐│ │Q 3.2│ │5 8 11 14│ │Don't││
│││ │ │0││ └─────┘ └─────────┘ └─────┘│
││└─┘ └─┘│                            │
│└∊──────┘                            │
└∊∊───────────────────────────────────┘
      2⎕TF ⎕← 2⎕TF'A'
A←('' (0⍴0)) ('Q' 3.2000000000000002) (5 8 11 14) 'Don''t'
A
      AA≡A
0
      8⎕CR A
┌→──────────────────────────────────┐
│┌⊖┐ ┌⊖┐ ┌→────┐ ┌→────────┐ ┌→────┐│
││ │ │0│ │Q 3.2│ │5 8 11 14│ │Don't││
│└─┘ └─┘ └─────┘ └─────────┘ └─────┘│
└∊──────────────────────────────────┘

The transfer form of A shown in the apl2lrm (page 337) is
A←(''(0⍴0))('Q' 3.2)(5-3×⎕IO-⍳4)'Don''t'
using a “progression” instead of explicit vector.
The Appendix says that redundant blanks and parentheses are prohibited, so I'm not sure if what GNU APL gives is strictly correct with regard to blanks, but the parenthesizing is the same and it certainly is correct in terms of ⍎.  It's parsing it back what fails in this case.

-k




reply via email to

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