Subject: Re: Little doubts with "if" clause From: Erik Naggum <erik@naggum.net> Date: Sun, 02 Dec 2001 05:27:22 GMT Newsgroups: comp.lang.lisp Message-ID: <3216259639613128@naggum.net> * cbbrowne@acm.org | 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 possibility. | 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.