Let me consider NCONC.
In CLHS I read the following about its arguments
"...each but the last must be a list"
But
(mapcan '+ '(1 2) '(3 4))
gives me just 6 (in ACL and CMUCL) without any error or warning.
Could you throw some light on that ?
--
Vladimir Zolotykh
In article <·················@eurocom.od.ua>, Vladimir Zolotykh wrote:
> Let me consider NCONC.
>
> In CLHS I read the following about its arguments
>
> "...each but the last must be a list"
>
> But
>
> (mapcan '+ '(1 2) '(3 4))
>
> gives me just 6 (in ACL and CMUCL) without any error or warning.
> Could you throw some light on that ?
Well, as it says: Each but the last argument /must/ be a list. You
should give it lists, then :-) I guess the consequences of not
doing so are simply undefined. On the LispWorks toplevel, I get
CL-USER 19 > (nconc 4 6)
Error: Signal : segmentation violation(11)
1 (abort) Return to level 0.
2 Return to top loop level 0.
Type :b for backtrace, :c <option number> to proceed, or :? for other options
CL-USER 20 : 1 >
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
Nils Goesche <······@cartan.de> writes:
> Well, as it says: Each but the last argument /must/ be a list. You
> should give it lists, then :-) I guess the consequences of not doing
> so are simply undefined.
It seems to me that CLHS is inconsistent here, as it lists
"Exceptional situations: None". So nconc, as I understand it, must
return a value even if handed non-list arguments. Treating non-conses
as the empty list like most implementations do, seems reasonable.
> On the LispWorks toplevel, I get
>
> CL-USER 19 > (nconc 4 6)
>
> Error: Signal : segmentation violation(11)
This looks like a bug to me.
--
Frode Vatvedt Fjeld
In article <··············@vserver.cs.uit.no>, Frode Vatvedt Fjeld wrote:
> Nils Goesche <······@cartan.de> writes:
>
>> Well, as it says: Each but the last argument /must/ be a list. You
>> should give it lists, then :-) I guess the consequences of not doing
>> so are simply undefined.
>
> It seems to me that CLHS is inconsistent here, as it lists
> "Exceptional situations: None". So nconc, as I understand it, must
> return a value even if handed non-list arguments. Treating non-conses
> as the empty list like most implementations do, seems reasonable.
>
>> On the LispWorks toplevel, I get
>>
>> CL-USER 19 > (nconc 4 6)
>>
>> Error: Signal : segmentation violation(11)
>
> This looks like a bug to me.
Hmm. The documentation of rplacd says:
# Exceptional Situations: None.
# Should signal an error of type type-error if cons is not a cons.
Strange :-)
Maybe somewhere else is specified what happens when you give a non-list
when the specification says ``must be a list'', or that the behavior
is just... undefined. I am still searching...
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
In article <··············@ID-125440.news.dfncis.de>, Nils Goesche wrote:
> In article <··············@vserver.cs.uit.no>, Frode Vatvedt Fjeld wrote:
>> Nils Goesche <······@cartan.de> writes:
>>
>>> Well, as it says: Each but the last argument /must/ be a list. You
>>> should give it lists, then :-) I guess the consequences of not doing
>>> so are simply undefined.
>>
>> It seems to me that CLHS is inconsistent here, as it lists
>> "Exceptional situations: None". So nconc, as I understand it, must
>> return a value even if handed non-list arguments. Treating non-conses
>> as the empty list like most implementations do, seems reasonable.
>>
>>> On the LispWorks toplevel, I get
>>>
>>> CL-USER 19 > (nconc 4 6)
>>>
>>> Error: Signal : segmentation violation(11)
>>
>> This looks like a bug to me.
>
> Hmm. The documentation of rplacd says:
>
> # Exceptional Situations: None.
>
> # Should signal an error of type type-error if cons is not a cons.
>
> Strange :-)
>
> Maybe somewhere else is specified what happens when you give a non-list
> when the specification says ``must be a list'', or that the behavior
> is just... undefined. I am still searching...
Here we go:
In 1.4.4.3 it says
# Except as explicitly specified otherwise, the consequences are
# undefined if these type restrictions are violated.
and in 1.4.2:
# The consequences are undefined
# This means that the consequences are unpredictable. The consequences
# may range from harmless to fatal. No conforming code may depend on
# the results or effects. Conforming code must treat the consequences
# as unpredictable. In places where the words ``must,'' ``must not,''
# or ``may not'' are used, then ``the consequences are undefined''
# if the stated requirement is not met and no specific consequence
# is explicitly stated. An implementation is permitted to signal an
# error in this case.
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
In article <··············@vserver.cs.uit.no>,
Frode Vatvedt Fjeld <······@acm.org> wrote:
>Nils Goesche <······@cartan.de> writes:
>
>> Well, as it says: Each but the last argument /must/ be a list. You
>> should give it lists, then :-) I guess the consequences of not doing
>> so are simply undefined.
>
>It seems to me that CLHS is inconsistent here, as it lists
>"Exceptional situations: None". So nconc, as I understand it, must
>return a value even if handed non-list arguments. Treating non-conses
>as the empty list like most implementations do, seems reasonable.
All functions require their arguments to be of the types specified in the
Syntax section. This isn't generally mentioned in the Exceptional
Situations section (although sometimes it is, for some reason). For
instance, RPLACA also says "Exceptional sitations: None", but it clearly
makes no sense if the first argument isn't a cons.
I'm sure this general requirement is stated somewhere in the CLHS, but I'm
damned if I can find it.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, 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.
Frode Vatvedt Fjeld <······@acm.org> writes:
> Nils Goesche <······@cartan.de> writes:
>
> > Well, as it says: Each but the last argument /must/ be a list. You
> > should give it lists, then :-) I guess the consequences of not doing
> > so are simply undefined.
>
> It seems to me that CLHS is inconsistent here, as it lists
> "Exceptional situations: None". So nconc, as I understand it, must
> return a value even if handed non-list arguments. Treating non-conses
> as the empty list like most implementations do, seems reasonable.
You should NEVER read the exceptional situations as an exhaustive
enumeration of things signalled.
It might have been the goal to one day do that, but all it turned out to
be as an extension of the Description where if there was a condition that
could be explained out of context, we tried to move the text there.
Seeing "None." does not mean "There are no exceptional situations signaled
by this operator" it means "There was no additional information beyond that
in the Description that goes here".
Also, notwithstanding anything it ever says in that field, it is always
possible to get errors due to resource exhausted (e.g., stack), wrong
numbers of args, etc.
> > On the LispWorks toplevel, I get
> >
> > CL-USER 19 > (nconc 4 6)
> >
> > Error: Signal : segmentation violation(11)
>
> This looks like a bug to me.
It's a programmer bug, not a bug in the LispWorks implementation.
| 1.4.4.3 The ``Arguments and Values'' Section of a Dictionary Entry
|
| ... Except as explicitly specified otherwise, the consequences are
| undefined if these type restrictions are violated.
| 1.4.2 Error Terminology
|
| ...
| The consequences are undefined
|
| This means that the consequences are unpredictable. The consequences
| may range from harmless to fatal. No conforming code may depend on the
| results or effects. Conforming code must treat the consequences as
| unpredictable. In places where the words ``must,'' ``must not,'' or
| ``may not'' are used, then ``the consequences are undefined'' if the
| stated requirement is not met and no specific consequence is
| explicitly stated. An implementation is permitted to signal an error
| in this case.
| ...