Re: suggestion for language extension

[Barry Margolin <barmar@Think.COM>]

    Date: Tue, 27 Oct 87 01:05 EST
    From: Brad Miller <miller@acorn.cs.rochester.edu>

	Date: Mon, 26 Oct 87 18:34 EST
	From: Barry Margolin <barmar@Think.COM>

	    I believe CLOS
	will allow this, although there will probably be some restrictions on
	the built-in functions that may be converted to generic functions (my
	feeling is that only functions proclaimed INLINE should be restricted).

    I don't think this would be general enough, see following...

It seems completely general to me.  Anything that isn't open-coded could
be turned into a generic function that dispatches on the data types of
its arguments.  What more do you need?

	You mentioned that overloading could be implemented using an ADVISE
	feature.  A simple-minded ADVISE can be implemented using existing CL
	facilities, so there is no real need for extending the language:

    This (a macro) does not alter the run-time semantics of already compiled
    programs, which would be necessary...

Why doesn't it?  It redefines the function you want to overload.  Unless
the function you are overloading was originally a macro or open-coded
function, future calls will go to the new definition.  Before we got
into the habit of customizing the Symbolics environment using ADVISE we
used something like it all the time.

    What I would *like* to do...

    Take the example of creating something that is a (possibly infinite) list,
    but lazy-eval'd. So you want to overload all the existing CL functions that
    can possibly accept lists, 

That's a LOT of functions!

			       and make them accept lazy-lists as well.
    ... cons, car, cdr, etc. work on all objects of type list
    independent of their lazyness.

Except that most of the functions already in the environment had CAR and
CDR compiled inline, so they won't pick up the overloaded definition.

    The main intent (for me particularly) is to get scheme-style streams up, but
    I figured other people might want to create first class objects too...

Scheme-style streams don't require overloading.  In Scheme you use
different functions (HEAD, TAIL) to get the items of a stream from the
ones used to get items in a list (CAR, CDR).  Scheme doesn't have any
special overloading support, either.

    The other thing I *really* would like is scheme-style continuations, but I
    suspect this sort of thing would be politically non-feasible at this point.
    Overloading helps, in that I can make continuations first class objects, but
    getting to just what a continuation is would still be hard since you need to
    snapshot the stack... 

CL already knows how to snapshot the stack, to make lexical closures.
The problem is that there are some arbitrary limitations on what a
closure can do.

			  This sort of thing may be better addressed as
    something CL would provide explicitly; I can't think of general underlying
    mechanisms that solve continuations that would also be useful to make
    generally available because of their utility in extending the language.
    (without consing up infinite hair in terms of concrete language semantics).

All that needs to be done to CL to make continuations as useful as they
are in Scheme is to change the extent of CATCH tags, BLOCK names, and
TAGBODY labels from dynamic to indefinite.  Unfortunately, this would be
a significant change to the language, and I'm not sure that its impact
on existing implementations would be worth the gain.  But if those
restrictions were lifted, the following definition of CALL/CC would
suffice:

(defmacro call/cc (function &rest args &aux (block-name (gensym)))
  `(block ,block-name
     (funcall ,function
	      #'(lambda (&rest results)
		  (return-from ,block-name (values-list results)))
	      .,args)))

I'm not a Scheme programmer, and I don't know what the value of being
able to transfer into a function that already returned is.  One thing I
believe CALL/CC is used for is coroutines, and the above CL
implementation will support that; however, without tail-recursion
optimization you will get pretty deep pretty quickly.

                                                barmar