Subject: Re: Little doubts with "if" clause
From: Erik Naggum <>
Date: Sun, 02 Dec 2001 05:27:22 GMT
Newsgroups: comp.lang.lisp
Message-ID: <>

| Stepping back a little bit, it's a _little_ irritating that there's not a
| convenient way to get an IF to encapsulate appropriate implicit PROGNs.

  But what does progn mean to you?  I read prog1, prog2, and progn with the
  same eye to _incidental_ side effects to a returned value, just in order
  to avoid really hairy expressions and deep nesting.  The same thing may
  be accomplished with let*, of course,  For some reason, I prefer implicit
  progns when I want bodies with several forms for pure side-effect, but do
  not see explicit progns as anathema to good style, like some other people.

  It is not particularly hard to write an if macro that lets the third form
  start with then to mean progn, and the fourth form start with else to
  mean progn.  The infamous else-if "problem" could then simply be a new if
  in the else-branch.  No keywords, no magic, and standard navigability and
  formatting, with almost complete compatibility with existing Common Lisp
  code, unless they had functions or macros called "then" or "else", so it
  would be a very good idea to put this in a new package to avoid problems
  and not pretend it "is" Common Lisp.  I am not at all sure this would buy
  anyone anything, however.

| I quite agree with him on the notion that DO is pretty painful to use;
| he phrases it as "do feels like object code."

  I only think DO is ugly if the step-form is identical to the init-form --
  it is so common that it should have had support, but all suggestions are
  fairly ugly.  (Like using a dotted list (var init-form . t), although I
  prefer (var #1=init-form #1#) which is at least conforming Common Lisp.)
  Otherwise, stepping multiple variables is far a superior technique to the
  usual one-variable looping constructs.

| I'm not sure but that Arc couldn't be implemented atop a combination of
| CL macros and maybe a readtable or two.

  If this is impossible, it is at _best_ due to incompetence.  It would be
  _so_ smart of someone who wanted to build a new language to capitalize on
  existing compilers before he could build his own that it is _unthinkable_
  for someone who should have known Common Lisp well who does _not_ harbor
  a personal grudge against Common Lisp to specifically circumvent such a

| He's certainly free to hold such opinions; the thing that seems broken
| about the idea is that it seems to throw out a whole lot of stuff that
| _isn't_ broken, infrastructure that involves a whopping lot of work to
| reimplement.

  Suppose there is an axis with language implementer on one end and user on
  the other.  Let it be used to represent where the responsibility for
  implementing a feature lies.  Common Lisp and Java would be on the far
  end towards the implementer, while Scheme and other toy languages would
  be on the far end towards the user.  If you are a user, you want the
  language implementer to take care of things for you.  If you are a lazy,
  egoistic implementer, you want the user to take care of most things for
  you, but if you are conscientious implementor, you realize that the user
  community benefits greatly from a common implementation of a lot of
  functionality.  It is odd that Arc goes in the "user" direction when the
  languages that Paul Graham appears to think have had success are all
  based on baking almost everything useful into the language implementation.

  The past is not more important than the future, despite what your culture
  has taught you.  Your future observations, conclusions, and beliefs are
  more important to you than those in your past ever will be.  The world is
  changing so fast the balance between the past and the future has shifted.