Re: suggestion for language extension

[Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>]

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

	Date: Mon, 26 Oct 87 17:37 EST
	From: Brad Miller <miller@acorn.cs.rochester.edu>

	There is, in fact, something conceptually simple that could be added to the
	spec, is upward compatible with the current language, and would make me sleep
	a lot easier (though compiler writers may groan a bit):

	    Allow overloading of functions.

	This would allow me to create my own first-class objects, since I could
	overload common operators to handle (special case) the new type.

    What do you mean by this?  Do you mean overloading in the Ada sense,
    where you specify the data types of the arguments that cause a
    particular implementation of the function to be invoked?

Yes. Like Ada, the information would be static, unlike Ada, result type
wouldn't (necessarily) need to be taken into account. <doing such would
certainly complicate things, but perhaps be in the lisp philosophy of
run-time coercion of objects when needed.> 

	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...

    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...

	...
    redefined without affecting the advice, which requires hooks in the
    implementation; however, I don't think it is necessary for the
    overloading feature that Brad wants.

Then again...

    Another question: what particular problem does overloading solve for
    you?  

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, and make them accept lazy-lists as well. Some of
them (e.g. reverse) might return an error when you pass them a lazy-list,
but most (e.g. cdr) may run the function associated with the lazy-list to
generate the next item. Once the lazy-list abstraction/type has been
defined, there should be no particular reason existing programs should not
be able to accept/deal with them, so long as the underlying functions have
been taught how to handle them. You have, with this mechanism, *extended the
language* to include the new first class object of lazy-stream, which is
considerably different than defining lazy-cons, lazy-car, .... and having
your program call these functions itself. To the programmer, the extension
is transparent. cons, car, cdr, etc. work on all objects of type list
independent of their lazyness.

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...

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... 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).

Thanks for your interest!
Brad Miller
------
miller@cs.rochester.edu {...allegra!rochester!miller}
Brad Miller
University of Rochester Computer Science Department