I-beam

[Phil Last]

There is now a plethora of i-beam invocations that do all sorts of useful and not-so-useful stuff.
From the Dyalog help pages:

WARNING: Although documentation is provided for I-Beam functions, any service provided using I-Beam should be considered as “experimental” and subject to change – without notice - from one release to the next. Any use of I-Beams in applications should therefore be carefully isolated in cover-functions that can be adjusted if necessary.

This is all very well. But experiments tend to come to an eventual conclusion not dissimilar to the APL signum function applied to reals: ¯1 0 1
What do (does?) Dyalog intend to do with the positives?
A little bird suggested that the functionality of such calls eventually might be implemented as system functions. Heaven forbid. We have too many already. Do we really want countless others?
The syntax is tried and tested. I believe there is a number of unicode glyphs dedicated to APL use which still seek a use. Why not just create a new operator with identical syntax but a different glyph to which proved functions are transferred identically? Precedents are the Foreign conjunction !: of J and the circle function ○ of APL.
If 9876⌶ works, is useful and has stood the test of time over a year or four, implement it as 9876(whatever).

[ray]

I like Phil's idea of promoting an experimental function from I-Beam to Premiership APL by replacing the I-Beam glyph by another. So 12345678⌶ becomes 12345678<some new glyph>. No new System function for each new ex-I-Beam, just a single new glyph for all the ex-I-Beams.

However at a later date, can the number (in my example 12345678) be safely "recycled" for use for another experimental function with I-Beam?

IMHO I think not.

That being the case, do we really need to use a new glyph, or can we just continue to use the I-Beam?

So, next, how do we tell experimental from promoted I-Beam functions?

All I-Beams are colour coded (as element type "System Function" I think).

Possibly, promoted I-Beam functions, (number + I-Beam) could then be colour coded as an idiom to show their new status?

Or even better, experimental I-Beam function defined as an "element" with it's own colour coding. In which case I would show them with a non-standard background colour, (just as I do for errors for which I use red on yellow). Once promoted, they would lose their experimental status.

[Morten|Dyalog]

A little bird suggested that the functionality of such calls eventually might be implemented as system functions. Heaven forbid. We have too many already. Do we really want countless others?

The numbering (some have proposed naming), and documenting of I-Beams is a tricky subject, which regularly gives rise to, ah, animated discussions within the Dyalog development team. The number of I-Beams is significantly larger than the public documentation would suggest. They are used for (often very short lived) experimental new algorithms for primitives, for highly speculative language features, to access otherwise unexposed bits of the interpreter in order to write quality assurance scripts, and for features which are only described to clients for whom they have been developed under contract.

The ability to implement such features without a “full blown” language discussion to debate the merits of a new feature in a 50-year perspective is invaluable. From time to time, we decide that it is “in the public interest” to publish the documentation of one or more selected I-Beams. However, this does not necessarily mean that it will be there for ever, it may be covering a gap that will eventually be filled by a primitive or a system function. Thus, it is not clear that we would ever pronounce an I-beam as “permanent”.

Application developers MUST NOT assume that any I-beam will be there forever. If you use an I-Beam, you must also think about what you will do if it disappears, by encapsulating the actual I-Beam calls in cover-functions that you will one day be prepared to rewrite, and having a contingency plan to rewrite any strategies that rely on the functionality.

In this particular case, I believe that your “little bird” was referring specifically to the experimental functionality for data binding that he is currently working on. In this case, I am hoping that, once we have spent some years fully understanding the issues, we will decide that data binding is such a “fundamental” feature that we should define a system function for it (or even a primitive). However, I don't really see any other candidate system functions in the list of documented I-beams, other than perhaps rolling the choice of a random number algorithm into ⎕RL.