Re: Distinguish primitive and defined functions inside an operator

Thomas Buchholz wrote:
> I wonder if there is a way in IBM APL2 for Windows to distinguish inside
> a defined operator whether or not the operator was called with some
> primitive function.
>
> Since there is actually no fill function implemeted for the Each
> operator I would like to mimic it using some defined operator E{<-}L(F
> EACH)R. In the monadic case the result of EACH on an empty R would
> therefore be E{<-}({rho}R){rho}{enclose}F{first}R if F is a primitive
> function and E{<-}R if F is a defined one. (BTW: does the Mainframe
> version really behave in that manner?)
>
> Any ideas would be gratefully appreciated.

Taking F as the left operand, look at the result of

'0' {[]}EA '{[]}CR''F'''

I believe this produces a detectable difference between defined and
primitive operands.

David Liebtag wrote:
> Mike,
>
> I don't know why you used QuadCR inside QuaDEA, but whatever the reason, I
> don't think your example provides you with a way to detect whether the
> operand is primitive or not.  You get the same result for locked defined
> functions as you get for primitives.

OK, but for many of us this is a theoretical limitation rather than
a practical one.  I have not run into any locked code in the past
fifteen years or so.

Do you get the same result for external functions (i.e, are they
treated as locked)?   That might be more of a practical issue.

David Liebtag wrote:
> Mike,
>
> I don't know why you used QuadCR inside QuaDEA, but whatever the reason,

Because I don't have access to an APL2 system at the moment; the
OS/2 system I keep alive just so I can run APL2 is temporarily
out of service, I could not check that QuadCR won't throw an error
when applied to an operand name (for example, if the operand
is a derived function ...).  So:  I wrapped some exception handling
around the call to QuadCR.