Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

almost done with ch2 of gentle intro damn the cddr cadr part is confusing....

53 views
Skip to first unread message

Gavino himself

unread,
May 22, 2017, 6:31:22 PM5/22/17
to
damn my brain hurting.

The car cdr first..tenth seems straightforward enough........
As is bit about cons and list.

Everything seems so ez in lisp....I have a feeeling I should have read this long ago...

Gavino himself

unread,
May 25, 2017, 3:06:31 AM5/25/17
to
damn second half of ch2 is geting hard
cons nil nil wtf!

George Neuner

unread,
May 25, 2017, 6:37:52 PM5/25/17
to
The CAR/CDR combinations were meant to be conveniences when Lisp was
very new and complex data structures were built primarily using cons
cells.

The combination functions have been kept as part of the standard
language for posterity, but few (if any) people use them any more.

CAR and CDR by themselves are widely used, but some people prefer to
use FIRST and REST when working with lists, or FIRST and SECOND when
working with trees built from conses.

But in modern usage, it's better to use ELT or NTH if you need to
reach deep into a list, and it's better to construct trees using
structures or objects rather than using conses.


The book is not wrong for teaching you about conses this way ... if
for nothing else it shows the versatility of the cons cells and of
Lisp's way of doing things ... but you don't need to worry about the
CAR/CDR combination functions because you will rarely, if ever, see
them other than in very old code.

George

Gavino himself

unread,
May 25, 2017, 8:09:19 PM5/25/17
to
Thank you!!!
TO what extent can you write large programs without resorting to a sql database like postgresql?
Could you ever do a lisp only program for say a e commerce website?
How would you split the data up among say 10 or 30 boxes as the website scaled?
What do you think of things like www.hypertable.org?
I dream of making awesome apps in lisp but am not very experienced except in shell and some python and tcl.

kint...@gmail.com

unread,
May 26, 2017, 7:29:12 PM5/26/17
to
> The CAR/CDR combinations were meant to be conveniences when Lisp was
> very new and complex data structures were built primarily using cons
> cells.
>
[ ... snip ... ]

> George

That was a very excellent response George . A great pleasure to read . Thank you !

~~ kintalken ~~

Pascal J. Bourguignon

unread,
May 26, 2017, 9:09:15 PM5/26/17
to
It's purely historical and dates back to even before LISP!

References:

* IBM 7090 User Manual:
http://bitsavers.trailing-edge.com/pdf/ibm/7090/22-6528-4_7090Manual.pdf

Those machines interpreted instruction words to contain an address field
and a decrement field. With such arrangement, it was practical to point
to the end of the data field (biggest address), and to start with the
largest decrement to point to the start of the field. The decrement was
decremented to 0, thus the pointer pointed to successive words up to the
last (with no possibility to go beyond the data field, since decrement
was not signed)! There was no buffer overflow errors on those machines,
even while you programmed them in assembler!


* FLPL (Fortran-Compiled List-Processing Language):
http://informatimago.com/articles/flpl/flpl.pdf

A library implementing NSS (Newell, Shaw, and Simon) lists using the
Content of the Address part of the Register as pointer to the element,
and the Content of the Decrement part of the Register as pointer to the
next cell in the linked list.

* LISP (AIM-8 Memo):
http://informatimago.com/develop/lisp/com/informatimago/small-cl-pgms/aim-8/index.html

LISP was based on the use of lists to represent data, including programs
as data, and reused the same kind of single-link list as in FLPL. John
McCarthy had been motivated in creating this new language, because the
Fortran guys didn't want to include in their compiler a ternary if
expression or a COND expression.


--
__Pascal J. Bourguignon
http://www.informatimago.com

Kaz Kylheku

unread,
May 26, 2017, 10:15:10 PM5/26/17
to
Counterpoint: I started programming in Lisp circa 2000.

In just recent years, I've started to use the functions cadr, cddr,
cadar and so on much more often.

The functions first, rest, second, third, to not feel appropriate,
except for flat lists.

Even then; as soon as I have a condition like "if there is a third
element, what is it?":

(when (consp (cddr x)) ;; there is a third element
.... access it with (caddr x) ...)

once I have tested with (consp (cddr x)), it feels stylistically
inconsistent to use the function (third x) to fetch this element!
rather than (caddr x), which clearly applies an "a" to (cddr x).

We know that if cddr is the the right cell, caddr gets us the car of it;
the only question is whether the two d's are the right number of
d's to get the cell we want.

