Message from discussion
How Lisp's Nested Notation Limits The Language's Utility
Path: g2news1.google.com!postnews.google.com!h2g2000hsg.googlegroups.com!not-for-mail
From: Joe Marshall <eval.ap...@gmail.com>
Newsgroups: comp.lang.lisp,comp.emacs,comp.lang.scheme,comp.lang.functional
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date: 6 May 2007 13:16:42 -0700
Organization: http://groups.google.com
Lines: 74
Message-ID: <1178482602.303291.16440@h2g2000hsg.googlegroups.com>
References: <1178323877.927816.20770@o5g2000hsb.googlegroups.com>
NNTP-Posting-Host: 71.202.61.211
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: posting.google.com 1178482603 17688 127.0.0.1 (6 May 2007 20:16:43 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Sun, 6 May 2007 20:16:43 +0000 (UTC)
In-Reply-To: <1178323877.927816.20770@o5g2000hsb.googlegroups.com>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.1; .NET CLR 3.0.04506.30),gzip(gfe),gzip(gfe)
Complaints-To: groups-abuse@google.com
Injection-Info: h2g2000hsg.googlegroups.com; posting-host=71.202.61.211;
posting-account=BTsObw0AAAAePJa45-w8T2_mYFbnHZkG
On May 4, 5:11 pm, Xah Lee <x...@xahlee.org> wrote:
> How Lisp's Nested Notation Limits The Language's Utility
>
> Xah Lee, 2007-05-03
>
> There is a common complain by programers about lisp's notation, of
> nested parenthesis, being unnatural or difficult to read. Long time
> lisp programers, often counter, that it is a matter of conditioning,
> and or blaming the use of "inferior" text editors that are not
> designed to display nested notations. In the following, i describe how
> lisp notation is actually a problem, in several levels.
I think you're wrong, Xah. If the syntax is a problem, why haven't
any alternative syntaxes taken over for s-expressions? I point to
these examples:
M-Expressions (c. 1962)
maplist[x;fn]=[null[x]->NIL;
T->cons [fn[x];maplist [cdr [x];fn]]]
CGOL (c. 1977)
define "CGMAP"(x, inon, disp, typ);
if atom car x or caar x not isin !'(quote function)
or if atom cadar x then typ ne "mapcar" else caadar x ne "LAMBDA"
then (princ typ; let lbd=0, rbd=0; cglist(x, ", ", 0, 0))
else if atom cadar x and typ = "mapcar" then
(cgolprin2(cadar x, lbd, rbd, depth);
princ "["; let lbd=-1, rbd=0;
cglist(cdr x, ", ", 0, 0);
princ "]")
else (printeol;
princ "for ";
for vars on cadr cadar x, argts on cdr x do
(lcprinc car vars;
princ inon;
cgolprin2(car argts, 2, 0, depth+1);
if cdr vars then princ ", ");
princ disp;
let depth = depth+1; printeol;
cglist(cddr cadar x, "; ", 1, 0)) $
Dylan (c. 1990)
define function find-position-and-velocity
(rock :: <rock>, time :: <float>)
=> (position :: <float>, velocity :: <float>)
values(-4.9 * time * time
+ rock.initial-velocity * time
+ rock.initial-position,
-9.8 * time
+ rock.initial-velocity);
end function;
Curl (late 1990s)
{method public {set-size layout:LayoutContext, rect:GRect}:void
{super.set-size layout, rect}
|| match pixmap size with display
let width:int = ((rect.lextent + rect.rextent) / pixel-length) asa
int
let height:int = ((rect.ascent + rect.descent) / pixel-length) asa
int
set self.current-pixmap = {Pixmap width, height, ignore-alpha?
=true}
{self.on-resample}
}
Every year someone comes on comp.lang.lisp and informs us
that it is the parenthesis that are the problem. But in more than
forty years no one has come up with a better alternative, and
it hasn't been for want of trying or lack of imagination.