There is a probably a better way to do this, but I find a I often need
to take a sequence (that may be either a list or a vector a priori),
and turn it into a vector:
(defun to-vector (seq)
(map 'vector #'identity seq))
Also, consider functions which operate on sequences --- sort is a
classic example. These generally take a :key keyword parameter, which
is the operation to apply to each object before applying a comparison.
For example, (sort foo #'< :key #'car) would sort a sequence of lists
whose car's were all numeric by increasing car order. When writing
functions of this type, it is quite natural to have :key default to
#'identity.
rif
rif wrote:
> There is a probably a better way to do this, but I find a I often need
> to take a sequence (that may be either a list or a vector a priori),
> and turn it into a vector:
>
> (defun to-vector (seq)
> (map 'vector #'identity seq))
Isn't this simpler?:
(defun to-vector (seq)
(coerce seq 'vector))
David Sletten wrote:
> rif wrote:
>
>> There is a probably a better way to do this, but I find a I often need
>> to take a sequence (that may be either a list or a vector a priori),
>> and turn it into a vector:
>>
>> (defun to-vector (seq)
>> (map 'vector #'identity seq))
>
>
>
> Isn't this simpler?:
> (defun to-vector (seq)
> (coerce seq 'vector))
Isn't that why rif opened with "There is probably a better way to do
this, but..."?
:)
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
>
>
> David Sletten wrote:
>
>> rif wrote:
>>
>>> There is a probably a better way to do this, but I find a I often need
>>> to take a sequence (that may be either a list or a vector a priori),
>>> and turn it into a vector:
>>>
>>> (defun to-vector (seq)
>>> (map 'vector #'identity seq))
>>
>>
>>
>>
>> Isn't this simpler?:
>> (defun to-vector (seq)
>> (coerce seq 'vector))
>
>
> Isn't that why rif opened with "There is probably a better way to do
> this, but..."?
>
> :)
>
> kenny
>
>
Perhaps my uncertainty about whether or not my way _was_ the "better"
way wasn't obvious enough... :)
David Sletten <·····@slytobias.com> writes:
> Kenny Tilton wrote:
>
> > David Sletten wrote:
> >
> >> rif wrote:
> >>
> >>> There is a probably a better way to do this, but I find a I often need
> >>> to take a sequence (that may be either a list or a vector a priori),
> >>> and turn it into a vector:
> >>>
> >>> (defun to-vector (seq)
> >>> (map 'vector #'identity seq))
> >>
> >>
> >>
> >>
> >> Isn't this simpler?:
> >> (defun to-vector (seq)
> >> (coerce seq 'vector))
> > Isn't that why rif opened with "There is probably a better way to do
> > this, but..."?
> > :)
> > kenny
> >
> Perhaps my uncertainty about whether or not my way _was_ the "better"
> way wasn't obvious enough... :)
That seems better to me. It honestly never occurred to me to use
coerce on a sequence. Thanks.
rif
>>>>> "David" == David Sletten <·····@slytobias.com> writes:
David> rif wrote:
>> There is a probably a better way to do this, but I find a I often need
>> to take a sequence (that may be either a list or a vector a priori),
>> and turn it into a vector:
>> (defun to-vector (seq)
>> (map 'vector #'identity seq))
David> Isn't this simpler?:
David> (defun to-vector (seq)
David> (coerce seq 'vector))
But aren't these different? The first always gives you a new vector.
But the second won't if seq is already a vector. (I think.)
Ray
Raymond Toy wrote:
>>>>>>"David" == David Sletten <·····@slytobias.com> writes:
>
>
> David> rif wrote:
> >> There is a probably a better way to do this, but I find a I often need
> >> to take a sequence (that may be either a list or a vector a priori),
> >> and turn it into a vector:
> >> (defun to-vector (seq)
> >> (map 'vector #'identity seq))
>
>
> David> Isn't this simpler?:
> David> (defun to-vector (seq)
> David> (coerce seq 'vector))
>
> But aren't these different? The first always gives you a new vector.
> But the second won't if seq is already a vector. (I think.)
IANALL, but you get a lot of support here:
"4.4.24 coerce Function
.....
Description:
Coerces the object to type result-type.
If object is already of type result-type, the object itself is
returned, regardless of whether it would have been possible in general
to coerce an object of some other type to result-type. "
But what does that whole "regardless..." clause mean?
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
In article <·······················@twister.nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> wrote:
> Description:
> Coerces the object to type result-type.
>
> If object is already of type result-type, the object itself is
> returned, regardless of whether it would have been possible in general
> to coerce an object of some other type to result-type. "
>
> But what does that whole "regardless..." clause mean?
Consider (coerce 'hash-table <something>). Normally, there's no way to
coerce something to a hash table, so a naive implementation of COERCE
might have chosen to report an error unconditionally in this case. But
it actually has to check first whether <something> is a hash table.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Kenny Tilton wrote:
> Description:
> Coerces the object to type result-type.
>
> If object is already of type result-type, the object itself is
> returned, regardless of whether it would have been possible in general
> to coerce an object of some other type to result-type. "
>
> But what does that whole "regardless..." clause mean?
If the identity conversion from some specific type T to itself is the
only reasonable one for that type, it would have been possible for
COERCE to reject working on that type altogether (for similar reasons
that some people think that nil and #f should be different things, or
(car nil) and (cdr nil) should raise errors).
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
Pascal Costanza wrote:
>
> Kenny Tilton wrote:
>
>> Description:
>> Coerces the object to type result-type.
>>
>> If object is already of type result-type, the object itself is
>> returned, regardless of whether it would have been possible in general
>> to coerce an object of some other type to result-type. "
>>
>> But what does that whole "regardless..." clause mean?
>
>
> If the identity conversion from some specific type T to itself is the
> only reasonable one for that type, it would have been possible for
> COERCE to reject working on that type altogether (for similar reasons
> that some people think that nil and #f should be different things, or
> (car nil) and (cdr nil) should raise errors).
Two follow-ups: I suspected something like this, but could not find any
discussion of types to which nothing of any other type can be coerced.
That is just a failure of my imagination. But my second question is why
this is added as a qualifier to the preceding part of the sentence. The
two seem unrelated. Could it have read?: "coercion to a type to which no
other type can be coerced is allowed if the object is already of that
type, in which case the object itself is returned."
Mind you I am just picking nits.
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Pascal Costanza wrote:
> If the identity conversion from some specific type T to itself is the
> only reasonable one for that type, it would have been possible for
> COERCE to reject working on that type altogether (for similar reasons
> that some people think that nil and #f should be different things, or
> (car nil) and (cdr nil) should raise errors).
>
What is #f ?
Andr�
--
On Thu, 20 May 2004 19:18:43 +0200, Andr� Thieme wrote:
> Pascal Costanza wrote:
>
>> If the identity conversion from some specific type T to itself is the
>> only reasonable one for that type, it would have been possible for
>> COERCE to reject working on that type altogether (for similar reasons
>> that some people think that nil and #f should be different things, or
>> (car nil) and (cdr nil) should raise errors).
>>
>
> What is #f ?
>
>
> Andr�
Scheme, a dialect of Lisp (if I can say that here without provoking a
flame fest?), separates nil into two different things:
1) something that is used to mark the end of a list.
2) something that is the "false" value (everything apart from this value
is considered to be "true"). In Scheme the "false" value is named #f.
Common Lisp doesn't separate these two things, so nil is used for both of
them. For reasons I don't properly understand, some people get very
excited about this and insist that one way (separating or not separating)
is the God-given right way to do it. I've used Common Lisp for a while,
and Scheme for a while longer, and I'm perfectly happy doing it either way.
Cheers,
Bill.
--
Dr. William Bland.
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax. (Ken Anderson).
William Bland wrote:
> Scheme, a dialect of Lisp (if I can say that here without provoking a
> flame fest?), separates nil into two different things:
>
> 1) something that is used to mark the end of a list.
> 2) something that is the "false" value (everything apart from this value
> is considered to be "true"). In Scheme the "false" value is named #f.
>
> Common Lisp doesn't separate these two things, so nil is used for both of
> them. For reasons I don't properly understand, some people get very
> excited about this and insist that one way (separating or not separating)
> is the God-given right way to do it.
It even goes as far that Guy Steele and Richard Gabriel have spent two
whole pages about that issue in their paper about the history of Lisp
[1]. They conclude that section with the following paragraph:
"This may seem to the reader to be a great deal of discussion to expend
in this paper on such a small point of language design. However, the
space taken here reflects accurately the proportion of time and energy
in debate actually expended on this point by the Lisp community over the
years. It is a debate about expressiveness versus cleanliness and about
different notions of clarity. Even if Lisp does not enforce strong
typing, some programmers prefer to maintain a type discipline in their
code, writing (if (not (null (car x))) ...) insteadof (if (car x) ...).
Others contend that such excess clutter detracts from clarity rather
than improving it."
I agree that it's probably not a too important issue in practice most of
the time, but I also think it tells a great deal about the difference in
goals of Scheme and Common Lisp.
Pascal
[1] see http://www.dreamsongs.com/Essays.html
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
Pascal Costanza <········@web.de> writes:
> I agree that it's probably not a too important issue in practice most
> of the time, but I also think it tells a great deal about the
> difference in goals of Scheme and Common Lisp.
One thing that still floors me because of my lingering C think is
this:
(if 0 'TRUE 'FALSE) => TRUE
I am getting used to it though. I wish I could say the same about the
fact that Java pukes on this:
if (0)
return "True";
else
return "False";
Unless I am misremembering the above.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
David Steuber wrote:
> One thing that still floors me because of my lingering C think is
> this:
>
> (if 0 'TRUE 'FALSE) => TRUE
>
> I am getting used to it though. I wish I could say the same about the
> fact that Java pukes on this:
>
> if (0)
> return "True";
> else
> return "False";
>
> Unless I am misremembering the above.
>
It seems to me that it should be more amazing that IF is an expression
that produces a value rather than a statement as in C:
<contrived>
(defun combine (x y)
(funcall (if (and (numberp x) (numberp y)) #'+ #'append) x y))
</contrived>
David Sletten <·····@slytobias.com> writes:
> David Steuber wrote:
>
>> One thing that still floors me because of my lingering C think is
>> this:
>> (if 0 'TRUE 'FALSE) => TRUE
>> I am getting used to it though. I wish I could say the same about
>> the
>> fact that Java pukes on this:
>> if (0)
>> return "True";
>> else
>> return "False";
>> Unless I am misremembering the above.
>>
> It seems to me that it should be more amazing that IF is an expression
> that produces a value rather than a statement as in C:
> <contrived>
> (defun combine (x y)
> (funcall (if (and (numberp x) (numberp y)) #'+ #'append) x y))
> </contrived>
The polymorphism is harder to obtain, but what about this?
#include "stdio.h"
int add (int x, int y)
{
return x + y;
}
int multiply (int x, int y)
{
return x * y;
}
void foo (int arg, int x, int y)
{
printf ("%d ", (arg == 0 ? add : multiply)(x, y));
}
int main(int argc, char* argv[])
{
foo (0, 2, 3);
foo (1, 2, 3);
return 0;
}
David Sletten <·····@slytobias.com> writes:
> David Steuber wrote:
>
> > One thing that still floors me because of my lingering C think is
> > this:
> > (if 0 'TRUE 'FALSE) => TRUE
> > I am getting used to it though. I wish I could say the same about
> > the
> > fact that Java pukes on this:
> > if (0)
> > return "True";
> > else
> > return "False";
> > Unless I am misremembering the above.
> >
> It seems to me that it should be more amazing that IF is an expression
> that produces a value rather than a statement as in C:
> <contrived>
> (defun combine (x y)
> (funcall (if (and (numberp x) (numberp y)) #'+ #'append) x y))
> </contrived>
You make a good point there. Is it a sign of Lispification that I
have simply gotten so used to if being an expresion (special though it
might be) that I now take it for granted?
Then again, I have annoyed many a C and Perl programmer by using the
following idiom in C, C++, and Perl:
return boolean ? TRUE : FALSE;
I'm not past using the ternary operator!
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
David Steuber wrote:
> Pascal Costanza <········@web.de> writes:
>
>>I agree that it's probably not a too important issue in practice most
>>of the time, but I also think it tells a great deal about the
>>difference in goals of Scheme and Common Lisp.
>
> One thing that still floors me because of my lingering C think is
> this:
>
> (if 0 'TRUE 'FALSE) => TRUE
>
> I am getting used to it though.
It's indeed useful to make 0 stand for falsity in a language whose main
iteration and traversal idioms involve indices into arrays and pointers
(that are also nothing more than indices into one big array called RAM).
It's possible to make zero-length arrays be the base cases most of the time.
Likewise in Lisp: There, the main iteration and traversal idioms involve
lists with heads and tails (first and rest, or car and cdr). The base
cases are typically empty lists.
Pascal
--
ECOOP 2004 Workshops - Oslo, Norway
*1st European Lisp and Scheme Workshop, June 13*
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
*2nd Post-Java Workshop, June 14*
http://prog.vub.ac.be/~wdmeuter/PostJava04/
William Bland <····@abstractnonsense.com> wrote:
+---------------
| Scheme, a dialect of Lisp (if I can say that here without provoking a
| flame fest?), separates nil into two different things:
|
| 1) something that is used to mark the end of a list.
| 2) something that is the "false" value (everything apart from this value
| is considered to be "true"). In Scheme the "false" value is named #f.
|
| Common Lisp doesn't separate these two things, so nil is used for both of
| them.
+---------------
Actually, in CL, NIL is *three* things: EOL, false, and a symbol named "NIL".
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Actually, in CL, NIL is *three* things: EOL, false, and a symbol named "NIL".
It's also a kind of fake cons cell, since you can do CAR and CDR on it.
Paul
"Paul F. Dietz" <·····@dls.net> writes:
> Rob Warnock wrote:
>
>> Actually, in CL, NIL is *three* things: EOL, false, and a symbol
>> named "NIL".
>
> It's also a kind of fake cons cell, since you can do CAR and CDR on it.
And the name of the type that no object is an instance of.
-Peter
P.S. Though I'd say it's a kind of list rather than a fake cons cell.
But that's more philosophy than anything.
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> "Paul F. Dietz" <·····@dls.net> writes:
>> Rob Warnock wrote:
>>> Actually, in CL, NIL is *three* things: EOL, false, and a symbol
>>> named "NIL".
>>
>> It's also a kind of fake cons cell, since you can do CAR and CDR on it.
[...]
> P.S. Though I'd say it's a kind of list rather than a fake cons cell.
> But that's more philosophy than anything.
Not just philosophy: apart from the fact that CDDR, etc., work on NIL,
there is
(listp nil) => t
(consp nil) => nil
Jeremy.
"Peter Seibel" <·····@javamonkey.com> wrote in message
···················@javamonkey.com...
> >> Actually, in CL, NIL is *three* things: EOL, false, and a symbol
> >> named "NIL".
> >
> > It's also a kind of fake cons cell, since you can do CAR and CDR on it.
>
> And the name of the type that no object is an instance of.
Just shooting from the hip here, but isn't the the type NULL not NIL and
isn't NIL the the one and only object of that type?
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
On Sun, 23 May 2004, Coby Beck wrote:
> "Peter Seibel" <·····@javamonkey.com> wrote in message
> ···················@javamonkey.com...
> > >> Actually, in CL, NIL is *three* things: EOL, false, and a symbol
> > >> named "NIL".
> > >
> > > It's also a kind of fake cons cell, since you can do CAR and CDR on it.
> >
> > And the name of the type that no object is an instance of.
>
> Just shooting from the hip here, but isn't the the type NULL not NIL and
> isn't NIL the the one and only object of that type?
NIL is the name of the type for which all objects X, (TYPEP X 'NIL) => NIL
(TYPEP NIL 'NULL) => T, but for no other objects.
"Coby Beck" <·····@mercury.bc.ca> writes:
> "Peter Seibel" <·····@javamonkey.com> wrote in message
> ···················@javamonkey.com...
>> And the name of the type that no object is an instance of.
>
> Just shooting from the hip here, but isn't the the type NULL not NIL and
> isn't NIL the the one and only object of that type?
No.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes wrote:
> "Coby Beck" <·····@mercury.bc.ca> writes:
>
>
>>"Peter Seibel" <·····@javamonkey.com> wrote in message
>>···················@javamonkey.com...
>>
>>>And the name of the type that no object is an instance of.
>>
>>Just shooting from the hip here, but isn't the the type NULL not NIL and
>>isn't NIL the the one and only object of that type?
>
>
> No.
Excellent response, much more concise than when kent pitman helped me
out on the same issue:
"From: Kent M Pitman (······@world.std.com)
Subject: Re: (upgraded-array-element-type nil)
View: Complete Thread (37 articles)
Original Format
Newsgroups: comp.lang.lisp
Date: 2003-02-03 09:29:12 PST
Kenny Tilton <·······@nyc.rr.com> writes:
> Kent M Pitman wrote:
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> >>btw, why /is/ nil a subtype of everything else? is that so nils can be
> >>stored in typed arrays?
> > Your question suggests a misunderstanding, which perhaps leads to
> > your
> > upsetness.
> > The type NIL does not include the object NIL.
>
> I had some trouble here, including starting to think that there was no
> object NIL. (typep nil 'nil) -> nil is a indeed a shocker. Thx for the
> clear-up.
No problem.
Just for reference:
* What you may have been confusing this with is:
(typep nil 'null) => t
* The type NULL is _not_ a subtype of all types.
Sounds like your problem is cleared up, but for the sake of others who
might have needed more explanation on this last point, about the potential
confusions of the NIL and NULL types:
There can be no object such that (typep x 'nil) returns T, which is
why it creates no problem that type NIL is a subtype of all types.
If you think of types as a set, represented as a list, then the type
NULL is (NIL) and the type BOOLEAN is the type (T NIL) and the type
UNSIGNED-BYTE is the type (0 1 2 3 4 ... 255), and so on, then the
type NIL is (). Saying that () is a subtype of all integers is the
same as saying that every list of integers is a null-terminated list,
which makes it properly degenerate. And this makes it clear why some
of us think it should be supported."
:)
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
>>> Just shooting from the hip here, but isn't the the type NULL not NIL and
>>> isn't NIL the the one and only object of that type?
>>
>> No.
>
> Excellent response, much more concise than when kent pitman helped me
> out on the same issue:
Perhaps he assumed that had the original poster actually wanted to know
the details, he would have read the fine documentation in the first
place.
Paul
"Paul F. Dietz" <·····@dls.net> writes:
> Perhaps he assumed that had the original poster actually wanted to know
> the details, he would have read the fine documentation in the first
> place.
Sometimes when I ask a question, all I want is a yes or no answer. A
pointer to the documentation never hurts. But /most/ of the time I've
already been there, or to the wrong spot in the documentation.
Contrary to usenet myth, it is most often fastest to look up the
answer in the fine manual :-)
IRC otoh can be faster still.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
Paul F. Dietz wrote:
> Kenny Tilton wrote:
>
>>>> Just shooting from the hip here, but isn't the the type NULL not NIL
>>>> and
>>>> isn't NIL the the one and only object of that type?
>>>
>>>
>>> No.
>>
>>
>> Excellent response, much more concise than when kent pitman helped me
>> out on the same issue:
>
>
> Perhaps he assumed that had the original poster actually wanted to know
> the details, he would have read the fine documentation in the first
> place.
[Ah, the yobbo[1] tag-team returns to cll!]
You mean that always-lovely-to-hear "read the fucking manual"? Yes,
obviously that was the monosyllabic point of just saying "no". You
missed my fucking point[2]: Kent did not say RTFM, he explained the
difference.
That is the difference between Kent and the Yobbos of Lisp IRC. He is a
gentleman. Well, you guys are also gentlemen, but that is overridden by
some bizarre macho geek ethic in which you brutalize folks for asking
things they could have spent an hour looking up.
cll is different, we're a bunch of newby-huggers (not that "the Cobe" is
a newby), and we understand that no one needs the stress of having to do
an hour of CLHS study before daring to ask a question replete with
footnotes to document that they have done their homework first so they
do not get slapped with the dread "RTFM".
It is easier to turn to a warm, welcoming guru community like cll and
just ask. Besides, I am a lousy reader; when I look things up I still
get it wrong, so why bother? It is easier to waste the time of the gurus
on cll and just ask. The good news being some do not mind.
The ones who do mind could fully optimize their handling of such queries
and not even take the trouble to say, "RTFM". ie, they could just just
STFU[2] and start studying Cells, since it is what they will be using
for the rest of their lives.
Cells Update
------------
I sent the thousand monkeys on a banana boat cruise to nowhere this
weekend and sat down to work out the first ever formal approach to
Cells. Pretty good for an application programmer, right? This will have
no interest to anyone but me, because it does nothing more than make the
hack work right. I mean, cells certainly worked right on cases at hand,
but there were some oddball gaps in the coverage of all possible cases.
Now I think with the formal definition of the specified behavior of
Cells I can re-engineer such that users can just use the thing and Get
What They Expect. I imagine Cells users already expected that, which is
why I say this will be of no interest to anyone but me, but the
internals overhaul is so radical, the folks in marketing want to call it
Cells II!
How exciting is that?! I'll post something if this works out OK in the
end, otherwise I'll be hoping no one notices I did not post anything.
:)
Kenny
1. I owe you guys for all those "Yabos" jerseys. The word is "yobbos",
so that is how I should spell it.
2. Just trying to find the language you Yobbos understand best.
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
> That is the difference between Kent and the Yobbos of Lisp IRC. He is a
> gentleman. Well, you guys are also gentlemen, but that is overridden by
> some bizarre macho geek ethic in which you brutalize folks for asking
> things they could have spent an hour looking up.
It takes about ten seconds to look up the types NIL and NULL in the hyperspec.
This was not a question that required deep ANSI exegesis to resolve.
Paul
"Paul F. Dietz" <·····@dls.net> wrote in message news:<······················@dls.net>...
> It takes about ten seconds to look up the types NIL and NULL in the hyperspec.
> This was not a question that required deep ANSI exegesis to resolve.
I once had a variable x that held either an integer or nil. I wrote
(declare (type (or integer nil) x))
But the compiler kept complaining and complaining. I lost a day of
work before I saw the problem [sniff].
Mark McConnell reminisced
> I once had a variable x that held either an integer or
> nil. I wrote (declare (type (or integer nil) x)) But the
> compiler kept complaining and complaining. I lost a day
> of work before I saw the problem [sniff].
These definitions might make attractive examples for an
introductory text.
(defun length-using-typecase(list)
(typecase list
;; 14.2.1 The types cons and null form an
;; exhaustive partition of the type list.
(null 0)
(cons (+ 1 (length-using-typecase (cdr list))))))
(defun length-using-case(list)
(case list
((nil) 0) ;careful not to specify an empty list of keys
(t (+ 1 (length-using-case (cdr list))))))
(defun length-using-cond(list)
(cond ((null list) 0)
(t (+ 1 (length-using-cond (cdr list))))))
(defun length-using-if(list)
(if list
(+ 1 (length-using-if (cdr list)))
0))
typecase, etypecase, and ctypecase get short shrift in all
the books I've got.
Alan Crowe
Edinburgh
Scotland
In article <····························@posting.google.com>,
···············@yahoo.com (Mark McConnell) wrote:
> "Paul F. Dietz" <·····@dls.net> wrote in message
> news:<······················@dls.net>...
> > It takes about ten seconds to look up the types NIL and NULL in the
> > hyperspec.
> > This was not a question that required deep ANSI exegesis to resolve.
>
> I once had a variable x that held either an integer or nil. I wrote
> (declare (type (or integer nil) x))
> But the compiler kept complaining and complaining. I lost a day of
> work before I saw the problem [sniff].
RTFMFNT
(Read The F*cking Manual Faster Next Time)
;-)
Paul F. Dietz wrote:
> It takes about ten seconds to look up the types NIL and
> NULL in the hyperspec. This was not a question that
> required deep ANSI exegesis to resolve.
It took me 5 minutes 13 seconds. I went for the master
index. I have a command, 'hyperspec', for bringing up the
hyperspec, but I fluffed typing it, so I was already 15
seconds in by the time I was scrolling down the N page.
Since I was racing against the clock I pounced on the entry
for 'nil'
nil
NIL
Glossary Section ``N''
so I circled round the glossary, and by 2 minutes 35 second
I had only got as far as
HyperSpec/Body/t_null.htm
System Class NULL
I followed the up arrow, expecting to get to a system class
dictionary, but it took me to
HyperSpec/Body/c_conses.htm
14.2 The Conses Dictionary
System Class LIST
System Class NULL
System Class CONS
So where is system class nil?
Back to the master index.
system class n. a class that may be of type
built-in-class in a conforming implementation and hence
cannot be inherited by classes defined by conforming
programs.
On to HyperSpec/Body/t_built_.htm#built-in-class
System Class BUILT-IN-CLASS
Again it is a system class, but this time going up the way
leads to
4.4 The Types and Classes Dictionary
Type NIL
Type BOOLEAN
At last. Clicking NIL leads to the page for type nil and the
note that solves the puzzle:
Notes:
The type containing the object nil is the type null,
not the type nil.
Stop the stop watch. Five minutes thirteen seconds.
How could one find it faster? Going back to the Master Index, I
notice that there two very similar entries, for NIL and
nil.
The HTML is
<B>NIL</B>
<A REL=BOOKMARK HREF="../Body/t_nil.htm">Type NIL</A>
<A REL=BOOKMARK HREF="../Body/v_nil.htm">Constant Variable NIL</A>
<B>nil</B>
<A REL=DEFINITION HREF="../Body/26_glo_n.htm#nil">NIL</A>
<A REL=DEFINITION HREF="../Body/26_glo_n.htm#nil">Glossary Section ``N''</A>
Notice that both of the links for 'nil' are to the same
page. I clicked on NIL (the second one, not the first
one). It only lead to glossary entries. So I went back to
try the other entry under nil, and it lead to the same text,
and its links' also only lead to glossary entries. At which
point I realised that it wasn't just the same text, but the
same page. That is confusing and annoying.
I don't understand why the type null is missing from
the types and classes dictionary. One would expect to find
The type nil - no objects are of this type
The type null - one object is of this type: nil
The type boolean - two objects are of this type: t and nil
I've learned some important lessons
1)Escape from glossary hell by clicking on the bold face
links, not the italic links. If there aren't any bold face
links, try the symbol index.
2)
(subtypep 'nil 'list) => T T
The empty set is a subset of the set of lists,
and Lisp is certain about this.
(typep 'nil 'list) => T
nil denotes the empty list and is therefore a list, albeit a
short one.
(subtypep 'null 'list) => T T
Since nil is the only object of type null, Lisp is certain
that every object of type null is a list.
(typep 'null 'list) => NIL
null is a symbol distinct from the only symbol that denotes
a list
(typep ''null 'list) => T
A single tiny typing error can cause total confusion.
3) Usability tests that don't use a stop watch and a naive
user underestimate the time taken to complete a task by a
factor of at least thirty.
Alan Crowe
Edinburgh
Scotland
Alan Crowe <····@cawtech.freeserve.co.uk> writes:
> Stop the stop watch. Five minutes thirteen seconds.
>
> How could one find it faster? Going back to the Master Index, I
> notice that there two very similar entries, for NIL and
> nil.
> The HTML is
>
> <B>NIL</B>
> <A REL=BOOKMARK HREF="../Body/t_nil.htm">Type NIL</A>
> <A REL=BOOKMARK HREF="../Body/v_nil.htm">Constant Variable NIL</A>
> <B>nil</B>
> <A REL=DEFINITION HREF="../Body/26_glo_n.htm#nil">NIL</A>
> <A REL=DEFINITION HREF="../Body/26_glo_n.htm#nil">Glossary Section ``N''</A>
>
> Notice that both of the links for 'nil' are to the same
> page. I clicked on NIL (the second one, not the first
> one). It only lead to glossary entries. So I went back to
> try the other entry under nil, and it lead to the same text,
> and its links' also only lead to glossary entries. At which
> point I realised that it wasn't just the same text, but the
> same page. That is confusing and annoying.
Try ours:
http://www.franz.com/support/documentation/6.2/ansicl/ansicl.htm
It generally takes me three clicks to get from there to any
system type. I find that whenever a name names both a type and
a definition (e.g. cons, list, nil, etc) the definition is at the
end of the index entry and the type is just before it.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> Try ours:
>
> http://www.franz.com/support/documentation/6.2/ansicl/ansicl.htm
>
> It generally takes me three clicks to get from there to any
> system type. I find that whenever a name names both a type and
> a definition (e.g. cons, list, nil, etc) the definition is at the
> end of the index entry and the type is just before it.
>
Took me 58 seconds.
Andr�
--
Duane Rettig wrote
> Try ours:
>
> http://www.franz.com/support/documentation/6.2/ansicl/ansicl.htm
>
Thank you. That is a lot nicer to use.
Which is intriguing because it is essentially the same as
the Xanalys copy I have on my machine. What small
differences in conversion to HTML are making it so much
nicer?
Running two browser windows side by side I notice something
I was never consciously aware off before. My browser clears
the screen before rendering. On the larger pages the title
comes up, then the gif renders
<IMG WIDTH=78 HEIGHT=65 ALT="[XANALYS]"
SRC="../Graphics/XanSmall.gif" ALIGN=Bottom>
and it creates a blink effect that draws by eye to the gif
just as I've started to read the page title. It is the same
gif on every page, so I tune it out, but it seems to be
making the difference between feeling that I'm looking
through the pages of book with the franz version and feeling
that I'm fighting with a computer with the Xanalys version.
Alan Crowe
Edinburgh
Scotland
Alan Crowe wrote:
> Paul F. Dietz wrote:
>
>
>>It takes about ten seconds to look up the types NIL and
>>NULL in the hyperspec. This was not a question that
>>required deep ANSI exegesis to resolve.
>
>
> It took me 5 minutes 13 seconds.
I did in 1:16 because....
I went for the master
> index. I have a command, 'hyperspec', for bringing up the
> hyperspec, but I fluffed typing it, so I was already 15
> seconds in by the time I was scrolling down the N page.
>
> Since I was racing against the clock I pounced on the entry
> for 'nil'
>
....
>
> How could one find it faster? Going back to the Master Index, I
> notice that there two very similar entries, for NIL and
> nil.
I spotted that pretty quickly and the two entries made me suspicious.
Of course I was also using AllegroCL, which Mr. Rettig indicates has a
different index, so our two times are apples and oranges.
> 3) Usability tests that don't use a stop watch and a naive
> user underestimate the time taken to complete a task by a
> factor of at least thirty.
New York City street signs are great if you already know the way. Same
in Edinburgh?
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
> New York City street signs are great if you already know
> the way. Same in Edinburgh?
No. Edinburgh sign posts are sufficiently confusing to throw
you off track even if you know the way. To get back from the
airport to my flat in the centre of Edinburgh I now know to
follow the signs for the zoo. The signs for Edinburgh route
you onto the bypass, and add 8 miles to the journey.
Alan Crowe
Lost in the one way system
but still in Scotland, I hope.
Alan Crowe <····@cawtech.freeserve.co.uk> writes:
> To get back from the airport to my flat in the centre of Edinburgh I
> now know to follow the signs for the zoo.
Does that mean that you're working for Kenny these days? How are the
monkeys doing?
This cyclical referencing within the same thread and the discussion
about driving and directions reminds me of a passage about Svlad
Cjelli...
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Alan Crowe <····@cawtech.freeserve.co.uk> writes:
> How could one find it faster?
By using the symbol index instead.
--
Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
Alan Crowe wrote:
> How could one find it faster?
When I was faced with a similar problem some time ago, I did this:
* (type-of nil)
-> NULL
Well, it worked.
"Svein Ove Aas" <··············@brage.info> wrote in message
·························@news4.e.nsc.no...
> Alan Crowe wrote:
>
> > How could one find it faster?
>
> When I was faced with a similar problem some time ago, I did this:
>
> * (type-of nil)
> -> NULL
>
Not defending my own laziness that started this hyperspec-lookup profiling
but the above is only half the picture (and indeed the less interesting half
(and indeed^2 the part I got right))
Perhaps CL should support
(type-of)
==> NIL
??!
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
Andr� Thieme <······························@justmail.de> writes:
> What is #f ?
Scheme-ish for the false value, which in Scheme is different from the
empty list.
...Peder...
--
This must be Thursday. I never could get the hang of Thursdays.
On Thu, 20 May 2004, [ISO-8859-1] Andr� Thieme wrote:
> Could you please post some code snippets where I can see a usefull use
> of the IDENTITY function?
(defun rev (list &optional (k #'identity))
"Reverse a list using continuation-passing-style"
(cond ((null list)
(funcall k nil))
((consp list)
(rev (rest list)
#'(lambda (res)
(funcall k (append res (list (first list)))))))))
The final continuation of pretty much any CPS algorithm will be IDENTITY
if you want the result returned to the toplevel. Sure, you could use
(lambda (x) x) but why not be a little more clear?
Also, IDENTITY might be used as a default for various library
function parameters, and then it could show up in documentation.
Andr� Thieme <······························@justmail.de> wrote in message news:<············@ulric.tng.de>...
> Could you please post some code snippets where I can see a usefull use
> of the IDENTITY function?
>
>
> Andr�
> --
I often use it for AND'ing list whose length isn't known at compile
time or to avoid AND's shortcuting behaviour:
(every #'identity (list 1 2 (setf *x* 3)))
Or to filter non-nil values (from Paul Graham's On Lisp):
(defun compose (&rest fns)
(if fns
(let ((fn1 (car (last fns)))
(fns (butlast fns)))
#'(lambda (&rest args)
(reduce #'funcall fns
:from-end t
:initial-value (apply fn1 args))))
#'identity))
(defun mklist (obj)
(if (listp obj) obj (list obj)))
(mapcan (compose #'identity #'mklist)
'(1 2 nil 3))
Gabor
Andr� Thieme wrote:
> Could you please post some code snippets where I can see a usefull use
> of the IDENTITY function?
It's a doozy, but it makes heavy use of identity (explanation below):
(defmodel family-values (family)
(
(kv-collector :initarg :kv-collector
:initform #'identity
:reader kv-collector)
(kid-values :initform (c? (when (kv-collector self)
(funcall (kv-collector self) (^md-value))))
:accessor kid-values
:initarg :kid-values)
(kv-key :initform #'identity
:initarg :kv-key
:reader kv-key)
(kv-key-test :initform #'equal
:initarg :kv-key-test
:reader kv-key-test)
(kid-factory :initform #'identity
:initarg :kid-factory
:reader kid-factory)
(.kids :initform (c? (c-assert (listp (kid-values self)))
(let ((new-kids (mapcan (lambda (kid-value)
(list (or (find
kid-value .cache
:key (kv-key self)
:test (kv-key-test self))
(trc nil
"family-values forced to make new kid"
self .cache kid-value)
(funcall (kid-factory
self) self kid-value))))
(^kid-values))))
(nconc (mapcan (lambda (old-kid)
(unless (find old-kid new-kids)
(when (fv-kid-keep self old-kid)
(list old-kid))))
.cache)
new-kids)))
:accessor kids
:initarg :kids)))
The idea is that I am offering optional parameters to the user, much
like the find function with args :key and :test.
I /could/ write code such as:
;; decide if this and that match
(let ((thiskey (if key (funcall key this) this))
(thatkey (if key (funcall key that) that)))
(if test
(funcall test thiskey thatkey)
(equal thiskey thatkey)))
...but if the test arg defaults to equal and key arg defaults to
identity, I just code:
(funcall test (funcall key this)(funcall key that))
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Andr� Thieme wrote:
> Could you please post some code snippets where I can see a usefull use
> of the IDENTITY function?
>
>
> Andr�
> --
Looking through my own code I only found 2 (semi) useful applications.
1. Lisp has a function to test whether an expression is false: NOT.
Unless I'm missing something, the only functions to test whether an
expression is true would be (COMPLEMENT #'NOT) or IDENTITY. Thus, to
test whether all elements of a list are true (since EVERY requires a
function arg):
(every #'identity l)
vs.
(every (complement #'not) l)
or
(notany #'not l)
The last 2 look contrived to me.
2. The mapping functions require a function arg to process the list
arg(s), which of course is what you usually want. However, I found one
example where I simply wanted to use MAPLIST to generate all of the
successive CDR's of a list:
(defun sublists (l)
(maplist #'identity l))
David Sletten
On Thu, 20 May 2004 06:02:42 +0000, David Sletten wrote:
> Andr� Thieme wrote:
>
>> Could you please post some code snippets where I can see a usefull use
>> of the IDENTITY function?
>>
Others have already suggested 'some' and 'every'. I also use:
- To concatenate the sublists of a (short) list:
* (mapcan #'identity '((1 2) (3 4) () (5)))
(1 2 3 4 5)
- To compose functions (this one is from OnLisp):
(defun compose (&rest fns)
(if fns
(let ((fn1 (car (last fns)))
(fns (butlast fns)))
#'(lambda (&rest args)
(reduce #'funcall fns
:from-end t
:initial-value (apply fn1 args))))
#'identity))
Antonio Leitao.
Antonio Menezes Leitao wrote:
>
> Others have already suggested 'some' and 'every'. I also use:
>
> - To concatenate the sublists of a (short) list:
>
> * (mapcan #'identity '((1 2) (3 4) () (5)))
> (1 2 3 4 5)
>
It has nothing to do with identity, but this is not a good way to
concatenate the sublists of a short list, unless you don't mind side
effects like these:
(defvar xx '((1 2) (3 4) () (5)))
=> xx
(mapcan #'identity xx)
=> (1 2 3 4 5)
xx
=> ((1 2 3 4 5) (3 4 5) nil (5))
I assume you usually want (mapcan #'copy-list ...).
--
-- Drew McDermott
Yale Computer Science Department
On Sun, 30 May 2004 12:32:42 -0400, Drew McDermott wrote:
> Antonio Menezes Leitao wrote:
>
>>
>> Others have already suggested 'some' and 'every'. I also use:
>>
>> - To concatenate the sublists of a (short) list:
>>
>> * (mapcan #'identity '((1 2) (3 4) () (5)))
>> (1 2 3 4 5)
>>
> It has nothing to do with identity, but this is not a good way to
> concatenate the sublists of a short list, unless you don't mind side
> effects like these:
>
> (defvar xx '((1 2) (3 4) () (5)))
> => xx
>
> (mapcan #'identity xx)
> => (1 2 3 4 5)
>
> xx
> => ((1 2 3 4 5) (3 4 5) nil (5))
>
> I assume you usually want (mapcan #'copy-list ...).
If I'm not sure about the origins of the sublists, yes.
However, the situation I described occurs only in (one) macroexpansion
where the '(short) list' is freshly consed and not shared. It's just an
alternative to an apply-nconc.
Thanks,
Antonio Leitao.
Andr� Thieme wrote:
> Could you please post some code snippets where I can see a usefull use
> of the IDENTITY function?
>
>
Suppose you have built a fancy data structure which supports
"iteration". E.g.
(defclass dictionary ()
(defclass red-black-tree (dictionary) ...)
Now you want to write a function that iterates over the content of the
data structure. E.g. a SEARCH-IN-DICTIONARY function.
Most likely you will define it as
(defmethod search-in-dictionary ((item t)
(rb red-black-tree)
&key
(test #'eql)
(key #'identity))
...)
I.e. the KEY key parameter is the perfect candidate for a non trivial
use of IDENTITY. This is one of those pieces of brilliance built in the
language.
I remember a passage of CLtL2 where Steele himself says something along
the lines: "... I knew IDENTITY would come useful some day..." (I think
it was while talking about XECTOR pretty printing in *Lisp)
Cheers
--
Marco