[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: suggestion for language extension
- To: Barry Margolin <barmar@Think.COM>
- Subject: Re: suggestion for language extension
- From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
- Date: Tue, 27 Oct 87 01:05 EST
- Cc: cl@DOUGHNUT.CS.ROCHESTER.EDU
- Default-character-style: (:FIX :CONDENSED :NORMAL)
- Fonts: CPTFONTC
- In-reply-to: <871026183445.4.BARMAR@OCCAM.THINK.COM>
- Organization: University of Rochester, Department of Computer Science
- Phone: 716-275-1118
- Postal-address: 401A CS Building, Computer Science Department, University of Rochester, Rochester NY 14627
- Reply-to: email@example.com
- Sender: firstname.lastname@example.org
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 <email@example.com>
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.
Another question: what particular problem does overloading solve for
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!
University of Rochester Computer Science Department