Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!mcnc!thorin!prins.cs.unc.edu!prins
From: prins@prins.cs.unc.edu (Jan Prins)
Newsgroups: comp.lang.apl
Subject: Ambivalence [was: Re: Problem with )COPY ]
Message-ID: <7960@thorin.cs.unc.edu>
Date: 28 Apr 89 18:21:37 GMT
References: <49700010@uicsrd.csrd.uiuc.edu> <575@moore.UUCP>
Sender: news@thorin.cs.unc.edu
Lines: 51

In article <49700010@uicsrd.csrd.uiuc.edu>, jaxon@uicsrd.csrd.uiuc.edu writes:
 ... 
   (intelligent remarks concerning use and management of symbols 
    in APL interpreters)
 ...
> 
> In APLB we managed to essentially eliminate symbol-table lookup cost using
> these techniques.  But we did not provide "ambivalent user functions".  In
> fact we are seriously opposed to the APL2 notation for ambivalent function
> templates because their scheme requires a use of #NC (Name Class), which
> costs 1 symbol table lookup, to determine the valence of the current call
> (something which the interpreter just figured out a microsecond ago).  If 
> you add in a collection of dyadic functions that have been modified to
> protect themselves from IBM's silly extension by testing #NC 'LEFT' on
> each line [1], then lookups become more frequent, and the implementer has
> to find a very low cost resizeable hash scheme.
> 
> Isn't anyone angry about APL2-style ambivalence?

It sure seems hokey and, as you point out, seems to require run-time 
symbol-table lookups ... even if you do not want to use it!

A simpler way to support ambivalence in user-defined functions is to permit 
multiple (well, two or three) definitions for the same name, and use the 
interpreter to resolve which definition is invoked.  This requires no run-time 
overhead (modulo the usual caveats about changes in valence and name class
of functions during execution by redefinition -- something which APLB rightly 
treats as the exception rather than the rule and handles accordingly only as
it happens).

I'm sure I've seen some APL system that worked this way.  Or am I thinking of 
direct-definition?  I suppose the objection is that typical definitions
will look like something this:

   DEL Z <- PLUS B    (monadic defn)
[1] Z <- 0 PLUS B
   DEL 

   DEL Z <- A PLUS B  (dyadic defn)
[1] z <- A + B
   DEL

and one might be worried about the additional function call overhead.  I bet
it's not much worse than all the horsing around with #NC, and you could always
remove it by copying in the code from the called functions, I suppose (Yech).

So what APL system supports ambivalence this way?

Jan Prins  (prins@cs.unc.edu)

> jaxon@uicsrd.uiuc.edu (Hi Greg!)