No Result for ⎕R?

[paulmansour]

I' surprised that ⎕R does not return some sort of result when the output is streamed. Were the in-house dfnistas asleep at the wheel when this was being designed? ;)

Perhaps it would be useful to have it return the number of replacements or blocks processed or something.

[JohnS|Dyalog]

Thanks for this - it was an oversight - we're on it.
The suggestion is that, in this case, ⎕R return the same (shy) result as ⎕NAPPEND: the file offset in bytes of the end of the new data.

[paulmansour]

Sounds good to me. Thanks!

[petermsiegel]

Since we're on the subject, any reason why ⎕CY should not return a value (similar to ⎕EX). In a DFN, one is forced to use execute ⍎'this that ⎕CY myWS ⋄ 1' or some such. Thanks.

[paulmansour]

Yes, please!

I'm usually doing something like

      {0::0 ⋄ z← ... ⎕CY ...}

somewhere I have operator for doing this....

I think when dfns were first introduced, there was a flurry of activity to retrofit any non result returning quad functions. A few were left behind.

[AndyS|Dyalog]

Regarding Peter's comment about ⎕CY: although we won't be changing ⎕CY in 16.0, we are thinking about it for 17.0, along with changing all the other non-result returning system functions too.

[petermsiegel]

Thanks. Shy results were the best idea ever-- have your cake and eat it, too.

[Morten|Dyalog]

Shy results may be cute, but IMHO they are nasty at the language/implementation level, as they require a function to know whether its result will be used. If I were starting again with a clean slate I would argue long and hard against them. There are so many edge cases that it quickly spirals out of control. Consider:

Code: Select all

     shydup←{r←⍵ ⍵}
     shydup 2
     shydup¨2
     (shydup⍣1)2 3

So far so good, but will you demand that we also special-case operators that need the values to assemble a result?

Code: Select all

     (shydup⍤0)2 3
2 3
2 3
     shydup⌸1 2
 1  1
 2  2

And what about asynchronous calls, like:

Code: Select all

     future←isolate.shydup 1

The function cannot know whether its result will be used, that hasn't been decided yet.

I don't personally feel that the utility of shyness is worth the implementation complexity. One man's view :-).

[Phil Last]

Two. 'though ALL functions should return a result. Just not a shy one.

      ∇f00∇
     ∇f00←{
[1]        r←⍵
[2]    }
     ∇
      ∇f01∇
     ∇f01←{
[1]        f00 ⍵
[2]    }
     ∇
      f00 2
      ⍝ OK?
      ⎕←f00 2
2
      ⍝ OK 
      f01 3
      ⍝ NOT OK
      ⎕←f01 3
VALUE ERROR: No result was provided when the context expected one
f01[1] f00 ⍵
      ∧
      ⍝ WHAAAAAT???????????????

[Morten|Dyalog]

Yay, I am not alone :-)

Since I feel encouraged, I will add:

* All functions SHOULD return a result (or they are not really functions, are they - functions map data from one domain to another).
* The result SHOULD always be displayed at a six space prompt (unless you "sink" it).
* The result of an expression within a TradFn body SHOULD NOT be displayed unless there is an explicit ⎕←.