Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
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.