From: ·······@my-deja.com
Subject: Re: please tell me the design faults of CL & Scheme
Date: 
Message-ID: <nm91yscs1lp.fsf@kindness.mit.edu>
This is an unusual question.  I'm curious as to why you ask.  Are you
choosing between these two languages for a particular project?

From: David Fox
Subject: Re: please tell me the design faults of CL & Scheme
Date: 
Message-ID: <77CF7AB5AE8AD523.FC53D3F20E47C761.7DF8A06E80101E01@lp.airnews.net>
·······@my-deja.com writes:

> This is an unusual question.  I'm curious as to why you ask.  Are you
> choosing between these two languages for a particular project?

I think its a great question, I'd like to see it answered for lots and
lots of languages.
From: ·······@my-deja.com
Subject: Re: please tell me the design faults of CL & Scheme
Date: 
Message-ID: <nm9wva3ornx.fsf@kindness.mit.edu>
·····@cogsci.ucsd.edu (David Fox) writes:

> ·······@my-deja.com writes:
> 
> > This is an unusual question.  I'm curious as to why you ask.  Are you
> > choosing between these two languages for a particular project?
> 
> I think its a great question, I'd like to see it answered for lots and
> lots of languages.

It makes sense to ask for lots of languages individually.  But when
asked of two languages at once, it sounds like a comparison.  I don't
think it's a fair comparison for these two languages.  Scheme, designed
primarily for teaching purposes, is more likely to leave out a feature
rather than include it with design flaws.

I define design flaws as problems that require backwards-incompatible
changes to fix.  You wouldn't want examples in a textbook to stop
working because of such a change.

CL, used for large projects, doesn't have the luxury of waiting until
the best possible design has been created before implementing
something, so it's likely to include more design flaws.  This doesn't
mean that you can choose Scheme for your project and build the missing
features yourself, and then expect the resulting system to have fewer
design flaws than if you started with CL.

(I don't actually use CL myself.  Those who know what they're talking
about feel free to step in.)

Anyway, about design flaws.  I think Scheme was generally designed well,
except some procedure names where chosen badly s.t. they will likely
never be changed.

The Scheme designers started to translate Lisp into something more like
English, but didn't finish the job, e.g. consp --> pair?, but they left
cons, car and cdr untouched.  Probably they had used them so long they
thought they *were* English words.

They should have used pair, first and rest.  If they were too
uncomfortable about "rest" for non-list pairs (technically correct, but
not the word one would normally use), and consciously kept cons/car/cdr,
then they should have kept pair? as cons?, following the uniformity of
other constructors / type predicates.

Conversion functions, e.g. number->string, are named consistent with
imperative style.  Wouldn't an expression like this...

(list->string (reverse (string->list word)))

...read a lot better like this...?

(string<-list (reverse (list<-string word)))
From: Joe Marshall
Subject: Re: please tell me the design faults of CL & Scheme
Date: 
Message-ID: <k8627mbo.fsf@content-integrity.com>
·······@my-deja.com writes:

> The Scheme designers started to translate Lisp into something more like
> English, but didn't finish the job, e.g. consp --> pair?, but they left
> cons, car and cdr untouched.  Probably they had used them so long they
> thought they *were* English words.
> 
> They should have used pair, first and rest.  If they were too
> uncomfortable about "rest" for non-list pairs (technically correct, but
> not the word one would normally use), and consciously kept cons/car/cdr,
> then they should have kept pair? as cons?, following the uniformity of
> other constructors / type predicates.

There are two types here:  cons-cells and lists (which happen to be
implemented using cons cells as the backbone).   So CAR and FIRST,
although implemented the same, are logically different.  Likewise with
CDR and REST.

If you prefer writing CONS? (or CONSP) to writing PAIR?, it is easy
enough to fix.

> Conversion functions, e.g. number->string, are named consistent with
> imperative style.  Wouldn't an expression like this...
> 
> (list->string (reverse (string->list word)))
> 
> ...read a lot better like this...?
> 
> (string<-list (reverse (list<-string word)))

The latter version echoes the dataflow, but I don't think the former
is necessarily imperative.  STRING->LIST is a function mapping from
elements in the domain of strings to elements in the domain of lists.
The function name echoes the usual english usage of `from A to B'.


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----
From: Lieven Marchand
Subject: Re: please tell me the design faults of CL & Scheme
Date: 
Message-ID: <m3vgpmet8w.fsf@localhost.localdomain>
·······@my-deja.com writes:

> The Scheme designers started to translate Lisp into something more like
> English, but didn't finish the job, e.g. consp --> pair?, but they left
> cons, car and cdr untouched.  Probably they had used them so long they
> thought they *were* English words.
> 
> They should have used pair, first and rest.  If they were too
> uncomfortable about "rest" for non-list pairs (technically correct, but
> not the word one would normally use), and consciously kept cons/car/cdr,
> then they should have kept pair? as cons?, following the uniformity of
> other constructors / type predicates.
> 

CL has both car/cdr and first/rest and while they are equivalent in
effect, there is an intended difference to the reader. The first pair
of functions is meant to be used for an abstraction called a cons,
that is an implementation of the mathematical concept of cartesian
product of the set of lisp object with itself. The second pair is
meant to be used for the abstraction "list". The fact that lists are
implemented with conses is a historical coincidence, not a necessity.

-- 
Lieven Marchand <···@wyrd.be>
Gla�r ok reifr skyli gumna hverr, unz sinn b��r bana.