(1) This one I think is the right decision. The real constructor is, after all, cons; and in fact, (is (type:cons 'a 'b) 'cons) but (isnt:alist:cons 'a 'b), since cons is more generic. Being a list is a property that certain sets of cons cells have, but it isn't their type.

(2) Again, I think this is the right decision. The point of obj is to be convenient in the simple case where you're building an object-like hash table: one with fixed fields and changing contents. I feel that table should probably take arguments like obj but without quoting (so that (obj a 1 b 2) would be (table 'a 1 'b 2)), but obj is still handy to have around.

(3) Ah, car/cdr versus first/rest. There's not really anything I have to add to this one, other than that I like the conciseness and composability. I've also seen fst and rst proposed, so that you can do frst for first:rest; make of that what you will.

(4) Yes, this is annoying. The rationale is the same as in the obj case, but I very often want to compare to non-symbols.

(5) If we accept that association lists are really just lists which have a certain structure, then we can't use special syntax, etc., as that already means something for lists. What if you have (= a '((1 a) (2 b))); would a.1 be a (since it's an association list) or b (since that's element 1 of the list)? I would also argue that the point of association lists is to be lists with special structure; if you want something like that that's its own type, that's what tables are for.

(6) I haven't really used deftem, but it does define a template; you create them using inst. On the other hand, obj creates the table right there.

Ok I can see this. Thank you for pointing this out, but I still don't see why it can't be type list.... list is more intuitive.

>(2)

I don't see how obj is convenient when you can't pass in functions, or when new users have to remember "use symbol here - oh but not here, or there when this case is true" - reminds me of i before e but not after c. Shouldn't a goal of language design be to prevent these kinds of things and focus on promoting language adoption / ease of use ?

>(5) "I would also argue that the point of association lists is to be lists with special structure; if you want something like that that's its own type, that's what tables are for."

The only use I can see for an association list is to have a key/val pairs structure that maintains order; Which tables do not. Otherwise I think alist would be dead. They don't have to be called "list" or "table" call them "directories", "catalogs" - whatever... I think there's an ease of use benefit having users being able to use the same tools in the "alist" as they do tables.

>(6) "I haven't really used deftem, but it does define a template; you create them using inst. On the other hand, obj creates the table right there."

makes sense. it's probably just related the other post... ie. why is it called obj? creates confusion.

===

Everything is a trade off. I'm not suggesting the justification as to "why" doesn't have merit, I'm suggesting Arc should try leaning more towards audience adoption and being more intiutive rather than being so strict that we care about each token, or having to be absolutely technically correct. Or to carry forward bad concepts from languages that are not well adopted even when more powerful.

Traditionally, there's a distinction -- if only in discussion, and not code -- made between nil-terminated conses and a cons with another terminator. If and only if a cons is nil-terminated, it's a list. Otherwise, it's simply a cons.

  car -> first
  cdr -> next
  caar -> ffirst
  cadr -> fnext
  cdar -> nfirst
  cddr -> nnext

    (= x (list "One" "Two" "Three" "Four" "Five" "Six"))

    (def first (xl)
      (car xl)) 

    (def next (xl (o n 1))
      (withs (n (+ n 1)
              nxl (cut xl 1 n))
       (if (single nxl)
           (car nxl)
           nxl)))

    (def rest (xl)
      (cdr xl))
 

    arc> (first x)
    "One"
    arc> (next x)
    "Two"
    arc> (next x 3) ; the next three
    ("Two" "Three" "Four")
    arc> (rest x)
    ("Two" "Three" "Four" "Five" "Six")
    arc> (next:rest x)
    "Three"
    arc> (rest:next x 3) ; the rest of the next 3
    ("Three" "Four")
    arc> (last:next x 3) ; the last of the next 3
    "Four"
    arc> (first:next x 3) ; the first of the next 3
    "Two"

    first = car
    last = last
    rest = cdr 
    next = cadr
    next:+1 
    next:+2 
    ....

"+" does mean "add" to the majority of people on earth - as its common knowledge, and thus it's intiutive. Car means "something one drives" to almost everyone.

> "all names are somewhat arbitrary, and it's ok to have names that don't relate to what they're doing if you use them enough"

