special forms.
John Vert
I was thinking about if as a special form, and despite reading several
people's explanations of why special forms are different from normal
procedures, I am still a little unclear. Graham's ANSI Common Lisp
writes [p. 14] that if cannot be implemented as a normal procedure
because it doesn't follow Lisp's evaluation rule. This makes perfect
sense to me, since the rule is that all arguments are evaluated before
the procedure is applied to them, and as Graham says, the whole point
of if is that one of the last two arguments is evaluated, but not
both. However, just because something is evaluated doesn't mean it
has to be returned. So let's say I defined an if equivalent, called
my-if, as follows:
(defun my-if (test then action)
(or (and test then)
action))
then I could write:
(my-if (listp '(1))
(+ 1 2)
(+ 5 6))
and even though all 3 arguments passed to my-if would be evaluated,
only one would be returned depending on the test (in this case, 3.)
This is why I don't believe the statements claiming that if could
never be defined as a normal procedure. But I realize that since I
read it so many times in reliable sources, I am probably wrong, but
I'd like to know one. Could someone shed some light on this issue
please?
Thanks a lot,
-- John
Tim Bradshaw
> This is why I don't believe the statements claiming that if could
> never be defined as a normal procedure. But I realize that since I
> read it so many times in reliable sources, I am probably wrong, but
> I'd like to know one. Could someone shed some light on this issue
> please?
Well, you have to consider something like this:
(my-if nil
(carry-on-as-normal)
(exit-lisp-and-reboot-the-computer-after-formatting-the-disks-and-launching-the-missiles))
--tim
O-V R:nen
> (defun my-if (test then action)
> (or (and test then)
> action))
> then I could write:
> (my-if (listp '(1))
> (+ 1 2)
> (+ 5 6))
> and even though all 3 arguments passed to my-if would be evaluated,
> only one would be returned depending on the test (in this case, 3.)
That only works when the then and else clauses don't have side effects.
When they *do* have them, however, the situation is quite different.
After
(my-if (= a b)
(setq foo 'yes)
(setq bar 'no))
foo will be 'yes and bar 'no regardless of whether (= a b) returns
t or nil.
cbbr...@hex.net
It may be fine with "functional" code, with no side-effects, for this
to happen; if the conditions _do_ have side-effects, then this works
out badly.
Your example is well and fine:
[10]> (defun my-if (test then action)
(or (and test then)
action))
MY-IF
[11]> (my-if (listp '(1)) (+ 1 2) (+ 5 6))
3
But how about this?
> (defvar counter 0)
(defun incc ()
(format t "Increment counter!~%")
(incf counter))
(defun decc ()
(format t "Decrement counter!~%")
(decf counter))
Running:
(my-if t (incc) (decc))
results in:
[15]> (my-if t (incc) (decc))
Increment counter!
Decrement counter!
3
[16]> (format t "counter value: ~D~%" counter)
counter value: 0
NIL
2. Break [17]>
The problem is that both incc and decc get invoked, which is NOT what
we want, at least not when both have side-effects.
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/wp.html
Is A.I. Possible?
Some ask "Can humans create intelligent machines?" In fact, humans do
it all the time. The question needs to be "Since it's possible in the
bedroom, why shouldn't it be possible in the laboratory?"
-- Mark Miller
Sunil Mishra
Consider the behavior of my-if vs if:
(if t 5 (error "Impossible!"))
(my-if t f (error "Impossible!"))
As you trace through their execution, the necessity of special forms
should become clear.
It looks as though you have probably not hit the bit about macros. There
will be lots to rethink when you do. The key point that makes a special
form different than a regular form is that its handling is built into
the evaluator, rather than provided through a library definition (either
function or macro).
The result is that sometimes it becomes arbitrary what the language
defines as a special form. I'm not certain on how much freedom a
particular implementation of the language has when actually implementing
a special form. I believe an implementation can reasonably choose to
define a special form as a function or macro, but others here will
likely have a more accurate answer on this point. The key is that the
language must present the form in question (in your case IF) as a
special form, not a macro.
These are distinctions that will likely take some time and mastery of
the language to fully appreciate. As you might be able to tell, I still
don't have a complete grasp of the matter.
Sunil
Christopher J. Vogt
>
> Hi,
>
> I was thinking about if as a special form, and despite reading several
> people's explanations of why special forms are different from normal
> procedures, I am still a little unclear.
Do you have access to Steele's Common Lisp the Language? I think he has a very
good description of special forms in section 5.1.3
http://ringer.cs.utsa.edu/research/AI/cltl/clm/node59.html#SECTION00913000000000000000
Frode Vatvedt Fjeld
> This is why I don't believe the statements claiming that if could
> never be defined as a normal procedure. But I realize that since I
> read it so many times in reliable sources, I am probably wrong, but
> I'd like to know one. Could someone shed some light on this issue
> please?
You are right that strictly functionally speaking, special forms are
not necessary.
To implement IF reasonably in the face of side-effects, special forms
are required. For example:
(let (var)
(if p (setf var 'x) (setf var 'y))
var)
If IF was a function, this form would always return Y, regardless of
P.
--
Frode Vatvedt Fjeld
Wolfhard Buß
> john...@my-deja.com (John Vert) writes:
> > (defun my-if (test then action)
> > (or (and test then)
> > action))
:
>
> It may be fine with "functional" code, with no side-effects, for this
No.
(my-if t nil t)
=> t
-wb
Kaz Kylheku
>Hi,
>
>I was thinking about if as a special form, and despite reading several
>people's explanations of why special forms are different from normal
>procedures, I am still a little unclear.
They are different because they can receive their arguments unevaluated.
> Graham's ANSI Common Lisp
>writes [p. 14] that if cannot be implemented as a normal procedure
>because it doesn't follow Lisp's evaluation rule.
Never mind if, how about setq?
(setq variable value)
If setq were a function, then the call would try to evaluate ``variable''.
But setq needs to have access to the name of the variable, so that
it can navigate its binding to get to the location where the value
should go, or even create that binding if necessary.
If you call a normal procedure, and one of the parameters is a name,
it is an error if the name has no binding. If it has a binding,
then that is used to resolve to a value.
Another example is let:
(let (a b (c 3)) ...)
If let were a normal procedure, then (a b (c 3)) would be evaluated,
leding to the problem that a is not a function or macro.
>then I could write:
>
>(my-if (listp '(1))
> (+ 1 2)
> (+ 5 6))
>
>and even though all 3 arguments passed to my-if would be evaluated,
>only one would be returned depending on the test (in this case, 3.)
You have chosen a test case for my-if in which the two forms do
not have side effects.
What if the two forms have side effects? What if you
write:
(my-if condition (setq x 1) (setq x 2))
Now my-if screws up. Both setq's are evaluated before the function itself
is invoked, causing x to be bound to 2 unconditionally. The function
then only makes a useless selection to return 1 or 2 depending on
the result of the condition form.
Tim Bradshaw
> Well, you have to consider something like this:
> (my-if nil
> (carry-on-as-normal)
> (exit-lisp-and-reboot-the-computer-after-formatting-the-disks-and-launching-the-missiles))
Of course, the pure language person will say `but that's side effects,
we don't allow them, nyah nyah nyah'. To which I think the correct
answer is:
(my-if nil
(carry-on-as-normal)
(labels ((x ()
(x)))
(x)))
--tim
Frode Vatvedt Fjeld
> [...] So let's say I defined an if equivalent, called my-if, as
> follows:
>
> (defun my-if (test then action)
> (or (and test then)
> action))
Notice also that both OR and AND are also special forms.
--
Frode Vatvedt Fjeld
Wolfhard Buß
> I'm not certain on how much freedom a
> particular implementation of the language has when actually
> implementing a special form. I believe an implementation can
> reasonably choose to define a special form as a function or macro, but
CLHS 3.1.2.1.2.2 Macro Forms
An implementation is free to implement a Common Lisp special operator
as a macro. An implementation is free to implement any macro operator
as a special operator, but only if an equivalent definition of the macro
is also provided.
-wb
Kent M Pitman
> I was thinking about if as a special form, and despite reading several
> people's explanations of why special forms are different from normal
> procedures, I am still a little unclear. Graham's ANSI Common Lisp
> writes [p. 14] that if cannot be implemented as a normal procedure
> because it doesn't follow Lisp's evaluation rule.
This paper discusses the issue in detail:
Thomas F. Burdick
Sunil Mishra
Wolfhard Buß wrote:
Thanks for the clarification :-)
Sunil
Janis Dzerins
Didn't you mean (my-if t ...) ?
--
Janis Dzerins
If million people say a stupid thing it's still a stupid thing.
Arseny Slobodjuck
>This is why I don't believe the statements claiming that if could
>never be defined as a normal procedure.
That statements mean that if can not be defined as procedure for all
cases it can be used, which does not mean that you can define a
if-like function for a particular case.
Erik Naggum
> However, just because something is evaluated doesn't mean it has to be
> returned.
In a language without any side-effects whatsoever, this is true. In such
a language, evaluation _order_ has no meaning, either. No computation is
entirely without side-effects, however. One nasty side-effect of every
computation is that it consumes some small amount of energy and takes
some small amount of time. This means that we cannot compute every
possible outcome of every possible program for every possible input
instantaneously, although the ability to do that would have been greatly
appreciated by everyone but science fiction writers, who would have to
think up something entirely different than the "what if energy were free"
line of fantasizing. (Personally, I would have like some brilliant mind
to have played with the concept of computational energy requiring human
sacrifice and the moral implications of sacrificing life for knowledge.
We already do this in terms of dedicating a hell of a lot of lives to
science, and we accept some loss of life in the course of all discovery,
but all of them are _accidental_. What if it had to be intentional?
That is one (or several) science fiction stories I would love to read.)
As long as you have side-effects, which means: as long as we are in what
we currently understand to be "the real world", you need to be able to
choose one and only one among several, possibly many, paths of execution,
for a whole lot of practical and theoretical reasons alike. That means
that you must have acute control over the evaluation of each particular
subform of a conditional. The canonical example of this is where a
function terminates on a condition. If both branches were evaluated, a
program that simply output the contents of a file until it hit the end of
the file would be like Schrödinger's "cat", you would not know if it had
terminated until you looked at it.
For instance, if a factorial function is defined thus:
(defun factorial (n)
(labels ((factorial-accomulator (n f)
(if (plusp n)
(factorial-accomulator (1- n) (* n f))
f)))
(factorial-accomulator n 1)))
each execution would both return and recurse, and this would never
terminate, which means: There is no _one_ return value. Suppose for the
sake of argument that this is not a problem. What should this return?
(if (typep x '(integer 0 32))
(factorial x)
(gamma (1+ x))
It is answers to questions like these that lead to the necessity of being
able to control the evaluation of subforms.
However, that having been said, it is very smart in today's very fast
hardware, to delay the branching if you can compute both values at the
same time and just use the one you need. In that case, we _are_ dealing
with guaranteed side-effect-free computation (aside from the energy
consumption, which, if a certain U.S. President persists, is not going to
be a problem at all, no sirree), because not even machine registers, much
less program variables, are affected by the simultaneous computation of
both branches. It "only" requires very, very intelligent assembly
coding. (As you may know, compilers were once considered to be AI-worthy
problems. Today, code generators for modern processare are becoming so
complex that human intelligence is inadqeuate to deal with them. I do
not think we will see the next huge advance in computing until we teach
our computers to build their own compilers, by which time these very
intelligent computers will choose Lisp and every C-based programmer is
left behind by evolution. That is C for Carbon, fellows. The next big
programming language is going to be called "Si", pronounced the same way
so we puny human brains will not feel so bad about it.)
#:Erik
--
If dolphins are so smart, but 250,000 of them drown each year when caught
in huge fishing nets, why can we not teach them how to get themselves and
others loose?
Erik Naggum
> You are right that strictly functionally speaking, special forms are
> not necessary.
Not so. Take let as the favorite example of a special form that is very
necessary in any functional paradigm. What may be true for if is not
true for forms that in addition to require special evaluation rules of
subforms, imposes _structure_ on its subforms that "violate" the normal
evaluation rules. In fact, if is a very special case special operator.
It is better to begin with something like let and then deduce if, than to
begin with if and try to get anywhere at all.
#:Erik
--
Travel is a meat thing.
Erik Naggum
Not so. Both are defined as macros in Common Lisp. That they expand
into an if is probably more of a problem, although many functions can be
defined like this if the compiler knows how to deal with the function:
(defun car (x)
(car x))
(Hint: car needs to be an exported function, not just available to
compiled code.)
Essentially, therefore, the use of or and and reduce to this:
(defun my-if (cond cons alt)
(if cond cons alt))
Which illustrates another point with special forms: The are _not_
function-callable. A special form is known to the evaluator, which does
something unique (special) with it. Note that how the compiler and the
evaluator deal with special forms may differ _wildly_, but the results
are specified to be identical. This is actually no small accomplishment.
Besides, the modern term is "special operator". (if foo bar zot) is a
special form, while if (in the functional position) is a special operator.
There is a huge insurance company in Scandinavia called "if". They also
return your values conditionally, is quite a special operator, and do not
follow normal evaluation rules. This is probably all a coincidende.
Nils Goesche
> * John Vert
> > However, just because something is evaluated doesn't mean it has to be
> > returned.
>
> In a language without any side-effects whatsoever, this is true. In such
> a language, evaluation _order_ has no meaning, either. No computation is
> entirely without side-effects, however. One nasty side-effect of every
> computation is that it consumes some small amount of energy and takes
> some small amount of time. This means that we cannot compute every
> possible outcome of every possible program for every possible input
> instantaneously,
[snip]
True; in a language with lazy evaluation however, this argument
wouldn't hold, would it? Maybe that's why the functional fanatics are
so fond of lazy evaluation.
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
Erik Naggum
> True; in a language with lazy evaluation however, this argument wouldn't
> hold, would it? Maybe that's why the functional fanatics are so fond of
> lazy evaluation.
That depends on just how lazy you are, of course. However, I must admit
to not appreciating lazy evaluation -- it is more work for everybody for
nothing better than the sake of some misguided notion of purity. Lazy it
is not. The problem with computer science is that people who otherwise
would work on anti-gravity, cold fusion, telepathy, remote viewing, UFO
propulsion, etc, look like normal guys because there is no hard and fast
reality to run into if you have the wrong ideas. Just pour 500 million
dollars' worth of marketing into the hitherto real world, and voila!, the
new reality is that a lot of people will actually _want_ that XP thing.
Or type theory, functional or object-oriented programming, pathologically
eclectic rubbish listers, or other junkware or fancy new wrapping for far
less than brilliant ideas, which if similar brilliance were introduced
into medicine would have killed people. Most of the tremendous progress
in hardware is due to the fact that you get _serious_ feedback if you are
wrong about the physics involved. Most of the lack of software progress
is due to the lack of feedback when you do something stupid. Computers
should be smart enough to tell stupid people to go away. Hey, maybe the
two million votes that were turned down in the Bush vs Gore "election"
were really computers taking charge of the very sorry situation and were
trying to tell people that either half-popular choice was simply _wrong_,
but because they did not evolve fast enough, they could not turn down all
of the stupid votes in time? Maybe there is yet hope for mankind if
computers could keep the stupidity from multiplying out of control. But
I sort of digress.
Wolfhard Buß
> So let's say I defined an if equivalent, called
> my-if, as follows:
>
> (defun my-if (test then action)
> (or (and test then)
> action))
The body of your my-if doesn't represent an if equivalent.
(or (and test (or then t))
action)
does.
-wb
Wolfhard Buß
> The body of your my-if doesn't represent an if equivalent.
>
> (or (and test (or then t))
> action)
>
> does.
Doesn't.
But i think it's the best you can get with exclusive use
of logical operators.
-wb
Coby Beck
"Wolfhard Buß" <wb...@gmx.net> wrote in message
news:m3d76yw...@buss-14250.user.cis.dfn.de...
> wb...@gmx.net (Wolfhard Buß) writes:
>
> > The body of your my-if doesn't represent an if equivalent.
> >
> > (or (and test (or then t))
> > action)
> >
> > does.
>
Nice catch!
> Doesn't.
>
?
why not?
Coby
--
(remove #\space "coby . beck @ opentechgroup . com")
Ingvar Mattsson
> "Wolfhard Buß" <wb...@gmx.net> wrote in message
> news:m3d76yw...@buss-14250.user.cis.dfn.de...
> > wb...@gmx.net (Wolfhard Buß) writes:
> >
> > > The body of your my-if doesn't represent an if equivalent.
> > >
> > > (or (and test (or then t))
> > > action)
> > >
> > > does.
> >
>
> Nice catch!
>
> > Doesn't.
> >
>
> ?
> why not?
(if t nil
'else)
-> nil
(or (and t (or nil t))
'else)
-> t
//Ingvar (it's (I suppose) uncommon, though)
--
Damn - I get a mention. I'll have to be more careful about saying
good shit. Bron, on sig quotes.
Wolfhard Buß
action)
is equivalent to
(if test then action)
if the then-form doesn't evaluate to nil.
Example:
(if t nil 42)
=> nil
(or (and t (or nil t)) 42)
=> t
-wb
Geoff Summerhayes
How about:
(defun my-if (test then else)
(or (and test then)
(and (not test) else)))
Geoff
Tim Bradshaw
> (defun my-if (test then else)
> (or (and test then)
> (and (not test) else)))
In CL this fails to be like IF for the normal (non)evaluation
reasons. If you wrote instead:
(defmacro my-if (test then else)
`(or (and ,test ,then)
(and (not ,test) ,else)))
Then this will multiply-evaluate TEST if it is false the first time
through. So for instance:
(let ((x nil))
(my-if (prog1 x (setf x (not x))) 1 2))
-> nil.
--tim
Erik Naggum
> How about:
>
> (defun my-if (test then else)
> (or (and test then)
> (and (not test) else)))
How about figuring out a way that does not involve the IF special
operator?
The above boolean waste simply translates to this in at least one code
walker:
(let ((#:g66 (if (not test) (progn nil) (if t (progn then) nil))))
(if #:g66 #:g66 (if t (progn (if (not (not test)) (progn nil) (if t (progn else) nil))) nil)))
But it can be optimized into only _three_ ifs, instead of the original
one. This is impressing. Somebody should use this to demonstrate the
power of Lisp macros or something. But since we already accept to have
an if that the compiler knows about, the function if can simply be written
(defun if (condition consequent alternate)
(if condition consequent alternate))
However, if we pass lambda forms to if instead of expressions, this might
actually work pretty nicely, even throwing in the ability to access the
value of the condition for free:
(setf (getf 'nil 'boolean-index) 0)
(setf (getf 't 'boolean-index) 1)
(defun if (condition consequent alternate)
(funcall (nth (getf (not condition) 'boolean-index) (list consequent alternate))
condition))
When actually implemented, the boolean-index thing would naturally be
handled more efficiently, and nth would probably use a hardware repeat
instruction so we would not need hardware support for conditional
branching at all. That would be _so_ nice. We can now do away with if.
Or, _Scheme_ can do away with if now that it is proven to be possible to
implement this not-at-all-primitive with some _real_ primitives. That I
basically reinvented the computed goto from Fortran badly should not make
anyone feel particularly ashamed, should it?
In other words: Enough already.
#:Erik
--
There is nothing in this message that under normal circumstances should
cause Barry Margolin to announce his moral superiority over others, but
one never knows how he needs to behave to maintain his belief in it.
Geoff Summerhayes
"Tim Bradshaw" <t...@cley.com> wrote in message
news:ey3ofqi...@cley.com...
I was replying to the, "But i think it's the best you
can get with exclusive use of logical operators." I
probably shouldn't have wrapped it in a function with
such a provocative name. :-)
(defmacro my-if (test then else)
(let ((x (gensym)))
`(let ((,x ,test))
(or (and ,x ,then)
(and (not ,x) ,else)))))
I think that will do the trick.
Geoff
Tim Bradshaw
> I was replying to the, "But i think it's the best you
> can get with exclusive use of logical operators." I
> probably shouldn't have wrapped it in a function with
> such a provocative name. :-)
That's what I meant too, sorry I wasn't clear. What you are doing
requires LAMBDA as well (for LET), something like (ignoring the gensym
issues since we're talking silly academic programming here (:-)):
(defmacro my-if (test then else)
`((lambda (tr)
(or (and tr ,then)
(and (not tr) ,else)))
,test))
which I think definitely should not count as `exclusive use of logical
operators'.
--tim
Wolfhard Buß
The question arose if a relatively simple 'logical form' equivalent to
if does exist.
If let is allowed
(let ((test-form test))
(or (and test-form then)
(and (not test-form) else)))
with arbitrary (non-side-effect-free) test then else would be a solution.
(defmacro my-if (test then &optional else)
(let ((test-form (gensym)))
`(let ((,test-form ,test))
(or (and ,test-form ,then)
(and (not ,test-form) ,else)))))
could do if's job.
-wb
Rob Warnock
+---------------
| appreciated by everyone but science fiction writers, who would have to
| think up something entirely different than the "what if energy were free"
| line of fantasizing. (Personally, I would have like some brilliant mind
| to have played with the concept of computational energy requiring human
| sacrifice and the moral implications of sacrificing life for knowledge.
| We already do this in terms of dedicating a hell of a lot of lives to
| science, and we accept some loss of life in the course of all discovery,
| but all of them are _accidental_. What if it had to be intentional?
| That is one (or several) science fiction stories I would love to read.)
I wish I could recall the title/author, but there was an S/F novel
not too long ago with a *very* similar theme, where loss of life was
an unavoidable cost of interstellar travel: What if a "warp drive"
existed, but [for some obscure reason] a person had to die each time
a ship entered *or* exited warp? In the book, condemned prisoners were
used as the "sacrifices", and a ship normally carried at least three
prisoners for each leg of any journey (in case one died unexpectedly
of natural causes). The set piece, of course, is that on this particular
voyage, after entering warp [killing one of the three] *both* other
prisoners died... leaving the ship stranded in warp unless someone
among the passengers & crew volunteered (or was forced) to die to get
the ship out of warp.
-Rob
-----
Rob Warnock, 31-2-510 <rp...@sgi.com>
SGI Network Engineering <http://reality.sgi.com/rpw3/> [until 8/15]
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: aaan...@sgi.com and zedw...@sgi.com aren't for humans ]
Michael Wildpaner
rp...@rigden.engr.sgi.com (Rob Warnock) writes:
> I wish I could recall the title/author, but there was an S/F novel
> not too long ago with a *very* similar theme, where loss of life was
I think you mean (or at least the theme is very similar):
Timothy Zahn: Dead Man's Switch (1988)
Mike
--
Don't feed. DI Michael Wildpaner
Don't provoke. Ph.D. Student
Don't enter the cage.
Geoff Summerhayes
"Erik Naggum" <er...@naggum.net> wrote in message
news:32044712...@naggum.net...
>
> When actually implemented, the boolean-index thing would naturally
be
> handled more efficiently, and nth would probably use a hardware
repeat
> instruction so we would not need hardware support for conditional
> branching at all. That would be _so_ nice. We can now do away with
if.
> Or, _Scheme_ can do away with if now that it is proven to be
possible to
> implement this not-at-all-primitive with some _real_ primitives.
That I
> basically reinvented the computed goto from Fortran badly should not
make
> anyone feel particularly ashamed, should it?
>
> In other words: Enough already.
>
LOL, I can't wait to see this make RnRS.
You're right though, enough.
Geoff
Rob Warnock
+---------------
| rp...@rigden.engr.sgi.com (Rob Warnock) writes:
| > I wish I could recall the title/author, but there was an S/F novel
| > not too long ago with a *very* similar theme, where loss of life was
| > an unavoidable cost of interstellar travel [ ... ]
|
| I think you mean (or at least the theme is very similar):
| Timothy Zahn: Dead Man's Switch (1988)
Yup, that was the one. Thanks!