>>>>"EN" == Erik Naggum schrieb am 06 Feb 2001 22:58:33 +0000:
EN> Common Lisp has loop, a very general iteration macro. "while"
EN> is no more than a termination condition for iteration, but is
EN> frequently made into a separate language construct in less
EN> general-minded languages. (I think this is a serious design
EN> mistake in those languages because it means that you can only put
EN> the termination condition in one place.)
I can't see the serious design mistake in having "while". If you are
talking about having "while" *as the only iteration construction*, I
agree, but are there any such languages (I guess most have at least a
corresponding "unless", no?)?
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"Gross die Macht von Forth ist. Die Reihenfolge der
Worte sie verdreht Dir."
-- Kristian Koehntopp in de.comp.os.unix.linux.misc
>>>>"EN" == Erik Naggum schrieb am 07 Feb 2001 10:34:17 +0000:
EN> Huh? The serious design mistake is not in _having_ "while" or
EN> not, it is in making "while" a separate language construct.
EN> Common Lisp _has_ while, the right way: as a termination
EN> condition in a general iterator construct.
Okay, I can see now more clearly what you're after.
EN> This is a plea to those who think that whipping up a "while"
EN> macro is a good idea: Don't. Just learn to write (loop while
EN> ... do ...), instead. It's the Common Lisp way, and you don't
EN> need to write a new macro to do things like (loop do ... while
EN> ... do ...), or special magic to collect values, etc.
What's the difference between "while" and the more familiar
do ({var | (var [init-form [step-form]])}*)
(end-test-form result-form*)
declaration* {tag | statement}*
or would you discourage the use of do and friends as well?
EN> A separate "while" construct is simpler than possible [...]
Rest agreed with.
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"Gross die Macht von Forth ist. Die Reihenfolge der
Worte sie verdreht Dir."
-- Kristian Koehntopp in de.comp.os.unix.linux.misc
>>>>"EN" == Erik Naggum schrieb am 07 Feb 2001 13:49:56 +0000:
>> What's the difference between "while" and the more familiar do or
>> would you discourage the use of do and friends as well?
EN> I fail to see why do is more familiar than loop. (I do know
EN> it, so you don't have to write out the whole syntax for it.
I wrote it out specificially to make the "familiar" more clear.
Obviously I failed. I was thinking of the language convert from
languages which do have a "while", while in CL it's closest cousin is
"do".
EN> Unless you're really writing in C or Pascal and need the IF, THEN
EN> and ELSE keywords along with BEGIN and END instead of ( and ), I
EN> guess, it may therefore make sense to start out with cond in
EN> cases where you expect changes.
Yes, that's a very interesting point. Perhaps there should be some
transfer-if-to-cond-function in Ilisp?
Only half joking,
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"Gross die Macht von Forth ist. Die Reihenfolge der
Worte sie verdreht Dir."
-- Kristian Koehntopp in de.comp.os.unix.linux.misc
Holger Schauer <··············@gmx.de> writes:
> Yes, that's a very interesting point. Perhaps there should be some
> transfer-if-to-cond-function in Ilisp?
I believe that Zmacs had a function (`twiddle-conditional' or something
like that) that would syntactically rewrite ifs to conds and vice
versa. I don't know how this got missed in gnu emacs.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
In article <············@content-integrity.com>, Joe Marshall
<···@content-integrity.com> wrote:
> Holger Schauer <··············@gmx.de> writes:
>
> > Yes, that's a very interesting point. Perhaps there should be some
> > transfer-if-to-cond-function in Ilisp?
>
> I believe that Zmacs had a function (`twiddle-conditional' or something
> like that) that would syntactically rewrite ifs to conds and vice
> versa.
In Zmacs
control-meta-& Frob Lisp Conditional
changes CONDS to ANDs, ORs, IFs, WHENs, or UNLESS's
and vice versa.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Holger Schauer <··············@gmx.de> writes:
> I can't see the serious design mistake in having "while". If you are
> talking about having "while" *as the only iteration construction*, I
> agree, but are there any such languages (I guess most have at least a
> corresponding "unless", no?)?
Eiffel prides itself on being a RISC-language, and one of the ways
this shows is in having only one looping construct, which is more or
less a while with some preinitialization, e.g.
combsort(direction : INTEGER) is
-- CombSort is a modified BubbleSort which is quite fast for
-- its simplicity. See Byte 4/90 for a detailed description
require
direction = Ascending or direction = Descending
local
i,j,gap:INTEGER
swapped:BOOLEAN
do
if count > 0 then
from
gap:=upper-lower
swapped:=TRUE
until
gap = 1 and not swapped
loop
-- Shrink Gap by the "magic" factor of 1.3
gap:=(gap.to_real/1.3).floor
-- We normalize the gap
if gap<1 then
gap:=1
elseif gap=9 or gap = 10 then
-- Gaps of size 9 or 10 are "evil", so we use 11 instead
gap:=11
end
-- This is in essence a simple BubbleSort but using gap
swapped:=FALSE
from
i:=lower
variant
upper - i
until
i+gap > upper
loop
j:=i+gap
-- This is really just a comparison, but since
-- Eiffel doesn't have function parameters we do it
-- this way.
if item(i).key.compare(item(j).key)*direction < 0 then
swap(i,j)
swapped:=true
end
i:=i+1
end
end
end
ensure
-- This is inefficient, but makes us safer, so it's good (TM)
is_sorted(direction)
end
Suffice it to say that I was less than impressed with this construct...
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
From: Valeriy E. Ushakov
Subject: Re: Is there a "while " stetement in LISP?
Date:
Message-ID: <95rkc6$htm$2@news.spbu.ru>
Pierre R. Mai <····@acm.org> wrote:
> Eiffel prides itself on being a RISC-language, and one of the ways
> this shows is in having only one looping construct, which is more or
> less a while with some preinitialization, e.g.
[...]
> Suffice it to say that I was less than impressed with this construct...
OOSC2 elaborates on rationale for giving you only this particular
choice of syntax (that emphasizes loop invarinats).
But as Kent once said: "The world needs to be about choices." ...
SY, Uwe
--
···@ptc.spbu.ru | Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/ | Ist zu Grunde gehen
In article <············@news.spbu.ru>,
"Valeriy E. Ushakov" <···@ptc.spbu.ru> wrote:
> Pierre R. Mai <····@acm.org> wrote:
>
> > Eiffel prides itself on being a RISC-language, and one of the ways
> > this shows is in having only one looping construct, which is more or
> > less a while with some preinitialization, e.g.
> [...]
> > Suffice it to say that I was less than impressed with this
construct...
>
> OOSC2 elaborates on rationale for giving you only this particular
> choice of syntax (that emphasizes loop invarinats).
>
> But as Kent once said: "The world needs to be about choices." ...
"The Customer Can Have Any Color He Wants So Long As It's Black".
-- Henry Ford
Seriously, every programming language is a set of tradeoffs. So Eiffel
has only one loop construct. On the other hand, it supports invariant
and variant assertions as part of the construct. You lose a little
flexibility and gain ways of making the program safer.
Greg
--
http://homestead.deja.com/user.gmc333/index.html
Sent via Deja.com
http://www.deja.com/
Greg <······@my-deja.com> writes:
> In article <············@news.spbu.ru>,
> "Valeriy E. Ushakov" <···@ptc.spbu.ru> wrote:
> > [...]
> > But as Kent once said: "The world needs to be about choices." ...
Yep. :-)
> "The Customer Can Have Any Color He Wants So Long As It's Black".
> -- Henry Ford
>
> Seriously, every programming language is a set of tradeoffs. So Eiffel
> has only one loop construct. On the other hand, it supports invariant
> and variant assertions as part of the construct. You lose a little
> flexibility and gain ways of making the program safer.
There's a serious problem in your language if you believe the question of
whether there should be a "while" statement is a semantic one, rather than
a syntactic one.
If Eiffel's loop construct is not adequately powerful that the change from
a while statement to whatever it has is not purely syntactic, then it's got
problems because it is not allowing the user to express a concept that is
completely natural in a way that matches that natural concept.
If Eiffel's loop construct is merely a syntactic transformation away, then
the issue of the program being "safer" is a red herring unless you believe
that program safety is a "syntactic" rather than "semantic" concept.
In fact, I'd be open to a claim that safety does have a syntactic component,
in that I think it's safer to express things in ways that people can look
at and understand directly (I call this "expressing an idea") rather than
in ways that the user has to think about to prove correctness (I call
this "implementing an idea"). However, if you follow this line of thinking,
you'll realize that it only means that even if you can make a syntactic-only
transformation between "while" and whatever you actually have in your
language, the language is less safe unless it provides "while" primitively
since it forces someone to implement what s/he would prefer to express.
So maybe you don't want to go down that road... :-)
"Pierre R. Mai" <····@acm.org> writes:
> Eiffel prides itself on being a RISC-language, and one of the ways
> this shows is in having only one looping construct, which is more or
> less a while with some preinitialization, e.g.
>
> Suffice it to say that I was less than impressed with this construct...
The inclusion of variant and invariant clauses is a nice idea.
--
Lieven Marchand <···@wyrd.be>
Gla�r ok reifr skyli gumna hverr, unz sinn b��r bana.
Lieven Marchand <···@wyrd.be> writes:
> "Pierre R. Mai" <····@acm.org> writes:
>
> > Eiffel prides itself on being a RISC-language, and one of the ways
> > this shows is in having only one looping construct, which is more or
> > less a while with some preinitialization, e.g.
> >
> > Suffice it to say that I was less than impressed with this construct...
>
> The inclusion of variant and invariant clauses is a nice idea.
Oh it is a nice idea, just like all of the DBC-constructs are a nice
idea. It's just that when you go off and build a whole language
around a nice idea, invariably you end up with a toy language,
IMNSHO.
Languages aren't built around a couple of nice ideas, they are built
around a couple of underlying conceptual frameworks, _plus_ all of the
years of experience and feed-back that make all of that into a
cohesive whole.
In a way Eiffel is actually very consistent here: Since the only
looping construct is so restrictive, that you'll have to contort your
code to fit the construct[1], you'll learn quickly to write your
variants, in order to catch the zillion of errors you introduce in
your contorted code (I've probably written more non-terminating loops
in Eiffel in a couple of months than I'm going to write in my whole
life). Those who think in terms of features when it comes to
languages, will probably count this as a success-story for DBC.
Regs, Pierre.
Footnotes:
[1] Made all the more problematic by the complete lack of syntactic
abstraction capabilities.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
"Pierre R. Mai" <····@acm.org> writes:
> Lieven Marchand <···@wyrd.be> writes:
>
> > "Pierre R. Mai" <····@acm.org> writes:
> >
> > > Eiffel prides itself on being a RISC-language, and one of the ways
> > > this shows is in having only one looping construct, which is more or
> > > less a while with some preinitialization, e.g.
> > >
> > > Suffice it to say that I was less than impressed with this construct...
> >
> > The inclusion of variant and invariant clauses is a nice idea.
>
> Oh it is a nice idea, just like all of the DBC-constructs are a nice
> idea. It's just that when you go off and build a whole language
> around a nice idea, invariably you end up with a toy language,
> IMNSHO.
>
There seem to be a whole bunch of languages that have something
against choices.
> Languages aren't built around a couple of nice ideas, they are built
> around a couple of underlying conceptual frameworks, _plus_ all of the
> years of experience and feed-back that make all of that into a
> cohesive whole.
>
> In a way Eiffel is actually very consistent here: Since the only
> looping construct is so restrictive, that you'll have to contort your
> code to fit the construct[1], you'll learn quickly to write your
> variants, in order to catch the zillion of errors you introduce in
> your contorted code (I've probably written more non-terminating loops
> in Eiffel in a couple of months than I'm going to write in my whole
> life). Those who think in terms of features when it comes to
> languages, will probably count this as a success-story for DBC.
>
I've only read OOSC 2. I've never written Eiffel for real use. I was
wondering about how useful variants/invariants where in real use. OOSC
is a very weird book; it has features of a religious book written by a
prophet who has seen the light. His insistence that every feature of
Eiffel is the only good way to do something is amazing, especially
given some really awful kludges he has to explain away.
--
Lieven Marchand <···@wyrd.be>
Gla�r ok reifr skyli gumna hverr, unz sinn b��r bana.
Lieven Marchand <···@wyrd.be> writes:
> There seem to be a whole bunch of languages that have something
> against choices.
If you are designing a language that is going to be used by people
dumber than you are, you can depend on them making poor choices (or at
least making choices poorer than you make), so you restrict their
options to the good choices.
This is a good way to design languages if
a) Everyone is in fact dumber than you.
b) Nevertheless, you think these morons ought to be writing
programs.
c) It is the case that after making all the choices necessary to
envision and design a program, these people suddenly become
incapable of rendering their design to a formal description.
d) You know beforehand every application that might be programmed in
your language.
If these aren't all true, perhaps a language with *more* choices would
be better.
The funny thing is that condition a may be true (as a first-order
approximation) for a lot of people who read comp.lang.lisp
The sad thing is that condition c *is* true for a large number of
people who consider themselves to be programmers.
The scary thing is the tacit acceptance of condition b by people who
use the products developed by people who satisfy condition c.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
From: Tim Bradshaw
Subject: Re: Is there a "while " stetement in LISP?
Date:
Message-ID: <ey3zofu2861.fsf@cley.com>
* Lieven Marchand wrote:
> "Pierre R. Mai" <····@acm.org> writes:
> There seem to be a whole bunch of languages that have something
> against choices.
>> Languages aren't built around a couple of nice ideas, they are built
>> around a couple of underlying conceptual frameworks, _plus_ all of the
>> years of experience and feed-back that make all of that into a
>> cohesive whole.
I agree with this (both quoted bits), or I'd like to, and I think
I've finally understood what happens.
Languages designed around a nice idea or two are generally really a
pain to use, I think that's fairly clear. (They also attract religious
fanatics who are obsessed with the One True Idea which makes them even
worse: I won't mention language names because these same fanatics have
newsgroup grepping tools (written in perl -- somehow the fanaticism
will allow the use of the ultimate impure language).) Languages in
this category are against choice the way Christianity was against
witchcraft in the middle ages, and for the same reasons.
But there are languages around which are obviously in the `couple of
frameworks plus years of experience' category which are just
horrible. A popular C-derived language springs to mind. These
languages *also* tend to be against choice: how does that work?
The secret is, I think, in the years of experience: experience of
*what*? I think it's experience of bad and indisciplined programmers
working in painful social environments like most development projects.
What you learn from this experience, as a language designer, is to
restrict choice, and to design these rigid, painful languages with
vast frameworks in which people have to write, because it's the only
way to get something done, unless you're willing to take the rather
radical step of changing the way you hire and treat programmers.
--tim
Tim Bradshaw <···@cley.com> writes:
> But there are languages around which are obviously in the `couple of
> frameworks plus years of experience' category which are just
> horrible. A popular C-derived language springs to mind. These
> languages *also* tend to be against choice: how does that work?
If you mean C++ I don't agree with your assessment that it is against
choice. It's horrible enough, but its proponents are publishing whole
books on how to achieve all sort of relatively simple things like
making a class whose objects can only be instantiated from the heap by
(ab)using five or more completely obscure rules.
There's a book by Stroustrup that documents the design of C++. The
pivotal step where C++ went wrong IMHO is where, through his bad
experience with Simula's object implementation, he decided that it
should be possible to have static instances of objects. A surprising
amount of kludges and problems in C++ can be traced to that design
decision. Comparable languages that didn't make that decision like
Java and Modula-3 are far better for it. It shows another weird state
of mind because the obvious reaction to bad performance from one
garbage collection based, 'all objects are references' language should
be to form and investigate the two hypotheses: (1) the implementation
sucked, or (2) the implementation was then state of the art but
perhaps more than 10 years later we have learned how to do better.
--
Lieven Marchand <···@wyrd.be>
Gla�r ok reifr skyli gumna hverr, unz sinn b��r bana.
In article <··············@localhost.localdomain>, Lieven Marchand wrote:
> ...
>of mind because the obvious reaction to bad performance from one
>garbage collection based, 'all objects are references' language should
>be to form and investigate the two hypotheses: (1) the implementation
>sucked, or (2) the implementation was then state of the art but
>perhaps more than 10 years later we have learned how to do better.
imo pascal is a prime example of not realising (2) (obviously, this principle
applies to other thaings than objects as well)
hs
··@paradise.nirvananet (Hartmann Schaffer) writes:
> In article <··············@localhost.localdomain>, Lieven Marchand wrote:
> > ...
> >of mind because the obvious reaction to bad performance from one
> >garbage collection based, 'all objects are references' language should
> >be to form and investigate the two hypotheses: (1) the implementation
> >sucked, or (2) the implementation was then state of the art but
> >perhaps more than 10 years later we have learned how to do better.
>
> imo pascal is a prime example of not realising (2) (obviously, this principle
> applies to other thaings than objects as well)
Especially hacks like forward declarations to allow mutual recursion
because you want a one pass compiler.
--
Lieven Marchand <···@wyrd.be>
Gla�r ok reifr skyli gumna hverr, unz sinn b��r bana.
In article <··············@localhost.localdomain>, Lieven Marchand wrote:
>··@paradise.nirvananet (Hartmann Schaffer) writes:
>
>> In article <··············@localhost.localdomain>, Lieven Marchand wrote:
>> > ...
>> >of mind because the obvious reaction to bad performance from one
>> >garbage collection based, 'all objects are references' language should
>> >be to form and investigate the two hypotheses: (1) the implementation
>> >sucked, or (2) the implementation was then state of the art but
>> >perhaps more than 10 years later we have learned how to do better.
>>
>> imo pascal is a prime example of not realising (2) (obviously, this principle
>> applies to other thaings than objects as well)
>
>Especially hacks like forward declarations to allow mutual recursion
>because you want a one pass compiler.
what irked me most was that for the sake of "efficiency" pascal permitted
declarations only at the top and function level just at the time when algol
implementations that had found an efficient way of blocks at any level began
to appear
hs
In article <················@naggum.net>, Erik Naggum <····@naggum.net> wrote:
>* Erik Naggum
>> Common Lisp has loop, a very general iteration macro. "while" is no more
>> than a termination condition for iteration, but is frequently made into a
>> separate language construct in less general-minded languages. (I think
>> this is a serious design mistake in those languages because it means that
>> you can only put the termination condition in one place.)
>
>* Holger Schauer
>> I can't see the serious design mistake in having "while". If you are
>> talking about having "while" *as the only iteration construction*, I
>> agree, but are there any such languages (I guess most have at least a
>> corresponding "unless", no?)?
>
> Huh? The serious design mistake is not in _having_ "while" or not, it is
> in making "while" a separate language construct. Common Lisp _has_ while,
> the right way: as a termination condition in a general iterator construct.
>
C has a general iterator construct: while (1) { ... } being one way
to write it (or for (;;) { ... }). You can terminate the loop with
"break". This makes it fairly easy to make the loop do what it
should. It isn't as slick as loop in CL, but it isn't bad.
(Naturally, there are people who will teach that this is a Bad
Thing, since it flouts the holy One Entrance/One Exit doctrine.
Ignore them.)
Pascal is a much more awkward language to customize loops in.
You've pretty much got to have a termination variable and use
an if to conditionally execute part of the loop.
If you want to feel really superior over C users, compare cond
and switch.
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
········@visi.com (David Thornley) writes:
> C has a general iterator construct: while (1) { ... } being one way
> to write it (or for (;;) { ... }). You can terminate the loop with
> "break".
Yes. And if you have nested loops and switchs and what else not, the
code may get _very_ unmaintainable. (I just read the paper "Software
Fault Prevention by Language Choice: Why C is Not My Favorite
Language" by Richard Fateman -- it's much like reading "Why Pascal is
Not My Favorite Language" by Brian W. Kernighan)
> (Naturally, there are people who will teach that this is a Bad
> Thing, since it flouts the holy One Entrance/One Exit doctrine.
> Ignore them.)
Why do you advise to ignore other's opinions?
> If you want to feel really superior over C users, compare cond
> and switch.
Common Lisp analog of C's switch is CASE. COND is a whole lot better
than writing lots of ifs and elseifs.
Janis Dzerins
--
If million people say a stupid thing it's still a stupid thing.
Erik Naggum <····@naggum.net> writes:
> > You can terminate the loop with "break".
>
> But you can't name the loop to break. This always annoys me in C. It
> tells me that the language designers don't want me to nest forms like
> for, while, switch, etc, without adding a huge burden.
That's what goto is for!
--
vsync
http://quadium.net/ - last updated Thu Feb 1 03:21:28 PST 2001
(cons (cons (car (cons 'c 'r)) (cdr (cons 'a 'o))) ; Orjner
(cons (cons (car (cons 'n 'c)) (cdr (cons nil 's))) nil))
vsync wrote:
> Erik Naggum <····@naggum.net> writes:
>
>> > You can terminate the loop with "break".
>>
>> But you can't name the loop to break. This always annoys me in C. It
>> tells me that the language designers don't want me to nest forms like
>> for, while, switch, etc, without adding a huge burden.
>
> That's what goto is for!
Goto is for specifiying "where to go" not "where to come from".
There is a difference!
Regards,
Jochen
In article <··············@ID-22205.news.dfncis.de>, Jochen Schmidt
<···@dataheaven.de> wrote:
> vsync wrote:
>
> > Erik Naggum <····@naggum.net> writes:
> >
> >> > You can terminate the loop with "break".
> >>
> >> But you can't name the loop to break. This always annoys me in C.
> >> It
> >> tells me that the language designers don't want me to nest forms
> >> like
> >> for, while, switch, etc, without adding a huge burden.
> >
> > That's what goto is for!
>
> Goto is for specifiying "where to go" not "where to come from".
> There is a difference!
Is this INTERCAL's COMEFROM advocacy or what ?
;-)
But more to the point of "named 'break points'", of course, everyone
has noticed that Java corrected this:
outer:
while(true) {
fetchFirst:
for(int i = 100 ; --i >= 0 ;) {
if (cond1) continue outer ;
if (cond2) break fetchFirst ;
if (cond3) break outer ;
}
if (cond4) break outer ;
}
__|__
--
--
JFB
From: Harald Hanche-Olsen
Subject: Re: Is there a "while " stetement in LISP?
Date:
Message-ID: <pco66ikkgyg.fsf@thoth.home>
+ Erik Naggum <····@naggum.net>:
| Common Lisp _has_ while, the right way: as a termination condition
| in a general iterator construct.
Yikes! I'm glad you told me. For too long I've felt a deep distaste
for the loop macro, which I now understand is caused by what appears
to be a seriously wrong description of it in Paul Graham's "ANSI
Common Lisp." Unless I read the description (in the reference
section) wrong, it says that end conditions, like while, are always
checked at the top, before any of the body forms - no matter in which
order they appear in the code. This seemed horrible to me at the time
I first saw it, and still does. But now, from looking at the
HyperSpec (esp. section 6.1.1.6) and experimenting a bit, I see that
loop does indeed do the right thing after all, allowing you to
naturally insert end conditions where they belong.
Guess I'll take Graham with a large dose of salt from now on. Or is
it possible that his description does not say what I think it does?
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Yes it works in practice - but does it work in theory?
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> Guess I'll take Graham with a large dose of salt from now on. Or is
> it possible that his description does not say what I think it does?
>
It seems to be saying that to me too. Off course, Graham states quite
clearly in his book that he isn't a loop fan.
--
Lieven Marchand <···@wyrd.be>
Gla�r ok reifr skyli gumna hverr, unz sinn b��r bana.
Lieven Marchand <···@wyrd.be> writes:
> It seems to be saying that to me too. Off course, Graham states
> quite clearly in his book that he isn't a loop fan.
My favorite is the index entry under "Macros...how not to use".
From: ········@hex.net
Subject: Re: Is there a "while " stetement in LISP?
Date:
Message-ID: <wk3ddnpwtr.fsf@mail.hex.net>
>>>>> "Lieven" == Lieven Marchand <···@wyrd.be> writes:
Lieven> Harald Hanche-Olsen <······@math.ntnu.no> writes:
>> Guess I'll take Graham with a large dose of salt from now on.
>> Or is it possible that his description does not say what I
>> think it does?
Lieven> It seems to be saying that to me too. Off course, Graham
Lieven> states quite clearly in his book that he isn't a loop fan.
That's a fair assessment.
Graham is certainly making some fair criticisms:
- LOOP _does_ suffer from being rather complex to understand.
- LOOP builds a "language syntax" that is considerably different from
what is used in most of the rest of CL.
The thing is, it's a bit of a leap to go from that to completely
deprecating LOOP as being unworthy of _any_ attention.
--
(concatenate 'string "cbbrowne" ·@acm.org")
http://www.ntlug.org/~cbbrowne/lisp.html
I have this nagging fear that everyone is out to make me paranoid.
········@hex.net writes:
> >>>>> "Lieven" == Lieven Marchand <···@wyrd.be> writes:
> Lieven> Harald Hanche-Olsen <······@math.ntnu.no> writes:
> >> Guess I'll take Graham with a large dose of salt from now on.
> >> Or is it possible that his description does not say what I
> >> think it does?
>
> Lieven> It seems to be saying that to me too. Off course, Graham
> Lieven> states quite clearly in his book that he isn't a loop fan.
>
> That's a fair assessment.
>
> Graham is certainly making some fair criticisms:
>
> - LOOP _does_ suffer from being rather complex to understand.
>
That's true in complex situations. But in those DO tends to get very
convoluted too. The reason why I've practically stopped using DO is
that often what starts out as a fairly simple iteration accumulates
more special cases and other stuff and LOOP is far more scalable in
that direction.
> - LOOP builds a "language syntax" that is considerably different from
> what is used in most of the rest of CL.
>
One of the nice things about CL is the ability to embed application
specific languages in it. Why not use it? For those that don't like
the syntax there are alternatives like SERIES and ITERATE.
--
Lieven Marchand <···@wyrd.be>
Gla�r ok reifr skyli gumna hverr, unz sinn b��r bana.
From: ········@hex.net
Subject: Re: Is there a "while " stetement in LISP?
Date:
Message-ID: <wk7l2vsy5k.fsf@mail.hex.net>
>>>>> "Lieven" == Lieven Marchand <···@wyrd.be> writes:
Lieven> ········@hex.net writes:
>> >>>>> "Lieven" == Lieven Marchand <···@wyrd.be> writes:
Lieven> Harald Hanche-Olsen <······@math.ntnu.no> writes:
>> >> Guess I'll take Graham with a large dose of salt from now
>> on. >> Or is it possible that his description does not say
>> what I >> think it does?
Lieven> It seems to be saying that to me too. Off course, Graham
Lieven> states quite clearly in his book that he isn't a loop fan.
>> That's a fair assessment.
>>
>> Graham is certainly making some fair criticisms:
>>
>> - LOOP _does_ suffer from being rather complex to understand.
Lieven> That's true in complex situations. But in those DO tends to
Lieven> get very convoluted too. The reason why I've practically
Lieven> stopped using DO is that often what starts out as a fairly
Lieven> simple iteration accumulates more special cases and other
Lieven> stuff and LOOP is far more scalable in that direction.
I find that I dislike DO quite a bit more than I dislike the
complexity of LOOP; I'd use DO to _implement_ something else, but
would probably rather tail recurse than use DO "in practice" :-).
>> - LOOP builds a "language syntax" that is considerably
>> different from what is used in most of the rest of CL.
Lieven> One of the nice things about CL is the ability to embed
Lieven> application specific languages in it. Why not use it? For
Lieven> those that don't like the syntax there are alternatives like
Lieven> SERIES and ITERATE.
So far, SERIES has been, to me, a solution looking for problems. I
haven't seen really tasty places to use it yet, which is disappointing
as there seems to be a lot to like about it. [In effect, SERIES
embeds, in Lisp, the important "generator" features of ICON...]
I probably should look at ITERATE, although I'd somewhat rather look
to something standard before looking to extensions. I suspect my time
is better spent figuring out more about LOOP...
--
(concatenate 'string "cbbrowne" ·@acm.org")
http://www.ntlug.org/~cbbrowne/lisp.html
"If your parents never had children, chances are you won't either."
-- Dick Cavett
········@hex.net writes:
> So far, SERIES has been, to me, a solution looking for problems. I
> haven't seen really tasty places to use it yet, which is disappointing
> as there seems to be a lot to like about it. [In effect, SERIES
> embeds, in Lisp, the important "generator" features of ICON...]
I've spend a bit of time investigating SERIES and I agree. It also
suffers from the scalability problem. It can be rather hard to modify
where with LOOP adding an extra clause is fairly straight forward.
--
Lieven Marchand <···@wyrd.be>
Gla�r ok reifr skyli gumna hverr, unz sinn b��r bana.
>>>>> "Lieven" == Lieven Marchand <···@wyrd.be> writes:
Lieven> ········@hex.net writes:
>> So far, SERIES has been, to me, a solution looking for problems. I
>> haven't seen really tasty places to use it yet, which is disappointing
>> as there seems to be a lot to like about it. [In effect, SERIES
>> embeds, in Lisp, the important "generator" features of ICON...]
Lieven> I've spend a bit of time investigating SERIES and I agree. It also
I use series whenever I would have used mapcar, reduce, etc., but have
knowledge about the data is which would benefit series. This can
generate better code, but that depends on how smart your compiler is
and on whether it can convert mapcar, reduce, etc., into iteration
itself. (If you look at some CMUCL lisp code, it seems there was a
start on this, but it was never finished and is commented out.)
Lieven> suffers from the scalability problem. It can be rather hard to modify
Lieven> where with LOOP adding an extra clause is fairly straight forward.
If I'm using a loop (either loop or do), then I'd use loop or do as
appropriate. Wouldn't you say map and friends and reduce also suffer
from a scalability problem?
Ray
Raymond Toy <···@rtp.ericsson.se> writes:
> If I'm using a loop (either loop or do), then I'd use loop or do as
> appropriate. Wouldn't you say map and friends and reduce also suffer
> from a scalability problem?
In a way yes, e.g., reduce is fine if you want to sum stuff (reduce
#'+ ...). When you want to combine that with a filter and some work
on the element (loop for item in sequence when (and (filter item) (/=
sum +foo+)) do (incf sum (function item))) becomes more readable than
the reduce equivalent.
--
Lieven Marchand <···@wyrd.be>
Gla�r ok reifr skyli gumna hverr, unz sinn b��r bana.
>>>>> "Lieven" == Lieven Marchand <···@wyrd.be> writes:
Lieven> Raymond Toy <···@rtp.ericsson.se> writes:
>> If I'm using a loop (either loop or do), then I'd use loop or do as
>> appropriate. Wouldn't you say map and friends and reduce also suffer
>> from a scalability problem?
Lieven> In a way yes, e.g., reduce is fine if you want to sum stuff (reduce
Lieven> #'+ ...). When you want to combine that with a filter and some work
Lieven> on the element (loop for item in sequence when (and (filter item) (/=
Lieven> sum +foo+)) do (incf sum (function item))) becomes more readable than
Lieven> the reduce equivalent.
I agree with you there. Of course, this particular example is fairly
straight-forward with series:
(collect-sum (#Mfunction (choose-if #'filter (scan sequence))))
except for the condition on sum not equal to +foo+. No idea how I'd
deal with that in the framework of series. Just don't do that, I
guess. :-)
Ray
From: Harald Hanche-Olsen
Subject: Re: Is there a "while " stetement in LISP?
Date:
Message-ID: <pcoelwz4qqo.fsf@thoth.home>
+ ········@hex.net:
| I probably should look at ITERATE, although I'd somewhat rather look
| to something standard before looking to extensions.
I wanted to try ITERATE, but could not get it to work with cmucl.
Before going into the gory details of what happened and my feeble
attempts at circumventing the problem, I'll ask here if anybody knows
how to get it to work?
On a completely different note: Did anybody fix emacs lisp mode so
that it will indent a LOOP body reasonably? (Whatever "reasonably"
may mean, but a smaller indent for stuff starting with a LOOP
keyword and a larger indent for the rest would be a good start.)
Apparently, the lack of good automagic indendation for LOOP is touted
as one reason to go for ITERATE.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Yes it works in practice - but does it work in theory?
From: Arthur Lemmens
Subject: Re: Is there a "while " stetement in LISP?
Date:
Message-ID: <3A8C5387.B0305CB5@xs4all.nl>
Harald Hanche-Olsen wrote:
> I wanted to try ITERATE, but could not get it to work with cmucl.
I've never tried ITERATE with cmucl, but I regularly use it with
Lispworks. Here's what I had to change to get the original ITERATE.LISP
(which calls itself version 1.2) working:
1. Add the following to the beginning of the file:
(eval-when (:compile-toplevel :load-toplevel :execute)
(pushnew :ansi-90 *features*))
2. Change the following line
(defclause-driver (FOR var IN-PACKAGE pkg
&optional EXTERNAL-ONLY (ext nil))
to
(defclause-driver (FOR var IN-PACKAGE pkg
&optional EXTERNAL-ONLY (ext 'nil))
ITERATE has become my preferred way of, ehm, looping.
It's a pity it didn't make it to the standard.
Arthur
"Arthur Lemmens" <········@xs4all.nl> wrote in message
······················@xs4all.nl...
>
> I regularly use [ITERATE ] with
> Lispworks. Here's what I had to change to get the original
> ITERATE.LISP
> (which calls itself version 1.2) working:
>
> 1. Add the following to the beginning of the file:
> (eval-when (:compile-toplevel :load-toplevel :execute)
> (pushnew :ansi-90 *features*))
>
> 2. Change the following line
> (defclause-driver (FOR var IN-PACKAGE pkg
> &optional EXTERNAL-ONLY (ext nil))
> to
> (defclause-driver (FOR var IN-PACKAGE pkg
> &optional EXTERNAL-ONLY (ext 'nil))
>
> ITERATE has become my preferred way of, ehm, looping.
> It's a pity it didn't make it to the standard.
>
> Arthur
Note: most of what follows is not specific to LispWorks, so read on if
ITERATE interests you even if you're not interested in LispWorks.
With the latest patch bundle from Xanalys (patch bundle 20), on Windows,
I didn't make either of the above changes, but I did make the following
change:
- Replace use of SPECIAL-FORM-P with SPECIAL-OPERATOR-P
(the Common Lisp HyperSpec states:
"Historically, [special-operator-p] was called special-form-p").
I also changed one of the entries in *SPECIAL-FORM-ALIST*, because it
looked like an obvious typo; I added a space preceding the dot in the
entry
(multiple-value-prog1. walk-cdr)
The only thing holding me back from using ITERATE seriously is this:
The modification dates in the file (iterate-1.2.lisp) show that it was
last changed in 1991. ANSI Common Lisp came into existence somewhat
later (1994?). I wonder if any changes made to Lisp after the ITERATE
code was written mean that there are situations where it doesn't work.
Can someone enlighten me?
Also, are there any known bugs, regardless of changes to Lisp itself?
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> I wanted to try ITERATE, but could not get it to work with cmucl.
>
> Before going into the gory details of what happened and my feeble
> attempts at circumventing the problem, I'll ask here if anybody knows
> how to get it to work?
As no-one else seems to have claimed to make a proper fix, I'll
contribute my quick hack.
http://www.s2.org/~chery/projects/iterate-1.2-fixed-for-cmucl.lisp
contains what is mostly iterate-1.2.lisp I found while searching
around. I make no claim that it is the latest version, I just think
so.
I changed the package name from ITERATE to ITER as there already was
an ITERATE package in my CMUCL. I also removed ITERATE from the
export list because EXTENSIONS exported it, I don't use ITERATE anyway, I
use ITER. I did retain COLLECT, however, so you probably want to
(shadowing-import 'iter:collect) before use-package'ing ITER into a
package where EXTENSIONS is used, such as CL-USER. On a second
thought these two put together were a very confusing thing to do. It
works, though.
I also moved some dispatch macro character code around because it did
not work in the order it was in, and modified package creation a bit,
but otherwise the code is unchanged from the original.
Hope this helps.
--
Teemu Kalvas
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> + Erik Naggum <····@naggum.net>:
>
> | Common Lisp _has_ while, the right way: as a termination condition
> | in a general iterator construct.
>
> Yikes! I'm glad you told me. For too long I've felt a deep distaste
> for the loop macro, which I now understand is caused by what appears
> to be a seriously wrong description of it in Paul Graham's "ANSI
> Common Lisp." Unless I read the description (in the reference
> section) wrong, it says that end conditions, like while, are always
> checked at the top, before any of the body forms - no matter in which
> order they appear in the code. This seemed horrible to me at the time
> I first saw it, and still does. But now, from looking at the
> HyperSpec (esp. section 6.1.1.6) and experimenting a bit, I see that
> loop does indeed do the right thing after all, allowing you to
> naturally insert end conditions where they belong.
>
> Guess I'll take Graham with a large dose of salt from now on. Or is
> it possible that his description does not say what I think it does?
on the issue of LOOP, one has to. graham does not hide his distaste
for LOOP and you must dig around in some other reference and try LOOP
yourself to see if you like it. for most other things, graham is
fine.
--
J o h a n K u l l s t a m
[········@ne.mediaone.net]
Don't Fear the Penguin!
In article <··············@euler.axel.nom>, Johan Kullstam
<········@ne.mediaone.net> wrote:
> Harald Hanche-Olsen <······@math.ntnu.no> writes:
>
> > + Erik Naggum <····@naggum.net>:
> >
> > | Common Lisp _has_ while, the right way: as a termination condition
> > | in a general iterator construct.
> >
> > Yikes! I'm glad you told me. For too long I've felt a deep distaste
> > for the loop macro, which I now understand is caused by what appears
> > to be a seriously wrong description of it in Paul Graham's "ANSI
> > Common Lisp." Unless I read the description (in the reference
> > section) wrong, it says that end conditions, like while, are always
> > checked at the top, before any of the body forms - no matter in which
> > order they appear in the code. This seemed horrible to me at the time
> > I first saw it, and still does. But now, from looking at the
> > HyperSpec (esp. section 6.1.1.6) and experimenting a bit, I see that
> > loop does indeed do the right thing after all, allowing you to
> > naturally insert end conditions where they belong.
> >
> > Guess I'll take Graham with a large dose of salt from now on. Or is
> > it possible that his description does not say what I think it does?
>
> on the issue of LOOP, one has to. graham does not hide his distaste
> for LOOP and you must dig around in some other reference and try LOOP
> yourself to see if you like it. for most other things, graham is
> fine.
For those with a more Lispy taste there is always
Jonathan Amsterdam's ITERATE macro:
http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/iter/iterate/0.html
Iterate is Jonathan Amsterdam's alternative to SERIES and the LOOP
macro. It provides a superset of LOOP's features in a much more
pleasant, Lisp-like syntax. Iterate is also extensible, has better
support for nested loops, and generates inline code.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Rainer Joswig <······@corporate-world.lisp.de> writes:
> For those with a more Lispy taste there is always
> Jonathan Amsterdam's ITERATE macro:
>
> http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/iter/iterate/0.html
>
> Iterate is Jonathan Amsterdam's alternative to SERIES and the LOOP
> macro. It provides a superset of LOOP's features in a much more
> pleasant, Lisp-like syntax. Iterate is also extensible, has better
> support for nested loops, and generates inline code.
It's a pleasure to read Jonathan Amsterdam's "Don't Loop, Iterate"
<URL:http://cbl.leeds.ac.uk/rodw/notes/net-src/iterate/doc/iterate-bare.ps>.
Jonathan Amsterdam:
"... others are so satisfied with do it's a wonder they're not C hackers. ...
Still others have gotten by with loop, but are getting tired of looking up
the syntax in the manual over and over again ..."
Question:
Does loop in the major CL implementations conform to the standard, meanwhile?
Regards,
Wolfhard.
--
"Das Auto hat keine Zukunft. Ich setze aufs Pferd." Wilhelm II. (1859-1941)
From: Lieven Marchand
Subject: Re: Don't Loop, Iterate (was: Is there a "while " stetement in LISP?)
Date:
Message-ID: <m3hf22wver.fsf@localhost.localdomain>
·····@gmx.net (Wolfhard Bu�) writes:
> Question:
> Does loop in the major CL implementations conform to the standard, meanwhile?
If you know of any bugs, you could report them to the appropriate
support forums I suppose.
LispWorks loop is so standard conforming they didn't implement the
common MIT extension of user defined iteration paths, so I tend to
load the MIT loop code in CL-USER.
--
Lieven Marchand <···@wyrd.be>
Gla�r ok reifr skyli gumna hverr, unz sinn b��r bana.