Little doubts with "if" clause
Francois Reland
Wich is the right strucuture?
(if (> Vble 4)
((do if yes)
(do if yes))
((do if not)
(do if not)))
I mean, how can I separate the if-yes commands from the if-not's?
Another question... how can I query for (not(> Vble 4)) (in this
example, it would be '<=' instead of '>', but with others).
I mean, in other languajes is:
!(Clause)
not(Clause)
How is it in LISP?? Thank you very much.
mda...@andrew.cmu.edu
> Good morning.
>
> Wich is the right strucuture?
>
> (if (> Vble 4)
> ((do if yes)
> (do if yes))
> ((do if not)
> (do if not)))
>
> I mean, how can I separate the if-yes commands from the if-not's?
(if (> vble 4)
(progn ;; then-clause
(do-something)
(do-something-again))
(progn ;; else-clause
(do-something-else)
(do-something-else-again)))
However it is advised that you use the COND form instead of the above:
(cond
((> vble 4) ;; then-clause
(do-something)
(do-something-again))
(t ;; else-clause
(do-something-else)
(do-something-else-again)))
I highly recommend consulting the Common Lisp HyperSpec on the meanings of
IF, COND, and PROGN (among other things).
http://www.xanalys.com/software_tools/reference/HyperSpec/FrontMatter/index.html
>
> Another question... how can I query for (not(> Vble 4)) (in this
> example, it would be '<=' instead of '>', but with others).
>
> I mean, in other languajes is:
> !(Clause)
> not(Clause)
>
> How is it in LISP?? Thank you very much.
(not (> vble 4)), you guessed correctly.
--
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Matthew Danish email: mda...@andrew.cmu.edu ;;
;; OpenPGP public key available from: 'finger m...@db.debian.org' ;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Erik Naggum
| Wich is the right strucuture?
What kind of material are you using in your study of Common Lisp?
///
--
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.
Kalle Olavi Niemitalo
> Wich is the right strucuture?
>
> (if (> Vble 4)
> ((do if yes)
> (do if yes))
> ((do if not)
> (do if not)))
It is (if TEST-FORM THEN-FORM ELSE-FORM), where ELSE-FORM may be
omitted. For example:
(if (> variable 4)
(write-line "variable is greater than 4")
(write-line "variable is not greater than 4"))
or omitting the ELSE-FORM:
(if (> variable 4)
(write-line "variable is greater than 4"))
(I suspect someone will now write I should call FRESH-LINE first.)
> I mean, how can I separate the if-yes commands from the if-not's?
You can only have one THEN-FORM in an IF, so if there is another
form after the THEN-FORM, it must be the ELSE-FORM.
If you need multiple forms in the THEN-FORM, you can use PROGN:
(if (> variable 4)
(progn
(write-line "variable is greater than 4")
(write-line "(therefore it's also positive)"))
(write-line "variable is not greater than 4"))
If there is no ELSE-FORM, it looks like this:
(if (> variable 4)
(progn
(write-line "variable is greater than 4")
(write-line "(therefore it's also positive)")))
Or you can abbreviate with WHEN:
(when (> variable 4)
(write-line "variable is greater than 4")
(write-line "(therefore it's also positive)"))
COND can be useful for long if-then-elseif-then-else chains:
(cond ((> variable 4)
(write-line "variable is greater than 4")
(write-line "(therefore it's also positive)"))
((minusp variable)
(write-line "variable is negative"))
((zerop variable)
(write-line "variable is zero"))
(t
(write-line "variable is a small positive number")))
> Another question... how can I query for (not(> Vble 4)) (in this
> example, it would be '<=' instead of '>', but with others).
You can use NOT, like you wrote:
(if (not (> variable 4))
(progn
(write-line "variable is not greater than 4")
(write-line "(not a very large number, then)")))
It works with WHEN too (or in any expression, for that matter):
(when (not (> variable 4))
(write-line "variable is not greater than 4")
(write-line "(not a very large number, then)"))
There is also UNLESS:
(unless (> variable 4)
(write-line "variable is not greater than 4")
(write-line "(not a very large number, then)"))
Coby Beck
<mda...@andrew.cmu.edu> wrote in message news:20011201051600.F2173@emu...
> On Sat, Dec 01, 2001 at 01:55:08AM -0800, Francois Reland wrote:
> > Good morning.
> >
> > Wich is the right strucuture?
> >
> > (if (> Vble 4)
> > ((do if yes)
> > (do if yes))
> > ((do if not)
> > (do if not)))
> >
> > I mean, how can I separate the if-yes commands from the if-not's?
>
> (if (> vble 4)
> (progn ;; then-clause
> (do-something)
> (do-something-again))
> (progn ;; else-clause
> (do-something-else)
> (do-something-else-again)))
>
> However it is advised that you use the COND form instead of the above:
>
Advised by whom? IF looks right to me....
--
Coby
(remove #\space "coby . beck @ opentechgroup . com")
Erik Naggum
| Advised by whom? IF looks right to me....
Me, I guess, but you would probably not have seen that, kill-files being
rather coarse-grained devices to block one's view to shocking truths. Go
look up the article I wrote on conditionals if you can read this.
The lack of an implicit progn in the if form is a hint that cond, which
has an implicit progn for each branch, would be more appropriately used
for bodies with side-effects and if for expressions.
cbbr...@acm.org
IF winds up forcibly drawing in PROGN forms, which falls into the
"isn't that artificially ugly?" category.
Two other possibilities:
(loop
for v = (> vble 4)
when v
do (do-something)
do (do-something-again)
when (not v)
do (do-something-else)
do (do-something-else-again))
(if* (> vble 4)
then
(do-something)
(do-something-again)
else
(do-something-else)
(do-something-else-again))
But I think the latter would cause #Erik's head to explode, so it's
not a terribly serious suggestion :-).
All in all, COND would seem the most natural choice of those available.
--
(reverse (concatenate 'string "moc.enworbbc@" "enworbbc"))
http://www.cbbrowne.com/info/multiplexor.html
Instead of talking to your plants, if you yelled at them would they
still grow, only to be troubled and insecure?
Erik Naggum
| But I think the latter would cause #Erik's head to explode, so it's
| not a terribly serious suggestion :-).
Thank you for your concern. :)
Note that if* is merely syntactic saccharin for cond. You have all the
benefits of if* without either bad style or bad taste if you use cond.
cbbr...@acm.org
> * cbbr...@acm.org
> | But I think the latter would cause #Erik's head to explode, so
> | it's not a terribly serious suggestion :-).
>
> Thank you for your concern. :)
>
> Note that if* is merely syntactic saccharin for cond. You have
> all the benefits of if* without either bad style or bad taste if
> you use cond.
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.
The creation of IF* apparently resulted from someone being _massively_
irritated by this, to the point apparently of desiring to redesign
chunks of CL.
There's a bit of a parallel in the Arc stuff; apparently Paul Graham
(and whomever else may be involved) wants to revisit some of the
control structures. (Strangely enough, he seems to want COND to _get
rid_ of the implicit PROGN; obviously people head in some different
directions :-).)
I quite agree with him on the notion that DO is pretty painful to use;
he phrases it as "do feels like object code."
The disagreements over "syntactic sugar" _don't_ make it evident to me
that it's dramatically worthwhile to start everything all over from
scratch. I'm not sure but that Arc couldn't be implemented atop a
combination of CL macros and maybe a readtable or two.
And once they get around to trying to _implement_ something, there are
vast quantities of implementational hoops that they'll have to jump
through.
- They haven't decided what pathnames will look like;
- They haven't defined what their math libraries will look like;
- They haven't described any sort of "virtual machine" or other
sort of model of what code is allowed to believe it's running on.
The point to Arc seems to be to fix up the things Graham thinks are
"crufty" about existing Lisps. 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.
--
(concatenate 'string "cbbrowne" "@cbbrowne.com")
http://www.cbbrowne.com/info/wp.html
Rules of the Evil Overlord #9. "I will not include a self-destruct
mechanism unless absolutely necessary. If it is necessary, it will not
be a large red button labelled "Danger: Do Not Push". The big red
button marked "Do Not Push" will instead trigger a spray of bullets on
anyone stupid enough to disregard it. Similarly, the ON/OFF switch
will not clearly be labelled as such." <http://www.eviloverlord.com/>
Erik Naggum
| 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.
Thomas F. Burdick
> * Coby Beck
> | Advised by whom? IF looks right to me....
>
> Me, I guess, but you would probably not have seen that, kill-files being
> rather coarse-grained devices to block one's view to shocking truths. Go
> look up the article I wrote on conditionals if you can read this.
>
> The lack of an implicit progn in the if form is a hint that cond, which
> has an implicit progn for each branch, would be more appropriately used
> for bodies with side-effects and if for expressions.
I thought that was a very good argument for COND in this case. For a
newbie, though, I would advise using COND all the time. Tell them
about IF, then say, "but use COND for now." Why? Because using IF
traps you in the little world of IF. It's ugly to have more than one
condition, and it's ugly to have more than one them or else clause. I
use COND unless I know for certain that I won't need more than one
clause, nor will I need to use PROGN in either of them. Because I
tested myself, and I'll avoid nested IFs and PROGNs in then/else
clauses when I use IF -- I assume because the operator itself
discourages them.
So, whom? Me, too.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Kent M Pitman
> Erik Naggum <er...@naggum.net> writes:
>
> > * Coby Beck
> > | Advised by whom? IF looks right to me....
> >
> > Me, I guess, but you would probably not have seen that, kill-files being
> > rather coarse-grained devices to block one's view to shocking truths. Go
> > look up the article I wrote on conditionals if you can read this.
> >
> > The lack of an implicit progn in the if form is a hint that cond, which
> > has an implicit progn for each branch, would be more appropriately used
> > for bodies with side-effects and if for expressions.
>
> I thought that was a very good argument for COND in this case. For a
> newbie, though, I would advise using COND all the time. Tell them
> about IF, then say, "but use COND for now." Why? Because using IF
> traps you in the little world of IF. It's ugly to have more than one
> condition, and it's ugly to have more than one them or else clause. I
> use COND unless I know for certain that I won't need more than one
> clause, nor will I need to use PROGN in either of them. Because I
> tested myself, and I'll avoid nested IFs and PROGNs in then/else
> clauses when I use IF -- I assume because the operator itself
> discourages them.
The COND/IF controversy was among the first places I started to learn life
lessons about how history is cyclic, and got a first-hand understanding of
the idea that people who do not learn from history are doomed to repeat it.
I've seen waves of people who grew up on IF going COND-crazy when they found
out how it freed them of PROGN, and as many waves of people going IF-happy
when they found out how it simplified out the extra parens for the simple
cases. People do so love to have a simple answer and to not have the complex
choice of deciding which to use on a case-by-case basis, but not until they
just embrace the fact that it's a subjective choice and that sometimes one is
better than the other and other times vice versa can they really rest.
I think the same of "time sharing" / "multiprocessing" was originally not
in computers, then as computers grew became important to make efficient use
of hardware, then as loads grew and machines got cheap became something
people outgrew, and then as machines were found largely empty and wasted
became more popular again, and ....
Client/side and Server/side computation has the same cyclic pattern of
evolution, each becoming popular with companies, and so with headhunters,
and so with universities, and then as quickly replacing the other again,
until finally negotiated peer-to-peer stabilizes things in a recognition
that neither client-side or server-side can really ever win...
So I say, take a few minutes out of talking about IF/COND to teach the
ways of the world, and then once your students understand that dynamic
tension that is just doomed to be present in life itself, come back and
teach the IF/COND situation as a tiny little instance of it, and the whole
debate will seem a lot less "big"...
Coby Beck
"Erik Naggum" <er...@naggum.net> wrote in message
news:32162483...@naggum.net...
> * Coby Beck
> | Advised by whom? IF looks right to me....
>
> Me, I guess, but you would probably not have seen that, kill-files being
> rather coarse-grained devices to block one's view to shocking truths. Go
> look up the article I wrote on conditionals if you can read this.
>
You've never been in my kill-file! And I never look away from what shocks me
anyway, truth or otherwise. Besides, I can't really say anything you write
shocks me. On top of that I would have missed your "feeling one's teeth"
discussion. (very entertaining!)
I read your article on conditionals, at least most of it and skimming the rest.
I guess for me the number of branches rather than side-effects or not guides my
choice of IF or COND. I guess it was mostly the passive tense "it is advised"
phrase that made me want to point out that is hardly a universal axiom of IF
that more than on form in a branch means it should be a COND.
> The lack of an implicit progn in the if form is a hint that cond, which
> has an implicit progn for each branch, would be more appropriately used
> for bodies with side-effects and if for expressions.
This is a strong argument, though one more from tradition than other stylistic
concerns. I still like the strong visual signal an IF form gives you that
there are two and only two branches. Variety is the spice of life, I like very
much that lisp provides so many ways to express your code.
Ed L Cashin
...
> 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.
I get the impression that while the language itself will have less
baked into it, there will be repositories ("huge libraries") of code
for the user to take advantage of. --Like perl's CPAN.
--
--Ed Cashin integrit file-verification system:
eca...@terry.uga.edu http://integrit.sourceforge.net/
Note: If you want me to send you email, don't munge your address.
Lieven Marchand
> (loop
> for v = (> vble 4)
> when v
> do (do-something)
> do (do-something-again)
> when (not v)
> do (do-something-else)
> do (do-something-else-again))
There's two problems with it: (1) you're going to loop forever, and
(2) you're second do's will always get executed since do introduces an
implicit progn and the second do introduces a new clause.
Combine those observations with the fact that when and unless as loop
keywords support an else clause and we get:
(loop for v = (> vble 4)
repeat 1
when v do
do-something
do-something-again
else do
do-something-else
do-something-else-again)
You may even repeat the when by if ;-)
--
Lieven Marchand <m...@wyrd.be>
She says, "Honey, you're a Bastard of great proportion."
He says, "Darling, I plead guilty to that sin."
Cowboy Junkies -- A few simple words
Erik Naggum
| You've never been in my kill-file!
My mistake -- I thought had said you did, once. My apologies.
| I guess it was mostly the passive tense "it is advised" phrase that made
| me want to point out that is hardly a universal axiom of IF that more
| than on form in a branch means it should be a COND.
I hope style is not considered "axiomatic" anywhere.
* Erik Naggum
> The lack of an implicit progn in the if form is a hint that cond, which
> has an implicit progn for each branch, would be more appropriately used
> for bodies with side-effects and if for expressions.
| This is a strong argument, though one more from tradition than other
| stylistic concerns.
| I still like the strong visual signal an IF form gives you that there are
| two and only two branches.
That seems like a reasonable rationale, but it appears to me (i.e.,
pretty weak certainy) that most of the uses have one branch with a single
form, like return or error, and the other a larger body of something. I
tend to use one-branch conditionals and know that that branch terminates
the function or asks the operator to fix an error -- sometimes one can
turn an error into a continuable error, then the function should not
simply error out
| Variety is the spice of life, I like very much that lisp provides so many
| ways to express your code.
I second that.
Erik Naggum
| I get the impression that while the language itself will have less
| baked into it, there will be repositories ("huge libraries") of code
| for the user to take advantage of. --Like perl's CPAN.
My impression of the CPAN is that it is a whole bunch of code of very
dubious and uncertain quality, and not at all what I would want to base
anything on in a real project. It is fine for the kinds of things that
Perl is used for. Why anyone would want a piece of that market eludes
me. Perl should reign supreme in that corner and not cause anything else
to be polluted by its mind-set.
Coby Beck
> Coby Beck
> * Erik Naggum
> > The lack of an implicit progn in the if form is a hint that cond, which
> > has an implicit progn for each branch, would be more appropriately used
> > for bodies with side-effects and if for expressions.
>
> | This is a strong argument, though one more from tradition than other
> | stylistic concerns.
>
> | I still like the strong visual signal an IF form gives you that there are
> | two and only two branches.
>
> That seems like a reasonable rationale, but it appears to me (i.e.,
> pretty weak certainy) that most of the uses have one branch with a single
> form, like return or error, and the other a larger body of something.
I think I'll start examining the way I use IF and see if this is not the case,
it sounds likely. I have to admit having extablished some of my usage patterns
based on thinking it ugly to use return-from forms in the middle of functions.
But I can see how doing that together with using WHEN and UNLESS as primarily
error-throwing and return-from code prevents these exit points from hiding.
Actually, now that I think about it, this is exactly the right fix for a real
head-shaker of a function I inherited at one job.
(if (something)
(progn
200+ lines)
(error (couldn't get database handle)))
(nested in another identical if statement, BTW)
That was a real headache to read. Obviously this should have been: (ignoring
the simple improvement of breaking it into smaller functions)
(unless (something) (error ....))
200+ lines
Ed L Cashin
> * Ed L Cashin
> | I get the impression that while the language itself will have less
> | baked into it, there will be repositories ("huge libraries") of code
> | for the user to take advantage of. --Like perl's CPAN.
>
> My impression of the CPAN is that it is a whole bunch of code of very
> dubious and uncertain quality, and not at all what I would want to base
> anything on in a real project. It is fine for the kinds of things that
> Perl is used for. Why anyone would want a piece of that market eludes
> me. Perl should reign supreme in that corner and not cause anything else
> to be polluted by its mind-set.
It is true that you have to examine a module from CPAN for quality
before choosing to make use of it, but I have found that most of the
modules that become popular are stable, usable code.
It can be a real life-saver to find out that someone else has already
done the groundwork -- and done it well -- on a new challenging area.
It can make the difference between saying, "Yes, we can do that," or,
"We will get back to you."
Many languages preach code reuse and modularity, but the CPAN
repository is, as far as I know, the greatest example to date of
modular code sharing.
Alain Picard
>
> Many languages preach code reuse and modularity, but the CPAN
> repository is, as far as I know, the greatest example to date of
> modular code sharing.
I have to second that. In fact, I'd go further and say that CPAN
is the _ONLY_ reason I would consider valid for using Perl.
I guess you can tell from my (now aging) .sig that I once thought
perl was rather cool... I guess we all grow up eventually. :-)
--
It would be difficult to construe Larry Wall, in article
this as a feature. <1995May29....@netlabs.com>
Tim Bradshaw
>
> (loop for v = (> vble 4)
> repeat 1
> when v do
> do-something
> do-something-again
> else do
> do-something-else
> do-something-else-again)
>
Surely (loop WITH v = ...), or even better (loop repeat 1 when (> vble 4) ...)
--tim
Duane Rettig
> Erik Naggum <er...@naggum.net> writes:
> > * cbbr...@acm.org
> > | But I think the latter would cause #Erik's head to explode, so
> > | it's not a terribly serious suggestion :-).
> >
> > Thank you for your concern. :)
> >
> > Note that if* is merely syntactic saccharin for cond. You have
> > all the benefits of if* without either bad style or bad taste if
> > you use cond.
>
> 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.
You can create a macro which expresses your own preference in
programming conditionals.
> The creation of IF* apparently resulted from someone being _massively_
> irritated by this, to the point apparently of desiring to redesign
> chunks of CL.
No, the design and implementation of IF* predates CL by several years.
[Note: I make no judgement for or against IF* here. It has pros and
cons for its usage, just as IF and COND have pros and cons for their
usage. Appropriate use is the key. As a personal style, I use all of
the power of CL, including IF and COND, as well as IF*, and I also use
WHEN and even UNLESS, which I also consider useful constructs (when
appropriate). I would also not be adverse to using a new conditional
macro designed by anyone, one which solved some of the problems which
IF and COND have, as well as IF*'s problems.]
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
Barry Margolin
Duane Rettig <du...@franz.com> wrote:
>cbbr...@acm.org writes:
>> The creation of IF* apparently resulted from someone being _massively_
>> irritated by this, to the point apparently of desiring to redesign
>> chunks of CL.
>
>No, the design and implementation of IF* predates CL by several years.
It should be noted that in the Lisp dialects that preceded CL, there were a
preponderance of different IF macros. The version in PDP-10 Maclisp and
Zetalisp had a single then-clause and an implicit PROGN for the
else-clause, and this survives now in GNU Emacs Lisp. Multics Maclisp
didn't have a built-in IF, but Multics Emacs had a version with 'then' and
'else' keywords (or maybe 'then' was implicit, I don't remember for sure).
For Common Lisp they deliberately chose a minimalist version, I think to
avoid the political issue of picking one form over any other.
--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Martti Halminen
> It should be noted that in the Lisp dialects that preceded CL, there were a
> preponderance of different IF macros. The version in PDP-10 Maclisp and
> Zetalisp had a single then-clause and an implicit PROGN for the
> else-clause, and this survives now in GNU Emacs Lisp. Multics Maclisp
> didn't have a built-in IF, but Multics Emacs had a version with 'then' and
> 'else' keywords (or maybe 'then' was implicit, I don't remember for sure).
This brings to mind the worst IF I ever saw: on the PL/1 -based Emacs in
its Lisp on Prime minicomputers there was an IF where the then -branch
returned a value, and the else -branch didn't (or was it the other
way?). Made programming it a little convoluted.
--