No Result for ⎕R?

[JohnS|Dyalog]

FWIW: the "official" way to return a shy result from a dfn is with a guarded assignment.

      1:shy←...

As per: http://dfns.dyalog.com/n_refcard.htm

[paulmansour]

Three.

Some questions:

1. Is there any reason for a shy result other than not displaying in the session?

2. What would be the implications of eliminating shy results in some future version? Anything more than the annoyance of some unwanted output in the session?

In other words, is there any implication at all for working code?

[JohnS|Dyalog]

1. Is there any reason for a shy result other than not displaying in the session?

I think the main reason is with a procedure, which produces a side-effect but whose result is, more-often-than-not, of no interest - eg ⎕EX.

Because we have them, I've used shy results in supplied workspaces min and max to return the environment from a min/max interactive session. This binary state is of use only to initialise a subsequent min/max session but could be quite large and I can't think of a circumstance when it would be useful to see it displayed.

2. What would be the implications of eliminating shy results in some future version? Anything more than the annoyance of some unwanted output in the session?

I don't believe so.

In other words, is there any implication at all for working code?

Theoretically, a shy-result-returning function need not spend time constructing its result if the calling context doesn't require one. Having said this, I would be surprised if changing this made any impact on a typical app's performance.

Of course, the shy result of an assignment would need to stay shy and there's an interesting question about the shy result of execute, as in:

      ⍎(0=⎕nc'Larg')/'Larg←0'

A separate question is: whether dfns should continue to be allowed to return void (no result).

[petermsiegel]

Back to the question on whether things like implicit output and shy results are good, useful evils, or things to be rid of... I suppose there is a debate to be had, if only in fun. I'll just say that implicit output has been a mainstay of APL since the APL\360 days and really useful when teaching students APL in the context of packages for statistics, linear algebra, or the like. Other languages like R and Python likely adopted implicit output from APL, or deployed it for similar reasons-- lots of users who create ad hoc functions for exploration and want to try things out -- in an incremental session, rather than by repeated compiles.

But the only place I'd really want to debate is on when to adhere to formal mathematical definitions within programming languages versus expanding definitions where programmatically useful, practical, and possibly of pedagogical value. I'd argue that the latter has been a part of the DNA of APL as implemented from the beginning, but here's my two pfennigs. If you want formal elegance, I'd push for making functions true first-class objects and cleaving off niladic functions from the function family (they are odd ducks, aren't they?) to make it possible to do so elegantly. In fact, I'd trade shy results for functions as first class objects any day, if only to avoid seeing too much Javascript.