1. From the Arc FAQ (http://paulgraham.com/arcfaq.html):

> Why did you keep car and cdr?

Because we couldn't think of any better alternatives. It would have been misleading to use first and rest or head and tail, because conses are fundamentally pairs; lists are one thing you can build with them, but not the only thing.

There's no conventional name in English for the first and second halves of a pair. If you have to make up names, car and cdr are pretty good choices, because they're short and the same length and naturally composable (e.g. cadr).

Example. I played a little the other day to implement surreal numbers (http://en.wikipedia.org/wiki/Surreal_number) in Lisp, using conses.

Basically, surreal numbers are a pair of two (surreal) numbers sets, the left one, and the right one.

0 is (() . ()), (cons () ()), where () is the empty set.

1 is (() . <surreal 0: (() . ())>)

-1 is (<surreal 0> . ())

It doesn't make sense to get the right set by saying (rest <surreal 0>), because it's just not the "rest", it's just the... cdr, i.e: the second halve of the 'cons. I mean conceptually, it's not the "rest".

2. Car means "something one drives" to almost everyone. No, no, NO. Ask, for instance, the 1+ billion Chinese people if "car" means anything to them. Just stop the fucking English-centrism. Will English be the proeminient language in 100 years? Is programming reserved to English-native-speakers? Is it good to mimic human languages in programming languages (hint: Algol VS C syntax)?

I love car/cdr because they don't mean anything.

Well actually, yes, they mean/meant something: content of {address|decrement} registry. But, in my view, they have just turn into arbitrary-chosen names for basic operations, like "+" is the arbitrary name of the "addition op" in our current arithmetic. You just learn that +/car means "this basic op", it becomes common knowledge, and you're done. I don't know, it's not even a name at this point, just the representation symbol.

>"No, no, NO. Ask, for instance, the 1+ billion Chinese people if "car" means anything to them. Just stop the fucking English-centrism."

I am willing to bet if you asked that question to every person on earth "what is car?" that statistically, the answer would represent my statement, even if by merit that some languages do not have a meaning for "car" and English, in my opinion, is more widely adopted. I could be wrong, but I don't feel bad about making that statement.

[Edited - deleted some of my own BS comments :) - thank you pg for having edit time]

Still- Maybe I should have written it this way: "Car does not mean first to almost everyone"

>"Will English be the proeminient language in 100 years?"

Not sure. I think the world we be a much better place if the average world citizen spoke multiple languages. And you never know maybe in doing so new languages could emerge and maybe there will be a "most powerful language" yet maybe it will not be widely adopted, or maybe it will.

We shall see :) (Edit - Opps - I just realized we will not)

Then you define some functions to operate (exclusively) on this new "data type", and 'last is one of them. Exclusively: (last (cons 'a 'b)) doesn't work, because it'd have no meaning to use 'last here. '(a . b) is not a list, just a cons.

Similarly, one way you could use lists is to build a-little-less-general abstraction, association lists. Then you define 'alref/etc. to use with this new data type. But (alref (list 'a 'b 'c) 'a) doesn't work, since it has no meaning in this context.

But 'car/'cdr, they operate on raw conses, not only on lists. And I said before, IMHO, 'rest is not good, because you're assuming by using this name that it is an operator for lists only. Yes, (rest '(a . b)) would work, but its meaning is crappy here (IMHO).

But you're making an interesting point. Maybe 'rest/'first should be also included, as synonyms for 'cdr/'car because actually people almost always use 'car/'cdr when working with lists, and in list context, their meaning may be easier to understand. But this is another debate.

---

About the meaning of 'car. Sure, if you're programming in one of the current dialects of Lisp, you have some basic notions of English, even if you're Chinese. Yet, when reading some Lisp code, if I see 'car I just know it means "first halve of the pair". I mean, before you pointed out that "car" means "a vehicle" most of the time, I didn't ever think about this (valid) point when reading/writing Lisp code. That's why I don't see it as a problem.

I don't know, I suppose it's because the context is important. When I see 'map in a Lisp file, I don't think about a (geographical) map. When I see 'cons I know it's not as in "pros & cons". When I see 'table, I know it's not about a dining table. When I type `cd' in my shell, I know it means "change directory" and not "compact disc", etc.

Yes, if you ask a random guy in the street what "car" means he'll answer you "a vehicle" and not "the first halve of the pair". But it's the same problem if you ask it what "cd" or "table" means. There are ton of issues like this, even in natural languages. For instance, homonyms: a tire is both a car wheel and the feeling of fatigue.

---

About language adoption. It seems pg knows it is important: So whether or not a language has to be good to be popular, I think a language has to be popular to be good. And it has to stay popular to stay good. (http://paulgraham.com/popular.html)

OTOH, remember Arc is made for "hackers" and to be adopted by "hackers" (at least at first). And there is the "100 years" idea (i.e: no rush in adoption may not be a problem). So maybe pg's idea of "language adoption" is not the same than yours ;-)

---

> (Edit - Opps - I just realized we will not)

Funny yet true one :-)

Absolutely and it's "because the context is important" that I made the suggestion. I don't really care that it's called "car". I'm just suggesting that IF you're going to have a function called "last" why wouldn't you create "first", as the user will intuitively try to use it given that last exists.