[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
More on MAP
- To: common-lisp@SAIL.STANFORD.EDU
- Subject: More on MAP
- From: VERACSD@A.ISI.EDU
- Date: Thu, 26 Mar 1987 02:37:00 -0000
- Cc: fahlman@C.CS.CMU.EDU, veracsd.rs@A.ISI.EDU
- Sender: VERACSD@A.ISI.EDU
Apropos Scott Fahlman's remarks:
1) I trust Guy Steele was indeed joking in proposing that
> if the first arg to MAP is an integer, it specifies which argument
> should be clobbered
> If you want a destructive operation, you should ask for it by name.
This is reasonable enough. "Samalone", in fact, proposes NMAP.
> it is usually a mistake to overload the same function to do two
> fundamentally different things depending on some subtle type
I buy this in general, but wonder about its application to this case,
since a) how fundamentally different or subtle is it really, b) MAP
already does two different things, when given NIL and when given a
(non-NIL) type specifier, and c) it's basically the overloading of NIL
and certain other (type-specifying) sequences that caused the original
proposal to fail.
4) Perhaps I am putting my foot in my mouth (again), but I question
> it is trivial to define a macro to do the job
of the proposed extension. I imagine Fahlman is thinking of something
like '(replace ,seq (map (type-of ,seq) ,fn ,@sequences), but the
point of the extension was to have a function which accomplishes this
without the extra time and space of consing and the time of replacing.
5) How about NMAP, anyway?