Documentation for ⎕NR, ⎕CR

[petermsiegel]

It looks as if ⎕NR and ⎕CR both allow a right argument in the ⎕OR (internal) format to be treated as if a name. I have been depending on this for years (grabbing ⎕OR-format items from ⎕stack), but the documentation seems to say that they allow only names.

Code: Select all

      ⎕CR 'PI'
 R←PI N
 R←○N 
      ORpi←⎕OR 'PI'
      ⎕NR ORpi
  R←PI N   R←○N
      ⎕CR ORpi
 R←PI N
 R←○N 
      (⎕NR ORpi)≡(⎕NR 'PI')
1
      OR≡'PI'
0      ⍝ No surprise!

Might the documentation for ⎕NR and ⎕CR be updated to explicitly allow this (rather than this feature be viewed as a bug in a future release)? Indeed, the documentation for ⎕OR exegetically suggests an object representation (R) of a name (Y) is a (perhaps magical) form of said name: "Otherwise, R is a special form of the name Y, re-classified as a variable."

(As always, if I read the documentation wrong, mea culpa).

[Morten|Dyalog]

⎕OR is a feature that I wish we did not have; it is handled inconsistently by various components of the interpreter and words like magic/voodoo frequently come to mind. Dyalog is unlikely to do anything that might encourage its use, which means we are unlikely to write new documentation for the things that happen to work, even if they are useful.

In the longer term, we are likely to provide other mechanisms for inspecting metadata, such as an objects that represents the state indicator, which would allow retrieving the source code of functions that are suspended. This work is currently some way down the queue, I would not expect anything for the first couple of years.

[Phil Last]

Sorry Morten but your pessimism

I would not expect anything for the first couple of years

might be somewhat understated.

Some two years ago Jay Foad apologised to me when he discovered that a complaint I had made regarding the absence of differential classification of namespaces - container and scripted - (⎕NC) was nothing more than a repetition of the same complaint I'd made seven years earlier when I'd been told that Dyalog was working on a new metadata system function that would cover all such things.

[Morten|Dyalog]

I'm sorry if you interpret this as pessimism, that isn't how I feel about it. I just want to make it clear that there are several other worthy projects that we judge to be more important than "the metadata project" at this point in time. You are right that it has slipped down the rankings a bit recently. However, once the .NET Core/5.0 bridge and a couple of other larger bits of infrastructure work are behind us, and we have one or maybe two more developers hired into the interpreter development team, I expect that we shall return to it. Projects have been known to lurk on the list for a decade, and then suddenly they pop to the top.

⎕OR still works; we won't be taking it away - just not promoting it at this point in time.

[Phil Last]

I'm even more pessimistic if it transpires that you are not.

A decade to correct a number?

      c←⎕ns''
      ⎕fix':namespace s' ':endnamespace'
      ⎕nc,¨'c' 's'
9.1 9.1

[Morten|Dyalog]

It *would* be nice to be able to distinguish the two cases without trapping an error (as I think you need to do today), but it isn't at all clear to me that changing the result of ⎕NC is the way to go. So that particular change isn't on our to do list at all, as far as I am aware.

You are right that projects like the METADATA are problematic in that there is a tendency to get over-ambitious and do too much, which makes it an enormous project. The "Theory of Everything" project that was presented at Dyalog'18 looks like a good way to go and would provide clean ways to do a great many things. It is a rather large piece of work, but eventually I do believe it will bubble to the top.

In this particular case: would it help you significantly if ⎕SRC returned an empty vector for namespaces which have no source. At one point I think we were considering auto-generating source in this case and did not want make that impossible in the future. However, as APL now supports external source files I think it would be a very bad idea to start auto-generating source, so I think I am happy to think about burning that bridge.

[Phil Last]

Checking for an empty result would definitely be better than having to set a trap [*] but given the table

complete set of name classification

and the obvious incompatibilty between normal and scripted nss it appears that the latter were probably destined for row n.3 but for some oversight in the final implementation. Checking for 9.3 vs 9.1 might be somewhat more straightforward.

This was my suggestion immediately after implementation. It could probably have been changed before more than a handful of users had even discovered the problem.

• for anyone unaware, the only way to distinguish between the two types is to ask for its ⎕SRC under a trap. If a NONCE ERROR ensues we know the space is non-scripted.

[petermsiegel]

Or, try ⎕JSON ns on the namespace and check for a domain error, when ns is scripted [see note]:

Code: Select all

       (uns←⎕NS '').(A B C)←⍳3
        ⎕FIX':namespace scr' 'A←0' 'B←1' 'C←2' ':Endnamespace'
       scr.(A B C)
0 1 2
       uns.(A B C)
0 1 2
        ⎕JSON uns
{"A":0,"B":1,"C":2}
        ⎕JSON scr 
DOMAIN ERROR: JSON export: item [2] of the right argument cannot be converted (⎕IO=0)
      ⎕JSON scr
      ∧
      ⎕EN
11
      ⎕NC 'uns' 'scr'
9.1 9.1

[note] OK. Only useful for namespaces (whose variables are) within the domain of JSON. The point is: an odd distinction to anticipate based on how a namespace is created, not how it is used.

[Adam|Dyalog]

Please do not rely on ⎕JSON erroring on scripted namespaces. This was a bug that has been fixed in the upcoming version:

Code: Select all

Dyalog APL/W-64 Version 18.0.36911
Serial number: 004823
Sun Sep 29 08:01:05 2019
      ⎕FIX':namespace scr' 'A←0' 'B←1' 'C←2' ':Endnamespace'
      ⎕JSON scr
{"A":0,"B":1,"C":2}