From: ··········@rsw.digi.com.br
Subject: Re: I can not find a word better than "CAR"
Date:
Message-ID: <umy8atx60.fsf@rsw.digi.com.br>
···@zedat.fu-berlin.de (Stefan Ram) writes:
> I could use �first component� and �second component�, but this
> is a two-word term (compound term). I do not deem compound
> terms to be appropriate for such fundamental concepts. For the
> same reason, I prefer �pair� to �2-tuple�. A 2-tuple might
> have a �first component� and a �second component�, but a pair
> should have a CAR and a CDR (or some other single-word term).
What about just >>first<< and >>second<<?
Rodrigo
On Jun 14, 9:47 pm, ··········@rsw.digi.com.br wrote:
> ····@zedat.fu-berlin.de (Stefan Ram) writes:
> > I could use »first component« and »second component«, but this
> > is a two-word term (compound term). I do not deem compound
> > terms to be appropriate for such fundamental concepts. For the
> > same reason, I prefer »pair« to »2-tuple«. A 2-tuple might
> > have a »first component« and a »second component«, but a pair
> > should have a CAR and a CDR (or some other single-word term).
>
> What about just >>first<< and >>second<<?
Head & Tail perhaps.
Bobi
http://www.linkedin.com/pub/slobodan-blazeski/6/b9b/151
On Jun 14, 1:34 pm, Slobodan Blazeski <·················@gmail.com>
wrote:
>
> Head & Tail perhaps.
"Head" and "tail" are my favorites too. I like them better than
"first" and "rest" because the latter terms are more abstract and
could apply to sequences implemented in other ways than as lists.
"Head" and "tail", on the other hand, seem to me to refer specifically
to the structure of a list.
Of course I don't mind "car" and "cdr", but this is just from
training :)
-- Scott
Scott Burson wrote:
> On Jun 14, 1:34 pm, Slobodan Blazeski <·················@gmail.com>
> wrote:
>> Head & Tail perhaps.
>
> "Head" and "tail" are my favorites too. I like them better than
> "first" and "rest" because the latter terms are more abstract and
> could apply to sequences implemented in other ways than as lists.
> "Head" and "tail", on the other hand, seem to me to refer specifically
> to the structure of a list.
>
> Of course I don't mind "car" and "cdr", but this is just from
> training :)
Cons cells can be used for things other than lists. For example, trees
and just pairs.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Jun 14, 2:20 pm, Pascal Costanza <····@p-cos.net> wrote:
> Scott Burson wrote:
> > On Jun 14, 1:34 pm, Slobodan Blazeski <·················@gmail.com>
> > wrote:
> >> Head & Tail perhaps.
>
> > "Head" and "tail" are my favorites too. I like them better than
> > "first" and "rest" because the latter terms are more abstract and
> > could apply to sequences implemented in other ways than as lists.
> > "Head" and "tail", on the other hand, seem to me to refer specifically
> > to the structure of a list.
>
> > Of course I don't mind "car" and "cdr", but this is just from
> > training :)
>
> Cons cells can be used for things other than lists. For example, trees
> and just pairs.
True. But CL itself defines `first' and `rest' as synonyms of `car'
and `cdr'. I was just explaining why I like `head' and `tail' better.
Personally, I tend to use `car' and `cdr', and I agree that there are
situations where these semantically unloaded terms are the only ones
that really work. But for those who would like to use more
semantically loaded terms in the extremely common case that the conses
form a list, I recommend `head' and `tail'.
-- Scott
Scott Burson wrote:
> On Jun 14, 2:20 pm, Pascal Costanza <····@p-cos.net> wrote:
>> Scott Burson wrote:
>>> On Jun 14, 1:34 pm, Slobodan Blazeski <·················@gmail.com>
>>> wrote:
>>>> Head & Tail perhaps.
>>> "Head" and "tail" are my favorites too. I like them better than
>>> "first" and "rest" because the latter terms are more abstract and
>>> could apply to sequences implemented in other ways than as lists.
>>> "Head" and "tail", on the other hand, seem to me to refer specifically
>>> to the structure of a list.
>>> Of course I don't mind "car" and "cdr", but this is just from
>>> training :)
>> Cons cells can be used for things other than lists. For example, trees
>> and just pairs.
>
> True. But CL itself defines `first' and `rest' as synonyms of `car'
> and `cdr'. I was just explaining why I like `head' and `tail' better.
>
> Personally, I tend to use `car' and `cdr', and I agree that there are
> situations where these semantically unloaded terms are the only ones
> that really work. But for those who would like to use more
> semantically loaded terms in the extremely common case that the conses
> form a list, I recommend `head' and `tail'.
Ah, ok.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Pascal J. Bourguignon
Subject: Re: I can not find a word better than "CAR"
Date:
Message-ID: <87k53d29k4.fsf@galatea.local>
Scott Burson <········@gmail.com> writes:
> On Jun 14, 2:20�pm, Pascal Costanza <····@p-cos.net> wrote:
>> Scott Burson wrote:
>> > On Jun 14, 1:34 pm, Slobodan Blazeski <·················@gmail.com>
>> > wrote:
>> >> Head & Tail perhaps.
>>
>> > "Head" and "tail" are my favorites too. �I like them better than
>> > "first" and "rest" because the latter terms are more abstract and
>> > could apply to sequences implemented in other ways than as lists.
>> > "Head" and "tail", on the other hand, seem to me to refer specifically
>> > to the structure of a list.
>>
>> > Of course I don't mind "car" and "cdr", but this is just from
>> > training :)
>>
>> Cons cells can be used for things other than lists. For example, trees
>> and just pairs.
>
> True. But CL itself defines `first' and `rest' as synonyms of `car'
> and `cdr'.
It's an error to believe that first and rest are synonymous to car and
cdr. There's a big difference: first and rest apply on lists, while
car and cdr apply on cons cells.
> I was just explaining why I like `head' and `tail' better.
>
> Personally, I tend to use `car' and `cdr', and I agree that there are
> situations where these semantically unloaded terms are the only ones
> that really work.
Yes.
> But for those who would like to use more
> semantically loaded terms in the extremely common case that the conses
> form a list, I recommend `head' and `tail'.
Not in lisp, where the traditionnal way to decompose lists is by first
and rest.
Notice that a tail doesn't start from the head, but from the end of
the body. If you had head, body, tail, then perhaps head and tail
could be used (along with body).
(defun head (x) (first x))
(defun body (x) (rest (butlast x)))
(defun tail (x) (first (last x)))
--
__Pascal Bourguignon__
In article <··············@galatea.local>,
···@informatimago.com (Pascal J. Bourguignon) wrote:
> Scott Burson <········@gmail.com> writes:
>
> > On Jun 14, 2:20�pm, Pascal Costanza <····@p-cos.net> wrote:
> >> Scott Burson wrote:
> >> > On Jun 14, 1:34 pm, Slobodan Blazeski <·················@gmail.com>
> >> > wrote:
> >> >> Head & Tail perhaps.
> >>
> >> > "Head" and "tail" are my favorites too. �I like them better than
> >> > "first" and "rest" because the latter terms are more abstract and
> >> > could apply to sequences implemented in other ways than as lists.
> >> > "Head" and "tail", on the other hand, seem to me to refer specifically
> >> > to the structure of a list.
> >>
> >> > Of course I don't mind "car" and "cdr", but this is just from
> >> > training :)
> >>
> >> Cons cells can be used for things other than lists. For example, trees
> >> and just pairs.
> >
> > True. But CL itself defines `first' and `rest' as synonyms of `car'
> > and `cdr'.
>
> It's an error to believe that first and rest are synonymous to car and
> cdr. There's a big difference: first and rest apply on lists, while
> car and cdr apply on cons cells.
Not so. Cons cells and lists are not distinct in Lisp. The standard
*defines* FIRST to be synonymous with CAR and REST to be synonymous with
CDR. It may be a good idea to keep the two concepts distinct, but
Common Lisp doesn't enforce -- or even support -- any distinction. Some
people consider this a feature.
rg
From: Pascal J. Bourguignon
Subject: Re: I can not find a word better than "CAR"
Date:
Message-ID: <87fxe11k7s.fsf@galatea.local>
Ron Garret <·········@flownet.com> writes:
> In article <··············@galatea.local>,
> ···@informatimago.com (Pascal J. Bourguignon) wrote:
>
>> Scott Burson <········@gmail.com> writes:
>>
>> > On Jun 14, 2:20�pm, Pascal Costanza <····@p-cos.net> wrote:
>> >> Scott Burson wrote:
>> >> > On Jun 14, 1:34 pm, Slobodan Blazeski <·················@gmail.com>
>> >> > wrote:
>> >> >> Head & Tail perhaps.
>> >>
>> >> > "Head" and "tail" are my favorites too. �I like them better than
>> >> > "first" and "rest" because the latter terms are more abstract and
>> >> > could apply to sequences implemented in other ways than as lists.
>> >> > "Head" and "tail", on the other hand, seem to me to refer specifically
>> >> > to the structure of a list.
>> >>
>> >> > Of course I don't mind "car" and "cdr", but this is just from
>> >> > training :)
>> >>
>> >> Cons cells can be used for things other than lists. For example, trees
>> >> and just pairs.
>> >
>> > True. But CL itself defines `first' and `rest' as synonyms of `car'
>> > and `cdr'.
>>
>> It's an error to believe that first and rest are synonymous to car and
>> cdr. There's a big difference: first and rest apply on lists, while
>> car and cdr apply on cons cells.
>
> Not so. Cons cells and lists are not distinct in Lisp. The standard
> *defines* FIRST to be synonymous with CAR and REST to be synonymous with
> CDR. It may be a good idea to keep the two concepts distinct, but
> Common Lisp doesn't enforce -- or even support -- any distinction. Some
> people consider this a feature.
And I have the regret to inform you that you are not distinct from
your mass of lead. Same number of quarks, same forces. The universe
doesn't enforce any distinction here either. And yes, it's a feature
too :-)
--
__Pascal Bourguignon__
In article <··············@galatea.local>,
···@informatimago.com (Pascal J. Bourguignon) wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <··············@galatea.local>,
> > ···@informatimago.com (Pascal J. Bourguignon) wrote:
> >
> >> Scott Burson <········@gmail.com> writes:
> >>
> >> > On Jun 14, 2:20�pm, Pascal Costanza <····@p-cos.net> wrote:
> >> >> Scott Burson wrote:
> >> >> > On Jun 14, 1:34 pm, Slobodan Blazeski <·················@gmail.com>
> >> >> > wrote:
> >> >> >> Head & Tail perhaps.
> >> >>
> >> >> > "Head" and "tail" are my favorites too. �I like them better than
> >> >> > "first" and "rest" because the latter terms are more abstract and
> >> >> > could apply to sequences implemented in other ways than as lists.
> >> >> > "Head" and "tail", on the other hand, seem to me to refer specifically
> >> >> > to the structure of a list.
> >> >>
> >> >> > Of course I don't mind "car" and "cdr", but this is just from
> >> >> > training :)
> >> >>
> >> >> Cons cells can be used for things other than lists. For example, trees
> >> >> and just pairs.
> >> >
> >> > True. But CL itself defines `first' and `rest' as synonyms of `car'
> >> > and `cdr'.
> >>
> >> It's an error to believe that first and rest are synonymous to car and
> >> cdr. There's a big difference: first and rest apply on lists, while
> >> car and cdr apply on cons cells.
> >
> > Not so. Cons cells and lists are not distinct in Lisp. The standard
> > *defines* FIRST to be synonymous with CAR and REST to be synonymous with
> > CDR. It may be a good idea to keep the two concepts distinct, but
> > Common Lisp doesn't enforce -- or even support -- any distinction. Some
> > people consider this a feature.
>
> And I have the regret to inform you that you are not distinct from
> your mass of lead. Same number of quarks, same forces. The universe
> doesn't enforce any distinction here either. And yes, it's a feature
> too :-)
That's a very bad analogy. The universe does enforce many distinctions
between me and a block of lead, or even between a block of lead and a
block of gold, to the dismay of many an alchemist. In fact, it is
precisely those distinctions that make it possible to distinguish
between lead and gold.
The distinction between cons cells and lists in Lisp, by way of
contrast, is purely one of convention. If I give you a block of metal
that is either lead or gold and ask you which it is you'll have no
trouble answering. On the other hand, if I give you a data structure
returned by the CONS function and ask you if it's a list or a cons cell
there's no way for you to tell. There *is* no "right answer".
rg
On 2009-06-15, Stefan Ram <···@zedat.fu-berlin.de> wrote:
> ···@zedat.fu-berlin.de (Stefan Ram) writes:
>>Ron Garret <·········@flownet.com> writes:
>>>if I give you a data structure returned by the CONS function
>>>and ask you if it's a list or a cons cell there's no way for
>>>you to tell
>>If the CDR is an atom other than nil, it's not a list.
>
> OK, I acknowledge that
>
> (listp '(1 . 2)) => T
>
> . I used to believe that �( 1 . 2 )� was not called a �list�.
It's not called a /proper/ list.
(proper-list-p '(1 . 2)) => NIL
In article <···················@gmail.com>,
Kaz Kylheku <········@gmail.com> wrote:
> On 2009-06-15, Stefan Ram <···@zedat.fu-berlin.de> wrote:
> > ···@zedat.fu-berlin.de (Stefan Ram) writes:
> >>Ron Garret <·········@flownet.com> writes:
> >>>if I give you a data structure returned by the CONS function
> >>>and ask you if it's a list or a cons cell there's no way for
> >>>you to tell
> >>If the CDR is an atom other than nil, it's not a list.
> >
> > OK, I acknowledge that
> >
> > (listp '(1 . 2)) => T
> >
> > . I used to believe that �( 1 . 2 )� was not called a �list�.
>
> It's not called a /proper/ list.
>
> (proper-list-p '(1 . 2)) => NIL
It is worth noting that proper-list-p is not part of the standard.
There's a reason for this: in CL it is impossible to produce a correct
implementation of proper-list-p that runs in better than O(n) time.
There is nothing preventing you from producing a dialect of Lisp where
proper lists are a distinct data type from improper lists (i.e. where
the CDR is constrained to contain only objects of type proper-list or
NIL). This was explicitly not done in CL, and this decision is firmly
rooted in Lisp tradition where lists and cons cells are conflated by
design. Reasonable people can disagree over whether or not this is a
good idea. But it is absolutely false that "It's an error to believe
that first and rest are synonymous to car and cdr." Not only are they
synonymous, but they are synonymous *by design*.
rg
* Ron Garret <·······························@news.albasani.net> :
Wrote on Mon, 15 Jun 2009 13:36:29 -0700:
| It is worth noting that proper-list-p is not part of the standard.
The Common Lisp standard defines the definitional terms
proper list n. A list terminated by the empty list. (The empty list is a
proper list.) See improper list.
improper list n. a list which is not a proper list: a circular list or a
dotted list.
| There's a reason for this: in CL it is impossible to produce a correct
| implementation of proper-list-p that runs in better than O(n) time.
It is true that the implementation of proper-list-p that runs in better
than O(n) time is not possible in CL --- because CL implements lists on
top of cons cells and you need O(n) operations to get to the last cons
cell.
But that cannot be *THE REASON* why it is not in the standard. A reason
why it is not in the standard may simply be it is a definitional term,
and is not useful in practice. If you think its useful you are "doing
something wrong."
| There is nothing preventing you from producing a dialect of Lisp where
| proper lists are a distinct data type from improper lists (i.e. where
| the CDR is constrained to contain only objects of type proper-list or
| NIL).
From what you said above, an O(n) cost of TYPEP operation would likely
prevent *someone* from producing such a dialect. So, either
1. LISTS in this dialect wouldn't have O(n) access characterestics, in
which case you cannot use cons cells as use cons cells do have O(n)
access characterstics
2. your dialect has other ways (like static typing, or constraining the
type of objects in the list to a specific type) to ensure type
integrity of the proper lists.
| This was explicitly not done in CL, and this decision is firmly rooted
| in Lisp tradition where lists and cons cells are conflated by design.
It is true that CL defines list operations in terms of CONS cells.
| Reasonable people can disagree over whether or not this is a good
| idea.
I'd think they would also disagree over the assumptions (such as lists
need not have O(n) characterestics, or other typing requirements)
| But it is absolutely false that "It's an error to believe that first
| and rest are synonymous to car and cdr." Not only are they
| synonymous, but they are synonymous *by design*.
you keep harping on *by design* even when it is a matter of *by
definition*.
Personally for me, the bottom line is this: In CL, FIRST, REST, SECOND
produce counter-intuitive results on dotted or circular lists, (in terms
of the type of the values they return vs the name of the operation. You
normally expect to use them only on proper lists)
OTOH I never go wrong with list functions like ENDP and LAST, defined in
terms of cons cells, which conform to expectations from their name and
the type of values they accept and return as defined in the standard.
--
Madhu
In article <··············@moon.robolove.meer.net>,
Madhu <·······@meer.net> wrote:
> * Ron Garret <·······························@news.albasani.net> :
> Wrote on Mon, 15 Jun 2009 13:36:29 -0700:
>
> | It is worth noting that proper-list-p is not part of the standard.
>
> The Common Lisp standard defines the definitional terms
>
> proper list n. A list terminated by the empty list. (The empty list is a
> proper list.) See improper list.
>
> improper list n. a list which is not a proper list: a circular list or a
> dotted list.
That's true. And your point would be...?
> | There's a reason for this: in CL it is impossible to produce a correct
> | implementation of proper-list-p that runs in better than O(n) time.
>
> It is true that the implementation of proper-list-p that runs in better
> than O(n) time is not possible in CL --- because CL implements lists on
> top of cons cells and you need O(n) operations to get to the last cons
> cell.
>
> But that cannot be *THE REASON* why it is not in the standard.
I didn't say it was *the* reason, I said it was *a* reason. But since
you brought it up, why couldn't it be *the* reason?
> A reason
> why it is not in the standard may simply be it is a definitional term,
> and is not useful in practice. If you think its useful you are "doing
> something wrong."
Knowing if a datum is a proper list can be very useful. For example,
calling mapcar on an improper list will result in an error, so you might
want to test for proper-listness ahead of time to avoid that.
> | There is nothing preventing you from producing a dialect of Lisp where
> | proper lists are a distinct data type from improper lists (i.e. where
> | the CDR is constrained to contain only objects of type proper-list or
> | NIL).
>
> From what you said above, an O(n) cost of TYPEP operation would likely
> prevent *someone* from producing such a dialect. So, either
>
> 1. LISTS in this dialect wouldn't have O(n) access characterestics, in
> which case you cannot use cons cells as use cons cells do have O(n)
> access characterstics
>
> 2. your dialect has other ways (like static typing, or constraining the
> type of objects in the list to a specific type) to ensure type
> integrity of the proper lists.
I was thinking of option 2, and I thought I made that clear in a passage
that you deleted:
> (i.e. where the CDR is constrained to contain only objects of
> type proper-list or NIL).
> | This was explicitly not done in CL, and this decision is firmly rooted
> | in Lisp tradition where lists and cons cells are conflated by design.
>
> It is true that CL defines list operations in terms of CONS cells.
Yes, but that is misleading. In Lisp, lists *are* cons cells. They are
one and the same thing, *by design* absolutely indistinguishable from
one another. Being identical to something is a much stronger property
than merely being defined in terms of something.
> | Reasonable people can disagree over whether or not this is a good
> | idea.
>
> I'd think they would also disagree over the assumptions (such as lists
> need not have O(n) characterestics, or other typing requirements)
Those aren't assumptions, those are facts. Alternative language design
and implementation options do exist.
> | But it is absolutely false that "It's an error to believe that first
> | and rest are synonymous to car and cdr." Not only are they
> | synonymous, but they are synonymous *by design*.
>
> you keep harping on *by design* even when it is a matter of *by
> definition*.
Well, yeah, but those definitions are part of the design, no?
> Personally for me, the bottom line is this: In CL, FIRST, REST, SECOND
> produce counter-intuitive results on dotted or circular lists, (in terms
> of the type of the values they return vs the name of the operation. You
> normally expect to use them only on proper lists)
>
> OTOH I never go wrong with list functions like ENDP and LAST, defined in
> terms of cons cells, which conform to expectations from their name and
> the type of values they accept and return as defined in the standard.
Personally, I would intuitively expect a function named LAST whose
argument is specified to be a LIST to return the last element of the
list. But what do I know?
rg
From: Pascal J. Bourguignon
Subject: Re: I can not find a word better than "CAR"
Date:
Message-ID: <87prd4tz6b.fsf@galatea.local>
Ron Garret <·········@flownet.com> writes:
> Personally, I would intuitively expect a function named LAST whose
> argument is specified to be a LIST to return the last element of the
> list. But what do I know?
Its real name is LASTCDR, but they were cheap on key punches when the
invented the name, so it was just LAST.
--
__Pascal Bourguignon__
On Jun 16, 12:28 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Ron Garret <·········@flownet.com> writes:
> > Personally, I would intuitively expect a function named LAST whose
> > argument is specified to be a LIST to return the last element of the
> > list. But what do I know?
>
> Its real name is LASTCDR, but they were cheap on key punches when the
> invented the name, so it was just LAST.
I think LASTCONS is better -- the last cdr is obviously NIL :)
For FSet I wanted LAST to be symmetrical with FIRST, so I shadow LAST
and export its functionality under the name LASTCONS.
-- Scott
* Scott Burson Wrote on Tue, 16 Jun 2009 10:42:48 -0700 (PDT):
| For FSet I wanted LAST to be symmetrical with FIRST, so I shadow LAST
| and export its functionality under the name LASTCONS.
Luckily, if you wanted to use have a mutable data structure built with
cons cells, you'd not use FSet in the first place, and CL:LAST would
still behave as the Spec defines it.
--
Madhu
On Jun 16, 9:34 pm, Madhu <·······@meer.net> wrote:
> * Scott Burson Wrote on Tue, 16 Jun 2009 10:42:48 -0700 (PDT):
>
> | For FSet I wanted LAST to be symmetrical with FIRST, so I shadow LAST
> | and export its functionality under the name LASTCONS.
>
> Luckily, if you wanted to use have a mutable data structure built with
> cons cells, you'd not use FSet in the first place, and CL:LAST would
> still behave as the Spec defines it.
Even if you are using FSet, you have the choice of whether to
shadowing-import FSET:LAST, or not.
-- Scott
* Ron Garret <·······························@news.albasani.net> :
Wrote on Mon, 15 Jun 2009 23:35:33 -0700:
| In article <··············@moon.robolove.meer.net>,
| Madhu <·······@meer.net> wrote:
|> | It is worth noting that proper-list-p is not part of the standard.
|>
|> The Common Lisp standard defines the definitional terms
[...]
| That's true. And your point would be...?
that `it' followed from these defintions of proper-list and
improper-list --- both what a proper-list-p involved and to also why it
would not be useful.
|> | There's a reason for this: in CL it is impossible to produce a
|> | correct implementation of proper-list-p that runs in better than
|> | O(n) time.
|>
|> It is true that the implementation of proper-list-p that runs in
|> better than O(n) time is not possible in CL --- because CL implements
|> lists on top of cons cells and you need O(n) operations to get to the
|> last cons cell.
|>
|> But that cannot be *THE REASON* why it is not in the standard.
|
| I didn't say it was *the* reason, I said it was *a* reason. But since
| you brought it up, why couldn't it be *the* reason?
Stated next:
|> A reason why it is not in the standard may simply be it is a
|> definitional term, and is not useful in practice. If you think its
|> useful you are "doing something wrong."
|
| Knowing if a datum is a proper list can be very useful. For example,
| calling mapcar on an improper list will result in an error, so you
| might want to test for proper-listness ahead of time to avoid that.
That is why I suggested you might be doing something wrong if you
thought you needed proper-list-p.
If you detect an improper list where a proper list is required, you
could at best signal the error when your code called PROPER-LIST-P and
determined it was not a proper list. Which is precisely what MAPCAR
would do -- throw an error.
I can anticipate type-based counter arguments but I'd just think they
were arguments for a sloppier structuring of your code. As this would
be a "philosophical" point of difference, I will not argue my case any
further though I think my claim stands
[...]
|> 2. your dialect has other ways (like static typing, or constraining the
|> type of objects in the list to a specific type) to ensure type
|> integrity of the proper lists.
|
| I was thinking of option 2, and I thought I made that clear in a passage
| that you deleted:
OK. I deleted that inadvertently.
--
Madhu
Madhu <·······@meer.net> writes:
> * Ron Garret <·······························@news.albasani.net> :
> Wrote on Mon, 15 Jun 2009 13:36:29 -0700:
>
> | It is worth noting that proper-list-p is not part of the standard.
...
> | There's a reason for this: in CL it is impossible to produce a correct
> | implementation of proper-list-p that runs in better than O(n) time.
>
> It is true that the implementation of proper-list-p that runs in better
> than O(n) time is not possible in CL --- because CL implements lists on
> top of cons cells and you need O(n) operations to get to the last cons
> cell.
>
> But that cannot be *THE REASON* why it is not in the standard.
Certainly. After all, LENGTH is in the standard and it requires O(n)
operations. Not to mention REMOVE-DUPLICATES, which is typically O(n^2)
in most implementations.
In article <···············@blackcat.isi.edu>,
···@sevak.isi.edu (Thomas A. Russ) wrote:
> Madhu <·······@meer.net> writes:
>
> > * Ron Garret <·······························@news.albasani.net> :
> > Wrote on Mon, 15 Jun 2009 13:36:29 -0700:
> >
> > | It is worth noting that proper-list-p is not part of the standard.
> ...
> > | There's a reason for this: in CL it is impossible to produce a correct
> > | implementation of proper-list-p that runs in better than O(n) time.
> >
> > It is true that the implementation of proper-list-p that runs in better
> > than O(n) time is not possible in CL --- because CL implements lists on
> > top of cons cells and you need O(n) operations to get to the last cons
> > cell.
> >
> > But that cannot be *THE REASON* why it is not in the standard.
>
> Certainly. After all, LENGTH is in the standard and it requires O(n)
> operations. Not to mention REMOVE-DUPLICATES, which is typically O(n^2)
> in most implementations.
Yes, the inclusion of those functions is clearly a bug in the spec ;-)
rg
On Jun 16, 11:08 am, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Not to mention REMOVE-DUPLICATES, which is typically O(n^2)
> in most implementations.
really? I could see that worst case, but it would depend on the
test. If the test is eq I would expect an O(n) solution.
I guess it would devolve to O(n^2) if you had something that really
didn't hash / a lot of collisions (for a hash table implementation),
or really unbalanced data (if you are using a tree instead of a hash
to remember what has already been seen). Memory cost would be
something to hash it, so maybe that isn't allowed? or tunable
depending on if you optimize for speed or space. I don't know what
implementations actually do though.
Kevin
K Livingston <······················@gmail.com> writes:
> On Jun 16, 11:08��am, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> > Not to mention REMOVE-DUPLICATES, which is typically O(n^2)
> > in most implementations.
>
> really? I could see that worst case, but it would depend on the
> test. If the test is eq I would expect an O(n) solution.
>
> I guess it would devolve to O(n^2) if you had something that really
> didn't hash / a lot of collisions (for a hash table implementation),
> or really unbalanced data (if you are using a tree instead of a hash
> to remember what has already been seen). Memory cost would be
> something to hash it, so maybe that isn't allowed? or tunable
> depending on if you optimize for speed or space. I don't know what
> implementations actually do though.
Well, with the caveat that it's been a long while since we actually did
any performance testing of this, but at one time it seems that
remove-duplicates was done using the straightforward O(n^2) algorithm.
There was no use of auxiliary data structures such as hash tables or
other clever means of detecting duplicates.
So for our software we implemented our own FAST-REMOVE-DUPLICATES
function that did use an O(n) algorithm.
In defense of the implementations, it seems like the fallback solution
has to be available to use since, unlike hash tables, REMOVE-DUPLICATES
has to accept an arbitrary test. So a hash table solution doesn't
necessarily work, except for certain specific tests. So it really comes
down to whether an implementation uses a special case for the (probably
relatively common) cases of EQ, EQL or EQUAL tests.
In any case, while reading the HyperSpec, I also noticed the following
interesting constraint. I found it interesting because it is exactly
the opposite of what I would have expected:
"The elements of sequence are compared pairwise, and if any two match,
then the one occurring earlier in sequence is discarded, unless
from-end is true, in which case the one later in sequence is
discarded."
That requirement would also seem to put some constraints on the
algorithm that can be used to implement REMOVE-DUPLICATES, since the
naive hash-table implementation [where you iterate through the sequence
and only keep the elements that haven't been see before] would have the
opposite behavior.
--
Thomas A. Russ, USC/Information Sciences Institute
On 18 jun, 15:33, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> [...]
> In any case, while reading the HyperSpec, I also noticed the following
> interesting constraint. I found it interesting because it is exactly
> the opposite of what I would have expected:
>
> "The elements of sequence are compared pairwise, and if any two match,
> then the one occurring earlier in sequence is discarded, unless
> from-end is true, in which case the one later in sequence is
> discarded."
>
> That requirement would also seem to put some constraints on the
> algorithm that can be used to implement REMOVE-DUPLICATES, since the
> naive hash-table implementation [where you iterate through the sequence
> and only keep the elements that haven't been see before] would have the
> opposite behavior.
Since there is nothing saying that the list needs to be constructed
from the beginning or from the end, this is a valid (sort of) straight-
forward solution (with :test #'eql :from-end nil)
(defun rem-dups (list &optional (hash-table (make-hash-table :size
(length list))))
(when list
(let ((tail (rem-dups (cdr list) hash-table)))
(if (gethash (car list) hash-table)
tail
(cons (setf (gethash (car list) hash-table) (car list))
tail)))))
The only problem is that it is not tail recursive, and I don't see a
way to make it tail recursive without creating an explicit stack.
On Jun 18, 3:39 pm, gugamilare <··········@gmail.com> wrote:
[...]
> Since there is nothing saying that the list needs to be constructed
> from the beginning or from the end, this is a valid (sort of) straight-
> forward solution (with :test #'eql :from-end nil)
> (defun rem-dups (list &optional (hash-table (make-hash-table :size
> (length list))))
> (when list
> (let ((tail (rem-dups (cdr list) hash-table)))
> (if (gethash (car list) hash-table)
> tail
> (cons (setf (gethash (car list) hash-table) (car list))
> tail)))))
> The only problem is that it is not tail recursive, and I don't see a
> way to make it tail recursive without creating an explicit stack.
Just reverse the list to start with, so the first element you see is
the last one in the list; that way you don't need to mess with tail
pointers (though it's maybe worth recycling your conses).
(defun rem-dups (list)
(let ((table (make-hash-table :size (length list))))
(labels
((helper (rev acc)
(if (null rev)
acc
(let ((elt (first rev)) (rest (rest rev)))
(cond
((gethash elt table) (helper rest acc))
(t
(setf (gethash elt table) t
;; Smash the CDR, because this will
;; be a fresh
cons.
(cdr rev) acc)
(helper rest rev)))))))
(helper (reverse list) '()))))
Cheers,
Pillsy
On Jun 18, 1:33 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> In any case, while reading the HyperSpec, I also noticed the following
> interesting constraint. I found it interesting because it is exactly
> the opposite of what I would have expected:
>
> "The elements of sequence are compared pairwise, and if any two match,
> then the one occurring earlier in sequence is discarded, unless
> from-end is true, in which case the one later in sequence is
> discarded."
>
> That requirement would also seem to put some constraints on the
> algorithm that can be used to implement REMOVE-DUPLICATES, since the
> naive hash-table implementation [where you iterate through the sequence
> and only keep the elements that haven't been see before] would have the
> opposite behavior.
Huh, that is the exact opposite of what I intuitively expected too.
(This probably explains some ordering changes in the output of a few
of my pieces of code, that I didn't expect. But it wasn't a problem/
wrong, and i never tracked it down.) Other things I easily think of
default to the first one found. For example plists, and destructuring-
bind on a keyword list that has multiple keys of the same value.
I looked it up in CLtL2, and after it says what you quoted, it says
the output is allowed to share a tail with the original. So it's
optimized for getting the biggest tail possible by removing from the
front. Saves consing and space.
I wonder if I have assumptions in my code that think remove-duplicates
provides a clean list. Got burned by that real bad with sublis once,
so I'm aware of that type of problem, thought I wouldn't make it any
more. I wonder if there is a list somewhere of functions allowed to
share structure? Probably safe to assume all of them I guess.
Kevin
K Livingston <······················@gmail.com> writes:
> On Jun 18, 1:33��pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> > �� "The elements of sequence are compared pairwise, and if any two match,
> > �� then the one occurring earlier in sequence is discarded, unless
> > �� from-end is true, in which case the one later in sequence is
> > �� discarded."
...
> I looked it up in CLtL2, and after it says what you quoted, it says
> the output is allowed to share a tail with the original. So it's
> optimized for getting the biggest tail possible by removing from the
> front. Saves consing and space.
That sounds like the most likely explanation.
I was thinking that it might also have something to do with the idea
that you are REMOVEing elements from the list, and you remove them in
the order encountered. So that would also mean one might remove from
the front. I suppose the other way would have to be called something
like KEEP-UNIQUE. It could have the following trivial definition:
(defun keep-unique (sequence &key :from-end &rest keys)
(apply #'remove-duplicates sequence :from-end (not from-end) keys))
--
Thomas A. Russ, USC/Information Sciences Institute
On Jun 15, 1:36 pm, Ron Garret <·········@flownet.com> wrote:
> There is nothing preventing you from producing a dialect of Lisp where
> proper lists are a distinct data type from improper lists (i.e. where
> the CDR is constrained to contain only objects of type proper-list or
> NIL).
In order to prevent circularities you'd also have to outlaw RPLACD and
(SETF CDR) on proper lists, or do unpalatable O(n) circularity
testing.
(Not to disagree with your larger point.)
-- Scott
From: Pascal J. Bourguignon
Subject: Re: I can not find a word better than "CAR"
Date:
Message-ID: <873aa11c35.fsf@galatea.local>
Ron Garret <·········@flownet.com> writes:
> In article <··············@galatea.local>,
> ···@informatimago.com (Pascal J. Bourguignon) wrote:
>
>> Ron Garret <·········@flownet.com> writes:
>>
>> > In article <··············@galatea.local>,
>> > ···@informatimago.com (Pascal J. Bourguignon) wrote:
>> >
>> >> Scott Burson <········@gmail.com> writes:
>> >>
>> >> > On Jun 14, 2:20�pm, Pascal Costanza <····@p-cos.net> wrote:
>> >> >> Scott Burson wrote:
>> >> >> > On Jun 14, 1:34 pm, Slobodan Blazeski <·················@gmail.com>
>> >> >> > wrote:
>> >> >> >> Head & Tail perhaps.
>> >> >>
>> >> >> > "Head" and "tail" are my favorites too. �I like them better than
>> >> >> > "first" and "rest" because the latter terms are more abstract and
>> >> >> > could apply to sequences implemented in other ways than as lists.
>> >> >> > "Head" and "tail", on the other hand, seem to me to refer specifically
>> >> >> > to the structure of a list.
>> >> >>
>> >> >> > Of course I don't mind "car" and "cdr", but this is just from
>> >> >> > training :)
>> >> >>
>> >> >> Cons cells can be used for things other than lists. For example, trees
>> >> >> and just pairs.
>> >> >
>> >> > True. But CL itself defines `first' and `rest' as synonyms of `car'
>> >> > and `cdr'.
>> >>
>> >> It's an error to believe that first and rest are synonymous to car and
>> >> cdr. There's a big difference: first and rest apply on lists, while
>> >> car and cdr apply on cons cells.
>> >
>> > Not so. Cons cells and lists are not distinct in Lisp. The standard
>> > *defines* FIRST to be synonymous with CAR and REST to be synonymous with
>> > CDR. It may be a good idea to keep the two concepts distinct, but
>> > Common Lisp doesn't enforce -- or even support -- any distinction. Some
>> > people consider this a feature.
>>
>> And I have the regret to inform you that you are not distinct from
>> your mass of lead. Same number of quarks, same forces. The universe
>> doesn't enforce any distinction here either. And yes, it's a feature
>> too :-)
>
> That's a very bad analogy. The universe does enforce many distinctions
> between me and a block of lead, or even between a block of lead and a
> block of gold, to the dismay of many an alchemist. In fact, it is
> precisely those distinctions that make it possible to distinguish
> between lead and gold.
You're speaking at the level of nucleons.
I was speaking at the level of quarks.
So you brillantly made my point. Thank you.
> The distinction between cons cells and lists in Lisp, by way of
> contrast, is purely one of convention. If I give you a block of metal
> that is either lead or gold and ask you which it is you'll have no
> trouble answering. On the other hand, if I give you a data structure
> returned by the CONS function and ask you if it's a list or a cons cell
> there's no way for you to tell. There *is* no "right answer".
>
> rg
--
__Pascal Bourguignon__
In article <··············@galatea.local>,
···@informatimago.com (Pascal J. Bourguignon) wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <··············@galatea.local>,
> > ···@informatimago.com (Pascal J. Bourguignon) wrote:
> >
> >> Ron Garret <·········@flownet.com> writes:
> >>
> >> > In article <··············@galatea.local>,
> >> > ···@informatimago.com (Pascal J. Bourguignon) wrote:
> >> >
> >> >> Scott Burson <········@gmail.com> writes:
> >> >>
> >> >> > On Jun 14, 2:20�pm, Pascal Costanza <····@p-cos.net> wrote:
> >> >> >> Scott Burson wrote:
> >> >> >> > On Jun 14, 1:34 pm, Slobodan Blazeski
> >> >> >> > <·················@gmail.com>
> >> >> >> > wrote:
> >> >> >> >> Head & Tail perhaps.
> >> >> >>
> >> >> >> > "Head" and "tail" are my favorites too. �I like them better than
> >> >> >> > "first" and "rest" because the latter terms are more abstract and
> >> >> >> > could apply to sequences implemented in other ways than as lists.
> >> >> >> > "Head" and "tail", on the other hand, seem to me to refer
> >> >> >> > specifically
> >> >> >> > to the structure of a list.
> >> >> >>
> >> >> >> > Of course I don't mind "car" and "cdr", but this is just from
> >> >> >> > training :)
> >> >> >>
> >> >> >> Cons cells can be used for things other than lists. For example,
> >> >> >> trees
> >> >> >> and just pairs.
> >> >> >
> >> >> > True. But CL itself defines `first' and `rest' as synonyms of `car'
> >> >> > and `cdr'.
> >> >>
> >> >> It's an error to believe that first and rest are synonymous to car and
> >> >> cdr. There's a big difference: first and rest apply on lists, while
> >> >> car and cdr apply on cons cells.
> >> >
> >> > Not so. Cons cells and lists are not distinct in Lisp. The standard
> >> > *defines* FIRST to be synonymous with CAR and REST to be synonymous with
> >> > CDR. It may be a good idea to keep the two concepts distinct, but
> >> > Common Lisp doesn't enforce -- or even support -- any distinction. Some
> >> > people consider this a feature.
> >>
> >> And I have the regret to inform you that you are not distinct from
> >> your mass of lead. Same number of quarks, same forces. The universe
> >> doesn't enforce any distinction here either. And yes, it's a feature
> >> too :-)
> >
> > That's a very bad analogy. The universe does enforce many distinctions
> > between me and a block of lead, or even between a block of lead and a
> > block of gold, to the dismay of many an alchemist. In fact, it is
> > precisely those distinctions that make it possible to distinguish
> > between lead and gold.
>
> You're speaking at the level of nucleons.
> I was speaking at the level of quarks.
>
See http://groups.google.com/group/comp.lang.lisp/msg/b7a9c1ca5bb1ceb1,
particularly the last two paragraphs.
rg
On 15 June, 18:27, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Ron Garret <·········@flownet.com> writes:
> > In article <··············@galatea.local>,
> > ····@informatimago.com (Pascal J. Bourguignon) wrote:
>
> >> Scott Burson <········@gmail.com> writes:
>
> >> > On Jun 14, 2:20 pm, Pascal Costanza <····@p-cos.net> wrote:
> >> >> Scott Burson wrote:
> >> >> > On Jun 14, 1:34 pm, Slobodan Blazeski <·················@gmail.com>
> >> >> > wrote:
> >> >> >> Head & Tail perhaps.
>
> >> >> > "Head" and "tail" are my favorites too. I like them better than
> >> >> > "first" and "rest" because the latter terms are more abstract and
> >> >> > could apply to sequences implemented in other ways than as lists.
> >> >> > "Head" and "tail", on the other hand, seem to me to refer specifically
> >> >> > to the structure of a list.
>
> >> >> > Of course I don't mind "car" and "cdr", but this is just from
> >> >> > training :)
>
> >> >> Cons cells can be used for things other than lists. For example, trees
> >> >> and just pairs.
>
> >> > True. But CL itself defines `first' and `rest' as synonyms of `car'
> >> > and `cdr'.
>
> >> It's an error to believe that first and rest are synonymous to car and
> >> cdr. There's a big difference: first and rest apply on lists, while
> >> car and cdr apply on cons cells.
>
> > Not so. Cons cells and lists are not distinct in Lisp. The standard
> > *defines* FIRST to be synonymous with CAR and REST to be synonymous with
> > CDR. It may be a good idea to keep the two concepts distinct, but
> > Common Lisp doesn't enforce -- or even support -- any distinction. Some
> > people consider this a feature.
>
> And I have the regret to inform you that you are not distinct from
> your mass of lead. Same number of quarks, same forces. The universe
> doesn't enforce any distinction here either.
wouldn't there be more quarks in the lead because lead has a bigger
mass anomally than the typical atoms making up a person?
> And yes, it's a feature too :-)
Nick Keighley <····················@hotmail.com> writes:
>> And I have the regret to inform you that you are not distinct from
>> your mass of lead. �Same number of quarks, same forces. �The universe
>> doesn't enforce any distinction here either.
>
> wouldn't there be more quarks in the lead because lead has a bigger
> mass anomally than the typical atoms making up a person?
Well, I didn't want to enter into details. You can take instead all
the atoms of the person, and put them in a jar in order of atomic
mass, and allow for the difference of mass due to the difference in
bounding, thermic, and kinetic energy.
--
__Pascal Bourguignon__
···@informatimago.com (Pascal J. Bourguignon) writes:
> Notice that a tail doesn't start from the head, but from the end of
> the body. If you had head, body, tail, then perhaps head and tail
> could be used (along with body).
Oh, no! Not CXRs!
--
Thomas A. Russ, USC/Information Sciences Institute
Let's see how many understand the reference.
I know some of the regulars will.
From: Mark Cox
Subject: Re: I can not find a word better than "CAR"
Date:
Message-ID: <m27hzeebik.fsf@gmail.com>
Scott Burson <········@gmail.com> writes:
> On Jun 14, 1:34�pm, Slobodan Blazeski <·················@gmail.com>
> wrote:
>>
>> Head & Tail perhaps.
>
> "Head" and "tail" are my favorites too. I like them better than
> "first" and "rest" because the latter terms are more abstract and
> could apply to sequences implemented in other ways than as lists.
> "Head" and "tail", on the other hand, seem to me to refer specifically
> to the structure of a list.
>
I'm not 100% sure on this, but I'd say that the shortcuts of the
composed forms were of importance as well (if not greater importance
given the number of shortcuts defined in the standard). For example:
(car (cdr x))
can be rewritten as a single function
(cadr x).
I know the shortcuts are somewhat frowned upon now, but perhaps there is
time in lisp's history when the shortcuts may have been common practice.
Take all this with a grain of salt. Part of me has always wondered why
they were even specified in the standard way down to CDDDDR. Can someone
enlighten me?
I wish I had the neurons and synapses that allowed me to navigate my
data structures using CADAAR and CADADR! Maybe the coffee was much
better in the past.
Mark
Mark Cox <·········@gmail.com> wrote:
+---------------
| I wish I had the neurons and synapses that allowed me
| to navigate my data structures using CADAAR and CADADR!
+---------------
The one place I find myself frequently using CDD*R
is in destructuring lists by "gulps" in LOOP, e.g.:
> (defun group-by-triples (list)
(loop for (a b c) on list by #'cdddr
collect (list a b c)))
GROUP-BY-TRIPLES
> (group-by-triples '(0 1 2 3 4 5 6 7 8 9 10 11 12))
((0 1 2) (3 4 5) (6 7 8) (9 10 11) (12 NIL NIL))
>
Note: Whether sublist (12 NIL NIL) is the "correct" result or a "bug"
depends upon your application. Adjusting the function so that the last
sublist is (12) is left as an exercise for the reader. ;-} ;-}
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
[At last, a *real* toy example to nitpick :)]
* (Rob Warnock) <································@speakeasy.net> :
Wrote on Sun, 14 Jun 2009 23:23:38 -0500:
|
| The one place I find myself frequently using CDD*R is in destructuring
| lists by "gulps" in LOOP, e.g.:
|
| > (defun group-by-triples (list)
| (loop for (a b c) on list by #'cdddr
| collect (list a b c)))
|
| GROUP-BY-TRIPLES
| > (group-by-triples '(0 1 2 3 4 5 6 7 8 9 10 11 12))
|
| ((0 1 2) (3 4 5) (6 7 8) (9 10 11) (12 NIL NIL))
| >
|
| Note: Whether sublist (12 NIL NIL) is the "correct" result or a "bug"
| depends upon your application. Adjusting the function so that the last
| sublist is (12) is left as an exercise for the reader. ;-} ;-}
You clearly don't want (12) in the output list because then you have a
situation where the accursed recursive solution is preferable over using
our glorious LOOP:
(defun group-by-triples (list &optional ret)
(if (some (lambda (x) (endp (funcall x list))) '(cdddr cddr cdr))
(nreconc ret (list list))
(group-by-triples (cdddr list) (cons (ldiff list (cdddr list)) ret))))
And of course, if you are the inveterate CADDARing aesthete, the
(ldiff list (cdddr list))
would be written as
(cons (car list) (cons (cadr list) (cons (caddr list) nil)))
--
Madhu
From: Pascal J. Bourguignon
Subject: Re: I can not find a word better than "CAR"
Date:
Message-ID: <87ski21p45.fsf@galatea.local>
Slobodan Blazeski <·················@gmail.com> writes:
> On Jun 14, 9:47�pm, ··········@rsw.digi.com.br wrote:
>> ····@zedat.fu-berlin.de (Stefan Ram) writes:
>> > � I could use �first component� and �second component�, but this
>> > � is a two-word term (compound term). I do not deem compound
>> > � terms to be appropriate for such fundamental concepts. For the
>> > � same reason, I prefer �pair� to �2-tuple�. A 2-tuple might
>> > � have a �first component� and a �second component�, but a pair
>> > � should have a CAR and a CDR (or some other single-word term).
>>
>> What about just >>first<< and >>second<<?
>
> Head & Tail perhaps.
Head and Tail are asymetric and presuppose a list structure.
First and Second expect a Third and Fourth and so on.
CAR and CDR are agnostic.
Alternatives would be: Top and Bottom, Up and Down, Left and Right,
Charm and Strange, Yin and Yang, etc. but they're all overloaded. At
least CAR and CDR are specific to computer pairs.
--
__Pascal Bourguignon__
On Jun 14, 2:28 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
>
> Alternatives would be: Top and Bottom, Up and Down, Left and Right,
> Charm and Strange, Yin and Yang, etc. but they're all overloaded. At
> least CAR and CDR are specific to computer pairs.
Hey, `yin' and `yang', I like that!
-- Scott
On Jun 14, 5:28 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
[...]
> Alternatives would be: Top and Bottom, Up and Down, Left and Right,
> Charm and Strange, Yin and Yang, etc. but they're all overloaded. At
> least CAR and CDR are specific to computer pairs.
The publishers of the venerable /Car and Driver/ magazine only half
agree. ;)
Cheers,
Pillsy
From: Pascal J. Bourguignon
Subject: Re: I can not find a word better than "CAR"
Date:
Message-ID: <87bpop1jya.fsf@galatea.local>
Pillsy <·········@gmail.com> writes:
> On Jun 14, 5:28�pm, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
> [...]
>> Alternatives would be: Top and Bottom, Up and Down, Left and Right,
>> Charm and Strange, Yin and Yang, etc. but they're all overloaded. �At
>> least CAR and CDR are specific to computer pairs.
>
> The publishers of the venerable /Car and Driver/ magazine only half
> agree. ;)
Notice the difference between CAR and car. The former is a TLA
standing for Content of Address Register part, the later is a word
derived from latin carrum designating a celtic two-wheeled war chariot.
Long life to case sensitivity!
--
__Pascal Bourguignon__
On 2009-06-15, Pascal J. Bourguignon <···@informatimago.com> wrote:
> Notice the difference between CAR and car. The former is a TLA
> standing for Content of Address Register part, the later is a word
> derived from latin carrum designating a celtic two-wheeled war chariot.
Dudeus, quo est carrum meum? :)
On 2009-06-14 17:28:58 -0400, ···@informatimago.com (Pascal J.
Bourguignon) said:
> Alternatives would be: Top and Bottom, Up and Down, Left and Right,
> Charm and Strange, Yin and Yang, etc. but they're all overloaded. At
> least CAR and CDR are specific to computer pairs.
THIS and THAT, and they're composable too!
cadr = thiat
cddr = thaat
caaadr = thiiiat
cdar = thais
;^)
--
Raffael Cavallaro
In article <············@news.eternal-september.org>,
Raffael Cavallaro <················@pas.espam.s.il.vous.plait.mac.com>
wrote:
> On 2009-06-14 17:28:58 -0400, ···@informatimago.com (Pascal J.
> Bourguignon) said:
>
> > Alternatives would be: Top and Bottom, Up and Down, Left and Right,
> > Charm and Strange, Yin and Yang, etc. but they're all overloaded. At
> > least CAR and CDR are specific to computer pairs.
>
> THIS and THAT, and they're composable too!
>
> cadr = thiat
> cddr = thaat
> caaadr = thiiiat
> cdar = thais
>
> ;^)
I like it :-)
I'm personally a fan of FST and RST, but if you really want something
concise that doesn't evoke lists I'd suggest SEL and SER for SElect Left
and SElect Right. These are also composable in the obvious way. Or if
you don't like Left and Right, you can do SEA/SEB, or SEX/SEY, SEA/SEZ,
or SEA/SEO (for Alpha and Omega). If you have a unicode-aware Lisp you
can even put real alpha and omega characters in there.
rg
Slobodan Blazeski <·················@gmail.com> writes:
> On Jun 14, 9:47��pm, ··········@rsw.digi.com.br wrote:
> > ····@zedat.fu-berlin.de (Stefan Ram) writes:
> > > �� I could use ��first component�� and ��second component��, but this
> > > �� is a two-word term (compound term). I do not deem compound
> > > �� terms to be appropriate for such fundamental concepts. For the
> > > �� same reason, I prefer ��pair�� to ��2-tuple��. A 2-tuple might
> > > �� have a ��first component�� and a ��second component��, but a pair
> > > �� should have a CAR and a CDR (or some other single-word term).
> >
> > What about just >>first<< and >>second<<?
>
> Head & Tail perhaps.
The problem that I see with HEAD and TAIL is that they make me think of
two different types of structures. Granted, they are isomorphic to CAR
and CDR, but on reflection that really just points up a problem with the
original formulation. The proper terms would really be CAR and CADR
(paralleling FIRST and SECOND).
--
Thomas A. Russ, USC/Information Sciences Institute
On Jun 14, 10:47 pm, ··········@rsw.digi.com.br wrote:
> ····@zedat.fu-berlin.de (Stefan Ram) writes:
> > I could use »first component« and »second component«, but this
> > is a two-word term (compound term). I do not deem compound
> > terms to be appropriate for such fundamental concepts. For the
> > same reason, I prefer »pair« to »2-tuple«. A 2-tuple might
> > have a »first component« and a »second component«, but a pair
> > should have a CAR and a CDR (or some other single-word term).
>
> What about just >>first<< and >>second<<?
>
> Rodrigo
As noted many times before, car & cdr have a good property of nesting:
caar, cadar and even cadadar :)
You can try fst & rst: frst, frrst,-- for that as well. But it as well
(like car/cdr) requires getting used to.
Other variants don't seem to work
Best regards,
Vsevolod