There is no function to test for the presence of a third element
which pairs nicely with third. If I resort to (consp (nthcdr 2 x)),
then that pairs with (nth 2 x), not (third x).

We can use destructuring for this, but then we have to deal with
dummy variables for the places in the structure we don't want:

(destructuring-bind (a b &optional (c nil c-present-p)) x
(when c-present-p
;; we have the third element and its value is in c
))

The "cadars" are simply appropriate when we are groping through a tree
structure, without the benefit of destructuring.

In my own dialect of Lisp, which dates back no farther than 2009, I
provide them to five levels deep, from car to cdddddr because they are
so good. In its internals, I'm increasingly using cadr, and caddr
and such. This causes some stylistic tension when new functions that use
cadr and caddr appear next to older functions that use second and third.

Look at this. The TinyLisp implementation of a small Lisp for
microcontrollres uses 'a' and 'd' as interactive commands in its editor
for navigating the Lisp structure.

http://www.technoblogy.com/show?1INT

Scroll down to "Using the program editor".

This "a and d stuff" lives, you know?

George Neuner

unread,
May 26, 2017, 11:07:11 PM5/26/17
to
On Thu, 25 May 2017 17:09:15 -0700 (PDT), Gavino himself
<jack...@gmail.com> wrote:


>TO what extent can you write large programs without resorting
>to a sql database like postgresql?

That's not a clear question ... many applications have no need
whatsoever for a database. And there are many forms of database.

Incidentally, SQL is a language, not a type of database. SQL is used
primarily with "relational" databases, but there also are
"non-relational" and "partly-relational" databases. There are also
"ACID" and "non-ACID", "distributed" and "non-distributed". There are
databases that don't use SQL at all, and some that use lobotomized SQL
because they can't handle everything SQL can do.

Databases have many degrees of freedom.


It is perfectly possible to create a full client-server DBMS using
Lisp. AFAIK it has never been done commercially, but there is no
reason it could not be. A non-ACID, key-store or ISAM system would be
relatively simple. A full ACID relational system is unbelievably
complex: commercial quality RDBMS have literally *thousands* of
man-years invested in their implementations.


You mentioned Postgresql. Postgresql evolved from an existing
database called "Postgres" (without the "ql"). Postgres itself
evolved from a prior system called "Ingres".

Ingres was THE VERY FIRST publicly available relational DBMS. It was
released in 1974, almost a year before the 'R' database from IBM Labs.
Moreover, Ingres was free and open-source, created by people at the
University of California. Ingres was the preferred DBMS on Berkeley
Unix and was widely used.

However, Ingres did not use SQL - it used a very different language
called QUEL. SQL, in fact, did not yet exist when Ingres was
released, and Ingres never *officially* supported SQL even though it
was an option in later versions.

Many people felt that QUEL was superior to SQL, but IBM's marketing
power won out.


The long-winded point I'm making here is that modern SQL based
Postgresql has been in development for decades. To recreate its
capabilities in Lisp would take years ... not nearly as long as the
original development, but still a long time ... and it would be a
waste of effort that should have gone into using the existing DBMS
rather than trying to recreate it.



>Could you ever do a lisp only program for say a e commerce website?

You could ... but it would be orders of magnitude more work than just
using an existing DBMS.


>How would you split the data up among say 10 or 30 boxes as the
>website scaled?

This is impossible to answer in the abstract - it depends on the data.
Better to ask questions like these in a database forum with examples
of the data.


>What do you think of things like www.hypertable.org?

Availability? Consistency? Tolerance for communication problems?

Pick any 2 ... you can't have all 3.

It is a trusim that all high availability distributed systems have to
sacrifice either data consistency across their nodes, or tolerance for
communication problems among their nodes.


TL;DR. I haven't looked specifically at Hypertable, but most HA
systems have chosen to sacrifice data consistency, meaning that in the
event of network problems, data that *should* be identical on
different nodes may be different, and queries against different nodes
in the incomplete system may return different results.

Many applications can tolerate temporary inconsistency for some
definitions of "temporary". For example, almost nobody gives a shit
whether there is a 24hr delay in a tweet being viewable on the other
side of the world. But most people would scream if they made a bank
deposit, then flew a few hours to another city and arrived to find the
deposited money wasn't available.


You can reduce the problem by, e.g., making sure every piece of data
is stored to at least N nodes, so that it is more likely that an
overall consistent view can be assembled from the set of nodes that
are still available. But it's impossible to completely eliminate the
problem.


Hypertable and systems like it have their place, but they aren't good
for everything and they aren't replacements for RDBMS.


George
0 new messages