Gruppen du sender innlegg til, er en Usenet-gruppe. E-postadressen til forfatteren av meldinger som legges inn i denne gruppen, vil vises for alle på Internett.
On 2009-06-15, Stefan Ram <r...@zedat.fu-berlin.de> wrote:
> r...@zedat.fu-berlin.de (Stefan Ram) writes: >>Ron Garret <rNOSPA...@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«.
On 2009-06-15, Pascal J. Bourguignon <p...@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.
p...@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.
>> >> > On Jun 14, 2:20 pm, Pascal Costanza <p...@p-cos.net> wrote: >> >> >> Scott Burson wrote: >> >> >> > On Jun 14, 1:34 pm, Slobodan Blazeski <slobodan.blaze...@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".
> On 2009-06-15, Stefan Ram <r...@zedat.fu-berlin.de> wrote: > > r...@zedat.fu-berlin.de (Stefan Ram) writes: > >>Ron Garret <rNOSPA...@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*.
> >> >> > On Jun 14, 2:20 pm, Pascal Costanza <p...@p-cos.net> wrote: > >> >> >> Scott Burson wrote: > >> >> >> > On Jun 14, 1:34 pm, Slobodan Blazeski > >> >> >> > <slobodan.blaze...@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.
* Ron Garret <rNOSPAMon-A9B40E.13360315062...@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.
In article <m3ab49xb3y....@moon.robolove.meer.net>,
Madhu <enom...@meer.net> wrote: > * Ron Garret <rNOSPAMon-A9B40E.13360315062...@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?
Ron Garret <rNOSPA...@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.
* Ron Garret <rNOSPAMon-A597D0.23353315062...@news.albasani.net> : Wrote on Mon, 15 Jun 2009 23:35:33 -0700: | In article <m3ab49xb3y....@moon.robolove.meer.net>, | Madhu <enom...@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:
> >> > On Jun 14, 2:20 pm, Pascal Costanza <p...@p-cos.net> wrote: > >> >> Scott Burson wrote: > >> >> > On Jun 14, 1:34 pm, Slobodan Blazeski <slobodan.blaze...@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?
Nick Keighley <nick_keighley_nos...@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.
On Jun 14, 11:48 am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> I was searching for a word referring to the »x« and »y« in the > relation »R(x,y)«.
in your case, first of all, you need to give a context. Without a particular specialization, )first element( and )last element( is perfect.
your question seems idiotic to me. It seems to be from the college student who has nothing to do. Philosophizing is a good thing, but your thinking on the issue as presented in your post is quite newbie. I'll explain a bit.
> I was searching for a word referring to the »x« and »y« in the > relation »R(x,y)«.
Ok. I'm expecting some context, or special field, that requires some special terminology. However, you didn't give much in the rest of your post. Fuzzily, you seem just want to rename the terms used in lisp langs. i.e. your context, is lisp languages cons cells. But are you considering this as for a new lisp lang? or do you mean this to be a thought experiment about )What terms would it be if we were to update lisp lingoes(? For a new lisp lang, trying to find a new term for things similar to traditional lisp's car cdr is sensible. For updating lisp lingoes, of course it won't fly in reality, but as a philosophization, that's ok, however, the context is different from say if you are writing a new lisp lang, and thus the candidate set of good terms differ in the two contexts.
Ok, so now suppose we are looking for a term for the first/second element of lisp's cons cell, and we are waxing philosophy on this, but other than that, no other specifics. Then, i think, )first( and ) second(, is good enough. Alpha and Beta is good, x and y could also be employed.
also note that, the traditional term, )car( and )cdr(, are functions that access the first or second elements. They don't refer to the first or second elements themselves, it's just that it is also convenient to use them to mean the first and second elements in practice, because there's generally no ambiguity. More properly, you'd say the )car component( or )cdr component(, or )first element of cons cell( and )second element of cons cell(.
Assume, for a moment, the word would be
> »alpha« and »beta«, respectively, then I would like to write > this explanation of "is a":
> "is a" > the relation, where the alpha is an instance of the beta
several things wrong here.
First, please don't use the )is a( term. The usage doesn't make sense. Did you pick up the )is a( phrase from the object oriented programing community?
Secondly, the second element in a cons cell is not a )instance( of its first element. The 2 elements in a cons cell do not have hierarchical relation in any sense. Their only relation, is ordinal. i.e. one comes after the other, as in B comes after A, 2 comes after 1, u comes after i.
now, taking a lead from your fashion of thinking, i'm thinking what possible good terms would be if we wax mathematics in... Mmm, there is in fact a close analogue: complex numbers. So, your )car( can be called the real part, and your )cdr( can be called imaginary part, and a fashionable coder could say, that the cons cell has a )is a( ) relation(, where the )complex( part is a )instance( of the )real( part. (I LOL)
> I looked up these web pages to find common, simple words for > the place holders »alpha« and »beta«:
Suppose i'm creating a lisp-like lang, and in my lisp, i have a cons like thing, except it has 3 cells. Suppose this )cons with 3 celles(, is called )fons( in my lang. Fons has 3 accessors, called )car(, )cbr (, )cdr(. These terms are based on lisp tradition. But now suppose, i'm dissatisfied with these terms, so i looked up 3-body problems in mathematics. JESUS, I FOUND NONE! Therefore, in actualality, car, cbr, cdr are the best! When i see them, i don't think of IMB 666 registers. I could use )first component(, )middle component(, )third component(, but that constitute the ill of wordygidiss!
> 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).
On Jun 16, 12:28 am, p...@informatimago.com (Pascal J. Bourguignon) wrote:
> Ron Garret <rNOSPA...@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.
On Jun 15, 1:36 pm, Ron Garret <rNOSPA...@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.
Madhu <enom...@meer.net> writes: > * Ron Garret <rNOSPAMon-A9B40E.13360315062...@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.
> > * Ron Garret <rNOSPAMon-A9B40E.13360315062...@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 ;-)
On Jun 14, 8:48 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> I found none.
> So actually, »CAR« and »CDR« are the nicest words for these > concepts I am aware of.
I'm surprised (actually, with cll moving closer in the direction of the other c.l.* newsgroups recently, I'm not) that no one has mentioned lhs and rhs. If a PAIR is constructed from a left-hand side and a right-hand side, and up to 4 levels of composition can be written as LRRLHS, you have a Lisp with these concepts actually well named.
Of course, this isn't actually an interesting or important concept. The reason Lisp dialects don't do this isn't because no one's thought of it, nor because it's not better in some platonic sense, but because the sense in which it's better is less important than the sense in which it's inferior: the slight agravation to experienced lispers writing (cadr (assoc ...)).
My problem with your statement above is that it is a dialectically true statement (*) but you phrased it in a way that makes it clear that you're viewing the problem metaphysically.
(*) said with philosophy hat on; with biology hat on, it would be a formal or developmental argument. I don't know that there's a CS way of phrasing that: *can* computer scientists reason dialectically ;-)
> I'm surprised (actually, with cll moving closer in the direction of > the other c.l.* newsgroups recently, I'm not) that no one has > mentioned lhs and rhs. If a PAIR is constructed from a left-hand side > and a right-hand side, and up to 4 levels of composition can be > written as LRRLHS, you have a Lisp with these concepts actually well > named.
And then we get to sing the "laurrels" of this brilliant naming scheme! :-)
-- Thomas A. Russ, USC/Information Sciences Institute
On Jun 14, 2:48 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> I was searching for a word referring to the »x« and »y« in the > relation »R(x,y)«. Assume, for a moment, the word would be > »alpha« and »beta«, respectively, then I would like to write > this explanation of "is a":
> "is a" > the relation, where the alpha "is a"(n) instance of the beta > ¯¯¯¯¯ ¯¯¯¯ > I looked up these web pages to find common, simple words for > the placeholders »alpha« and »beta«:
> ://en.wikipedia.org/wiki/Relation_algebra
>'the relation, where the alpha "is a"(n) instance of the beta'
"Is a" is recursively defined? Except you don't seem to have a limiting condition.
Perhaps if you used a more concrete starting definition you wouldn't have so much trouble.
(car (1 2 3)) => 1 (cdr (1 2 3)) => (2 3)
car is an instance of the cdr? 1 is an instance of 2 3
> .
> I found none.
(member 1 (set 1 2 3))
member is an instance of set 1 is an instance of 1 2 3 How about member and set?
> So actually, »CAR« and »CDR« are the nicest words for these > concepts I am aware of. I can pronounce them, I do not think > of IBM 704 registers when I use them. And they are well > established. Or are there any other terms, I could use instead > of »alpha« and »beta« above?
> 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).
A pair should have car and cdr? a pair or a cons? a cons maybe.
* 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.
|
