Earlier quoted context omitted.
I think this depends on which RnRS you look at.
Do some of the older ones just completely omit reserving them?
R6RS: pairs and lists, enclosed by ( ) or [ ] (see section 4.3.2)
The Nature of Lisp (2006)
71–80 of 95 posts
Re: The Nature of Lisp (2006)
#72Re: The Nature of Lisp (2006)
#73Earlier quoted context omitted.
FIRST and REST as names for list operations have been added 40 years ago. Pattern destructuring and list templates are as old. Naming is important, but the core Lisp names can be learned in a day.
Yes, and yet the names Cons and Cdr still exist and come up in introductory documentation and are still used in discussions constantly -- why?
There is actually a good reason: it's precisely because they bring in no semantic baggage. Although conses are usually used to build list structure, they don't have to be used that way; you can make binary trees or even arbitrary graphs with cycles out of them (creating directed cycles requires side effects, of course). The accessors 'first' and 'rest' are appropriate only for conses used as list structure. Even 'left' and 'right', which are less semantically loaded than 'first' and 'rest', wouldn't be appropriate in all cases.
So, what would be a better name than 'cons'? 'List' is not right; the empty list is not a cons. Scheme uses 'pair', which is admittedly not too bad, but I think it would be more appropriate for an immutable pair than a mutable two-element struct. (I actually think there should be two types, immutable pairs and mutable conses. In such a Lisp, conses would probably be fairly rarely used, and much more of a historical relic.)
And to echo what outworlder says, it really just isn't that big a deal. Yes, Common Lisp has some historical baggage, and a lot of things we would change if were designing our own Lisp from scratch — I assure you every Lisper has their own list. But CL rationalization projects, of which there have been several over the years (and, no doubt, more that I'm not aware of), don't catch on. The reason is clear: the CL community is already "small yet remarkably fragmented" as I recall someone putting it (Eric Raymond?); a rationalized CL would just fork off another sub-community, if it caught on at all.
Re: The Nature of Lisp (2006)
#74Earlier quoted context omitted.
> Like - it's 2018 and people are still using 'cdr' and 'cons' as terminology and happily expecting other people to learn those words Ok, so what do you think are better names for those operators and why would they be better?
'first' and 'rest' for 'car' and 'cdr' are obviously better, because they say what's going on, and that's why some people are already using them. I'm not sure if there's a good term that's not already used for 'cons'. Maybe 'Join' or something. Do I even need to justify why these are better names? The problem is not that people don't know about better names. Everyone does [0]. My issue is that this doesn't seem to bo…
> 'first' and 'rest' for 'car' and 'cdr' are obviously better, because they say what's going on
I sometimes use cons cells for binary trees - first and rest are misleading in that case. I very often use cons cells to define things - the car is some object and the cdr is some property or definition that applies to the object. first and rest are misleading for that use case.
What you are proposing is to use domain-specific names for operations on an abstract data structure. Any names with pre-existing meaning will become misleading as soon as the data structure is applied to a different application. Coming up with new terminology to unambiguously refer to new technical concepts is not a "problem," it is a means of effective communication.
Re: The Nature of Lisp (2006)
#75Earlier quoted context omitted.
That said, it would be nice if lisp used square brackets for this instead. Easier to type on boring old US QWERTY.
Parentheses are so much more frequently typed than square brackets in almost every context that you are better off following the Lisp Machine keyboard layout and swapping them on your keyboard even if you do not program in Lisp: https://news.ycombinator.com/item?id=14985932
Yes, agreed. From your previous comment:
> Apple does not provide a way to do these remappings on OS X
Run Emacs (or XEmacs) under XQuartz and you can do whatever remapping you want. This is how I deal with it.
Another choice is a fully programmable keyboard, though these also tend to have nonstandard layouts that require some retraining.
Re: The Nature of Lisp (2006)
#76Earlier quoted context omitted.
It is a true statement, lisp syntax is wierd. You spend years learning that 2 + 2 = 4, seeing (+ 2 2) for the first time is a bit of a shock. The point is overused but its a good point and he doesnt dwell on it. Arguments shouldnt be evaluated just by how interesting they are.
Algol syntax is weird. Tell me, what does this mean? x = x + 5 Obviously, it's a null statement. It's nonsense. x cannot equal x + 5 because that means 0 = 5 and, therefore, 0 = 1 and, therefore, all mathematics is broken. However, most Algols are completely happy to accept that statement, something we learned was nonsensical way back in our childhoods, as not only valid but as the only way of doing things. My point…
That's precisely why Algol used ':=' for assignment ;-}
Re: The Nature of Lisp (2006)
#77Earlier quoted context omitted.
IDK, I feel like this is the kind of slightly smug reasoning that's seen lisp get passed by. Just because I believe the factory-made, cheap, and standardized building blocks are a better medium than your artisan homemade clay blocks doesn't mean I'm just a dumb pleb churning out junk. I just have different values than you. I've spent lots of time crafting the greatest macros and trying to deal with missing/half finis…
> doesn't mean I'm just a dumb pleb churning out junk I do not see how what I wrote would support this claim The actual underlying theme was: if you really need a medium to express yourself(or in this case, your thoughts), Lisp is great. The comparison to clay was because: it is mold-able, it is not easy to work with, most people do not want to get their hands dirty with it, they may not even be interested on it. And…
You know, I did misread what you said. The rest of your post is entirely true.
I saw the kind of argument that I'm used to hearing lispers make and overreacted. My issue is I'm not really sure that lisp is actually better at doing things at a lower level. You have more freedom with syntax, sure, but I'm not at all convinced that's the same thing as building things up from the bottom. Rust, for example, will let you do low level things that lisp really can't, and Ocaml will let you build up typologies in ways lisp isn't made to.
At the end of the day, languages really aren't that different, especially modern ones, you're mostly working with the same abstractions, and the question becomes is syntactic freedom more important or is a growing community more important? That actually is my biggest issue with lisp (and most other language) evangelism. It's a bunch of claims that aren't really rooted in any kind of evidence.
Re: The Nature of Lisp (2006)
#78Earlier quoted context omitted.
Algol syntax is weird. Tell me, what does this mean? x = x + 5 Obviously, it's a null statement. It's nonsense. x cannot equal x + 5 because that means 0 = 5 and, therefore, 0 = 1 and, therefore, all mathematics is broken. However, most Algols are completely happy to accept that statement, something we learned was nonsensical way back in our childhoods, as not only valid but as the only way of doing things. My point…
That's precisely why Algol used ':=' for assignment ;-}
Eh, C/Java is an Algol, too.
You know, like how Scala/Scheme is a Lisp.
Re: The Nature of Lisp (2006)
#79Earlier quoted context omitted.
I can handle parentheses. What really gets me? Semicolons. Most useless character in programming language history. Every time I switch from a language that doesn't require them to one that does, the pirates run away from me.
Well, what are the options for detecting the end of a statement? You can have a language where all possible statements are clear about where the end is from just the statement alone . You can have a language where each statement has to be on a separate line, and only on one line (or where you specially mark a continuation of a statement from the previous line). Or you can have a termination marker. As far as I can te…
Technically, of course, there are no statements in Lisp; there are only expressions (forms, Lisp calls them).
The artificial distinction between statements and expressions is a source of endless annoyance to me when I'm working (as I do, for my day job) in a language that has it. In Lisp I can say things like
(when (some (lambda (x) ...) some-list)
(do-something))
The point is, I think this complaint, about the statement/expression distinction, has a lot more substance than complaints about either parentheses or semicolons.
Re: The Nature of Lisp (2006)
#80Earlier quoted context omitted.
I can handle parentheses. What really gets me? Semicolons. Most useless character in programming language history. Every time I switch from a language that doesn't require them to one that does, the pirates run away from me.
Well, what are the options for detecting the end of a statement? You can have a language where all possible statements are clear about where the end is from just the statement alone . You can have a language where each statement has to be on a separate line, and only on one line (or where you specially mark a continuation of a statement from the previous line). Or you can have a termination marker. As far as I can te…
Python handles this really well.
A statement can span multiple lines. And it has no termination marker.