From: Arthur Lemmens
Subject: Re: How to do (map (type-of x) ...) right
Date: 
Message-ID: <3AD6A916.EDE25CBC@xs4all.nl>
Clemens Heitzinger wrote:

> I want to write a function that takes a sequence, maps a function over
> it, and returns a sequence of the same type.
> 
> Let's see:
> 
> USER(178): (defun foo (x)
>                (map (type-of x) #'log x))
> FOO
> USER(179): (foo (vector 1 2 3))
> #(0.0 0.6931472 1.0986123)
> USER(180): (foo (list 1 2 3))
> Error: CONS is an invalid output type specifier.

I think that's a bug in your implementation. The spec says "If the 
result-type is a subtype of list, the result will be a list." and 
it seems clear to me that CONS is a subtype of LIST.

FWIW, your code works fine in Lispworks 4.1.19.

Arthur Lemmens

From: Sam Steingold
Subject: Re: How to do (map (type-of x) ...) right
Date: 
Message-ID: <u8zl0vlpf.fsf@xchange.com>
> * In message <··············@rainbow.studorg.tuwien.ac.at>
> * On the subject of "Re: How to do (map (type-of x) ...) right"
> * Sent on 13 Apr 2001 09:37:17 +0200
> * Honorable Clemens Heitzinger <········@rainbow.studorg.tuwien.ac.at> writes:
> Arthur Lemmens <········@xs4all.nl> writes:
> 
> > I think that's a bug in your implementation. The spec says "If the 
> > result-type is a subtype of list, the result will be a list." and 
> > it seems clear to me that CONS is a subtype of LIST.
> 
> You are right, thanks.  Both ACL 5.0 and Clisp 2.25.1 get it wrong.
> SBCL 0.6.11 gets it right.

This bug has just been fixed in the CLISP CVS.
Thanks.

-- 
Sam Steingold (http://www.podval.org/~sds)
If it has syntax, it isn't user friendly.
From: Kent M Pitman
Subject: Re: How to do (map (type-of x) ...) right
Date: 
Message-ID: <sfwoftwsqtm.fsf@world.std.com>
Sam Steingold <···@gnu.org> writes:

> > * In message <··············@rainbow.studorg.tuwien.ac.at>
> > * On the subject of "Re: How to do (map (type-of x) ...) right"
> > * Sent on 13 Apr 2001 09:37:17 +0200
> > * Honorable Clemens Heitzinger <········@rainbow.studorg.tuwien.ac.at> writes:
> > Arthur Lemmens <········@xs4all.nl> writes:
> > 
> > > I think that's a bug in your implementation. The spec says "If the 
> > > result-type is a subtype of list, the result will be a list." and 
> > > it seems clear to me that CONS is a subtype of LIST.

Bleah, whoever edited that text should be shot.  NIL is a subtype of LIST,
though I suppose technically since (map nil ...) returns NIL, the claim
about subtypes of list as a type yielding list results is technically
(read: accidentally) true.

> > You are right, thanks.  Both ACL 5.0 and Clisp 2.25.1 get it wrong.
> > SBCL 0.6.11 gets it right.
> 
> This bug has just been fixed in the CLISP CVS.
> Thanks.

Looks like LispWorks 4.1.20 gets
 (map 'cons '1+ '(1 2 3)) => (2 3 4) ;correct
 (map 'null '1+ '(1 2 3)) => error   ;incorrect
 (map 'nil  '1+ '(1 2 3)) => nil     ;correct
Sigh.  (Did everyone try the middle, pathologically awful example in those
other implementations?)
From: Carl Shapiro
Subject: Re: How to do (map (type-of x) ...) right
Date: 
Message-ID: <ouybspwka4f.fsf@panix3.panix.com>
Kent M Pitman <······@world.std.com> writes:

> Looks like LispWorks 4.1.20 gets
>  (map 'cons '1+ '(1 2 3)) => (2 3 4) ;correct
>  (map 'null '1+ '(1 2 3)) => error   ;incorrect
>  (map 'nil  '1+ '(1 2 3)) => nil     ;correct
> Sigh.  (Did everyone try the middle, pathologically awful example in those
> other implementations?)

In the middle case, Lucid returns nil and Genera returns (2 3 4).

Which is correct? 
From: Kent M Pitman
Subject: Re: How to do (map (type-of x) ...) right
Date: 
Message-ID: <sfwlmp0sofd.fsf@world.std.com>
Carl Shapiro <········@panix.com> writes:

> 
> Kent M Pitman <······@world.std.com> writes:
> 
> > Looks like LispWorks 4.1.20 gets
> >  (map 'cons '1+ '(1 2 3)) => (2 3 4) ;correct
> >  (map 'null '1+ '(1 2 3)) => error   ;incorrect
> >  (map 'nil  '1+ '(1 2 3)) => nil     ;correct
> > Sigh.  (Did everyone try the middle, pathologically awful example in those
> > other implementations?)
> 
> In the middle case, Lucid returns nil and Genera returns (2 3 4).
> 
> Which is correct? 

I guess I'd have assumed that the intent was that the argument of NULL
or CONS behaved similarly to an UPGRADED-ARRAY-ELEMENT-TYPE, and so was
equivalent to passing LIST.  Consequently, I'd expect (2 3 4).  But I'd
stop short of saying that's what's "correct" or "required".   It seems
a matter over which people could legitimately disagree.

It's hard to construct a case where someone passes NULL and yet passes
all non-null lists as args. (When they pass NULL and only NIL's as args,
the issue is moot.)  However, the case I can imagine happening is someone
treating the vector/list issue as a loop invariant and factoring it out,
so they do:
  (let ((q (all-vectors-or-all-lists))
        (result-type (type-of (first q))))
    (mapcar #'(lambda (q0) (map result-type fn q0))
            q))
only to find that the first of q is pathologically null instead of cons.      
Since the alternative is to write:
  (let ((q (all-vectors-or-all-lists)))
    (mapcar #'(lambda (q0) (map (type-of q) fn q0)) q))
and in this case you'd get (2 3 4) from any given call to MAP where
fn was 1+ and q0 was (1 2 3), then I guess I think that if NULL was
passed, the likely desired value would be the same.  In other words, I
think the most likely case where the confusing situation of
 (map 'NULL fn non-null)
is where 
 (map 'LIST fn non-null)
is intended, not where
 (map 'NULL fn NIL)
is intended.  The latter looks to me to be quite unlikely, so modeling
the return value after that seems a bad plan.
From: Sam Steingold
Subject: Re: How to do (map (type-of x) ...) right
Date: 
Message-ID: <u3db8vgxn.fsf@xchange.com>
> * In message <···············@world.std.com>
> * On the subject of "Re: How to do (map (type-of x) ...) right"
> * Sent on Mon, 16 Apr 2001 17:21:57 GMT
> * Honorable Kent M Pitman <······@world.std.com> writes:
>
> Sam Steingold <···@gnu.org> writes:
> 
> > This bug has just been fixed in the CLISP CVS.
> 
> Looks like LispWorks 4.1.20 gets
>  (map 'cons '1+ '(1 2 3)) => (2 3 4) ;correct
>  (map 'null '1+ '(1 2 3)) => error   ;incorrect
>  (map 'nil  '1+ '(1 2 3)) => nil     ;correct
> Sigh.  (Did everyone try the middle, pathologically awful example in those
> other implementations?)

the current CLISP:

[1]> (map 'cons '1+ '(1 2 3))
(2 3 4)
[2]> (map 'null '1+ '(1 2 3))
(2 3 4)
[3]> (map 'nil  '1+ '(1 2 3))
NIL

-- 
Sam Steingold (http://www.podval.org/~sds)
The only intuitive interface is the nipple.  The rest has to be learned.
From: Erik Naggum
Subject: Re: How to do (map (type-of x) ...) right
Date: 
Message-ID: <3196435586928252@naggum.net>
* Kent M Pitman
> Bleah, whoever edited that text should be shot.

  Hang in there for yet another while, please.  :)

> NIL is a subtype of LIST,

  No.  `null' is a subtype of `list'.  `nil' is not a type specifier.

#:Erik
-- 
  I found no peace in solitude.
  I found no chaos in catastrophe.
			-- :wumpscut:
From: Kent M Pitman
Subject: Re: How to do (map (type-of x) ...) right
Date: 
Message-ID: <sfwg0f8d3zs.fsf@world.std.com>
Erik Naggum <····@naggum.net> writes:

> 
> * Kent M Pitman
> > Bleah, whoever edited that text should be shot.
> 
>   Hang in there for yet another while, please.  :)
> 
> > NIL is a subtype of LIST,
> 
>   No.  `null' is a subtype of `list'.  `nil' is not a type specifier.

(subtypep 'nil 'list) => t, t

The empty type is a subtype of all types.
From: Barry Margolin
Subject: Re: How to do (map (type-of x) ...) right
Date: 
Message-ID: <heIC6.447$U4.19042@burlma1-snr2>
In article <···············@world.std.com>,
Kent M Pitman  <······@world.std.com> wrote:
>Erik Naggum <····@naggum.net> writes:
>
>> 
>> * Kent M Pitman
>> > Bleah, whoever edited that text should be shot.
>> 
>>   Hang in there for yet another while, please.  :)
>> 
>> > NIL is a subtype of LIST,
>> 
>>   No.  `null' is a subtype of `list'.  `nil' is not a type specifier.
>
>(subtypep 'nil 'list) => t, t
>
>The empty type is a subtype of all types.

True.  But in the context of the first argument to MAP, it's treated
specially, to mean that no result should be accumulated, not treated as a
type specifier (although the fact that no returned value could be an
element of the empty type was presumably the reason for this design).

-- 
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Pierre R. Mai
Subject: Re: How to do (map (type-of x) ...) right
Date: 
Message-ID: <87puecoihi.fsf@orion.bln.pmsf.de>
Kent M Pitman <······@world.std.com> writes:

> > > Arthur Lemmens <········@xs4all.nl> writes:
> > > 
> > > > I think that's a bug in your implementation. The spec says "If the 
> > > > result-type is a subtype of list, the result will be a list." and 
> > > > it seems clear to me that CONS is a subtype of LIST.
> 
> Bleah, whoever edited that text should be shot.  NIL is a subtype of LIST,
> though I suppose technically since (map nil ...) returns NIL, the claim
> about subtypes of list as a type yielding list results is technically
> (read: accidentally) true.

[...]

> Looks like LispWorks 4.1.20 gets
>  (map 'cons '1+ '(1 2 3)) => (2 3 4) ;correct
>  (map 'null '1+ '(1 2 3)) => error   ;incorrect
>  (map 'nil  '1+ '(1 2 3)) => nil     ;correct
> Sigh.  (Did everyone try the middle, pathologically awful example in those
> other implementations?)

FWIW CMU CL gets all cases right, i.e. 

* (map 'null '1+ '(1 2 3)) 

(2 3 4)
* (map 'cons '1+ '(1 2 3))

(2 3 4)
* (map 'nil '1+ '(1 2 3))

NIL

Regs, Pierre.

-- 
Pierre R. Mai <····@acm.org>                    http://www.pmsf.de/pmai/
 The most likely way for the world to be destroyed, most experts agree,
 is by accident. That's where we come in; we're computer professionals.
 We cause accidents.                           -- Nathaniel Borenstein
From: Frank A. Adrian
Subject: Re: How to do (map (type-of x) ...) right
Date: 
Message-ID: <C9QC6.743$FV.739050@news.uswest.net>
And for another entrant in the "who's got it right" map contest, Corman Lisp
does fine with type specifiers 'cons and nil, but flunks with an error on
'null.  A patch has been sent Roger's way (not that he probably hasn't
already fixed it after reading this discussion).

faa

"Arthur Lemmens" <········@xs4all.nl> wrote in message
······················@xs4all.nl...
>
> Clemens Heitzinger wrote:
>
> > I want to write a function that takes a sequence, maps a function over
> > it, and returns a sequence of the same type.
> >
> > Let's see:
> >
> > USER(178): (defun foo (x)
> >                (map (type-of x) #'log x))
> > FOO
> > USER(179): (foo (vector 1 2 3))
> > #(0.0 0.6931472 1.0986123)
> > USER(180): (foo (list 1 2 3))
> > Error: CONS is an invalid output type specifier.
>
> I think that's a bug in your implementation. The spec says "If the
> result-type is a subtype of list, the result will be a list." and
> it seems clear to me that CONS is a subtype of LIST.
>
> FWIW, your code works fine in Lispworks 4.1.19.
>
> Arthur Lemmens
From: Kent M Pitman
Subject: Re: How to do (map (type-of x) ...) right
Date: 
Message-ID: <sfwbspv4vos.fsf@world.std.com>
"Frank A. Adrian" <·······@uswest.net> writes:

> And for another entrant in the "who's got it right" map contest, Corman Lisp
> does fine with type specifiers 'cons and nil, but flunks with an error on
> 'null.  A patch has been sent Roger's way (not that he probably hasn't
> already fixed it after reading this discussion).

Xanalys support pushed back at me with this clause form the exceptional
situations:

 An error of type type-error should be signaled if result-type
 specifies the number of elements and the minimum length of the
 sequences is different from that number.

We're still quibbling back and forth over whether this applies.
My position is this is intended for (array 50) kinds of situations,
not for cons/null.  It looks to me like the cons/null thing is being
treated in the style of upgraded-array-element-type and must first 
override the given spec before the error situations can be interpreted,
but I've not seen whether this argument convinces them.

Certainly their argument is the strongest counter-argument I've seen.

I suppose I should dig out the TeX sources and see if there's any insight
in them.  Sometimes there's a comment saying why something was done...