From: ·······@giasdla.vsnl.net.in
Subject: Difference between do & do*
Date:
Message-ID: <7hkc3q$bbf$1@nnrp1.deja.com>
Can anyone please exppain me the difference between Do & DO*
Any type of help would be highly appreciated
Thanx
--
visit me at http://members.tripod.com/~Coolviki
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
·······@giasdla.vsnl.net.in writes:
> Can anyone please exppain me the difference between Do & DO*
It is like the difference between LET and LET*.
Without the *, the binding are done in parallel,which means that they
cannot refer to eachother, but can refer to outside bindings with the
same names.
With the *, the bindings are done in order, so that the second binding
can refer to the first and so on.
Stig Hemmer,
Jack of a Few Trades.
·······@giasdla.vsnl.net.in writes:
> Can anyone please exppain me the difference between Do & DO*
DO* is like LET*. If there is more than one binding, the second binding
can be computed using the value of the first.
DO* is useful in a case like:
(defun foo (list)
(do* ((x list (cdr x))
(item (car x) ; x already has its binding, so we can use it
(car x))) ; successive values of x, starting with second
((null x) 'done)
(print item)))
You could write this with DO by doing:
(defun foo (list)
(do ((x list (cdr x))
(item (car list) ; x is not yet bound, so we use list
(cadr x))) ; x has old value, so next element is cadr
((null x) 'done)
(print item)))
Personally, I NEVER use DO*, though. (Just a personal choice, not a
big religious mission.) Instead, I use the following kind
of idiom if I'm using DO:
(defun foo (list)
(do ((x list (cdr x)))
((null x) 'done)
(let ((item (car x)))
(print item))))
This gets the same effect as DO* (i.e., ITEM is able to get bound based
on the X value) but it doesn't get as messy [to my way of thinking] as
DO* does. I find it just plain hard to read DO*.
Also, DO* is not like DO in one critical sense. LET* has a neat decoding
into a cascade of LETs. There is not an equivalent cascade of DOs into
which DO* can be unfolded. Only the binding part and not the looping
part of DO* is involved in the "*" part.
[I minimally tested the above examples. I hope they work for you, too.
But I'm clumsy with DO*, so don't blame me if it didn't work.]
See the Common Lisp HyperSpec for more info on DO and DO*.
http://www.harlequin.com/education/books/HyperSpec/FrontMatter/
On Sat, 15 May 1999 18:22:29 GMT, Kent M Pitman <······@world.std.com> posted:
>Also, DO* is not like DO in one critical sense. LET* has a neat decoding
>into a cascade of LETs. There is not an equivalent cascade of DOs into
>which DO* can be unfolded. Only the binding part and not the looping
>part of DO* is involved in the "*" part.
Wouldn't a DO* be "cascadable" into a DO along with a cascade of LETs?
Graham describes DO as essentially defining a LET environment where updates
are done using SETQ, and DO* as one that is analagous, except that it uses
LET* and PSETQ...
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/lsf.html>
········@hex.net - "What have you contributed to free software today?..."
········@news.brownes.org (Christopher B. Browne) writes:
> >Also, DO* is not like DO in one critical sense. LET* has a neat decoding
> >into a cascade of LETs. There is not an equivalent cascade of DOs into
> >which DO* can be unfolded. Only the binding part and not the looping
> >part of DO* is involved in the "*" part.
>
> Wouldn't a DO* be "cascadable" into a DO along with a cascade of LETs?
>
> Graham describes DO as essentially defining a LET environment where updates
> are done using SETQ, and DO* as one that is analagous, except that it uses
> LET* and PSETQ...
Yes, this was the meaning of my last sentence you quoted above. I admit I
might have been a bit cryptic. But LET/LET* is the "binding part" and
the tagbody/go/block/return part is the "looping part". The * is about
the binding part, not about the operator itself. But in LET/LET*, the
binding part is the whole form, while in DO/DO*, the binding part is only
part of the full package. If what I'm saying seems to cryptic, don't
worry about it. It's a small point. But such points bug me, so I mentioned
it. Not sure why really... It has no practical value.