Emulation in different Dyalog versions

[Phil Last]

Because our users still have users who still use Dyalog V14.0 we now have emulators for all enhancements used by acre that have arisen since. All of them are rather more sophisticated than the following which I present to demonstrate a problem. Here is a version 14.0 session:

      Dyalog APL/W-64 Version 14.0.21929
Serial No : xxxxxx
Unicode Edition
Non-commercial Licence
Thu Jan 24 15:54:59 2019
clear ws
      )lib .
SavedIn14     SavedIn16
      )load SavedIn16
this WS requires a later version of the interpreter.
      )load SavedIn14
.\SavedIn14 saved Thu Jan 24 15:53:31 2019
      ⎕nl⍳11
i_
      ∇i_∇
     ∇i_←{
[1]        ver←⍎{⍵/⍨2>+\⍵='.'}1⊃'.'⎕WG'APLVersion'
[2]        16≤ver:⍸⍵
[3]        (,⍵)/,⍳⍴⍵
[4]    }
     ∇
      i_ 1 0 1 0 1
0 2 4

And here a version 16.0 session:

      Dyalog APL/W-64 Version 16.0.34994
Serial No : xxxxxx
Unicode Edition
Thu Jan 24 15:58:37 2019
      )lib .
SavedIn14.DWS SavedIn16.dws
      )load SavedIn16
.\SavedIn16.dws saved Thu Jan 24 15:56:38 2019
      ⎕nl⍳11
i_
      i_ 1 0 1 0 1
0 2 4
      )load SavedIn14
.\SavedIn14.dws saved Thu Jan 24 15:53:31 2019
      i_ 1 0 1 0 1
SYNTAX ERROR
i_[2] 16≤ver:⍸⍵
             ∧
      ⍸⍵
0 2 4
      ⊢⎕fx⎕nr'i_'
i_
      i_ 1 0 1 0 1
0 2 4

While we can't )LOAD a later dws into an earlier interpreter we can't RUN an earlier dws in a later because the functions containing not-yet implemented symbols have those symbols flagged at fix time as syntax errors which persist even when )LOADed into a version that supports them. Refixing every function under the later version does the trick but becomes somewhat irksome when you have to do it every time the dws is )LOADed.

It would be nice to be able to have a single v14.0 dws to run in any supported version but ... Current strategy is to have a separate, ostensibly identical, workspace for each Dyalog version supported.

Incidentally, once installed in multiple versions, acre reads and writes code to text files that are immediately available in any previous or later supported version.

[AndyS|Dyalog]

Oh what a tangled web !

We've been discussing this for several years, and not come to a satisfactory conclusion yet .. the current line of thought is that at run time we generate a SYNTAX ERROR, but set the extended message to something along the lines of "⎕wheelbarrow was invalid syntax when the expression was fixed" - which means that you'll get a unique ⎕DMX.ENX too.

There have been several suggestions over the years for taking an action to (re)fix the item in error rather than just simply generating an error message, but none has been considered satisfactory. For example, if we were to refix any function that contains an invalid syntactical item, do we update the ⎕AT information or not ? From the development team's perspective doing this is not easy as there are currently some limitations that )load and )copy impose that would need to be relaxed, which will not be a small job.

We have this sort of problem in our QAs, and for us the best (or least worse) option is to code

      16≤ver:⍎'⍸⍵'

or

      ⍎'int←⍸'
      16≤ver:⍸⍵

which is pretty horrible ! Of course, that leads to more fun in Classic interpreters with symbols such as ⌸ and ⍤ vs ⎕u2338 and ⎕u2364.

[For Dyalog people this is mantis 13432]