[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: s-exprs + prototypes
> From: "Anton van Straaten" <firstname.lastname@example.org>
> Date: Sat, 21 Jun 2003 19:48:55 -0400
> > I see the OO paradigm of communication via messages between things
> > that encapsulate data as more general than lists.
> The two aren't directly comparable, since they don't fill corresponding
> roles. Encapsulation of data and/or behavior behind an interface of some
> kind is very important, but it's not specific to OO. In fact, it's
> important to lists too - see below.
> > Everything is an object, not everything is list.
> Surely you see the relativeness of statements like this. Lambda calculus
> says that everything is a function, for example - and follows through on
> that in a way that no computer language does. Everything could be a list if
> you wanted it to be, but neither Lisp nor Scheme claim this. Lists are
> simply a core data structure that are a good fit for recursive processing
> and for expressing a variety of more complex structures, including trees.
Another point: lisp/scheme advocates never claim that everything is a list.
What they (I) claim is that all *code* can be expressed in terms of nested
lists, which is quite different. There is nothing particularly magical
about this choice; you could instead represent code as trees (which is, as
has been pointed out, isomorphic to lists anyway), or as an abstract syntax
tree (like camlp4 does for ocaml), or presumably as objects. However,
lists are particularly convenient for this purpose and they make macro
writing particularly easy compared to alternatives I've seen.
Using lists to represent arbitrary data structures is a different issue,
and IMO is much more controversial (or should be). While you can do this,
it is often neither the most elegant way to write programs nor the most
efficient. Pure scheme has no notion of structs or records like most
languages do (although most schemes provide this as an extension), and I
think this is a significant weakness which leads programmers to use lists
in places where they are not the optimal solution. Why this is so is an
interesting question; are there multiple disjoint reasonable record
implementations, similar to the multiple disjoint reasonable object