Hi, I just started coding what I always wanted to try out: doing
some stuff with finite automata and later regular expressions.
Right now I wrote a rather ugly loop to create an NFA from a
sequential string:
(loop with first = (make-instance 'state)
with nfa = (make-instance 'nfa :start-state first)
for c in (cons nil (loop for c across string collect c))
for source = first then target
for target = (make-instance 'state) then (make-instance 'state)
do (progn (add-state nfa source)
(link source c target))
finally (progn (add-state nfa target)
(setf (end-state nfa) target)
(return nfa))))
nil means a transition without any input.
Results look like this:
CL-USER> (print-nfa foo) ; from an input string "ab"
nfa: starts at G631
ends at G634
state G631
NIL -> G632
state G632
a -> G633
state G633
b -> G634
state G634
NIL
Any ideas how to make the loop cleaner and more elegant? This one
looks too much like Java code to me...
--
Don't let school interfere with your education. -- Mark Twain
Ulrich Hobelmann <···········@web.de> writes:
> Hi, I just started coding what I always wanted to try out: doing some
> stuff with finite automata and later regular expressions.
>
> Right now I wrote a rather ugly loop to create an NFA from a
> sequential string:
> (loop with first = (make-instance 'state)
> with nfa = (make-instance 'nfa :start-state first)
> for c in (cons nil (loop for c across string collect c))
> for source = first then target
> for target = (make-instance 'state) then (make-instance 'state)
> do (progn (add-state nfa source)
> (link source c target))
> finally (progn (add-state nfa target)
> (setf (end-state nfa) target)
> (return nfa))))
I think it looks reasonable. (The "then" part of "for target" is
redundant.) A different possibility is a recursive solution, if
you're unhappy with the iteration (untested, of course; hope there are
no stupid mistakes):
(let ((nfa (make-instance 'nfa :start-state (make-instance 'state)))
(label-list (cons nil (loop for c across string collect c))))
(labels ((extend-nfa (source target)
(add-state nfa source)
(cond (label-list
(link source (pop label-list) target)
(extend-nfa target (make-instance 'state)))
(t (add-state nfa target)
(setf (end-state nfa) target)))))
(extend-nfa (start-state nfa) (make-instance 'state))
nfa))
--
Rob St. Amant
http://www4.ncsu.edu/~stamant
Ulrich Hobelmann wrote:
> Hi, I just started coding what I always wanted to try out: doing some
> stuff with finite automata and later regular expressions.
>
> Right now I wrote a rather ugly loop to create an NFA from a sequential
> string:
> (loop with first = (make-instance 'state)
> with nfa = (make-instance 'nfa :start-state first)
> for c in (cons nil (loop for c across string collect c))
> for source = first then target
> for target = (make-instance 'state) then (make-instance 'state)
> do (progn (add-state nfa source)
> (link source c target))
> finally (progn (add-state nfa target)
> (setf (end-state nfa) target)
> (return nfa))))
It is commonplace to have something like add-state return the new state.
If you that:
(defun v1 (string)
(flet ((new-state () (make-instance 'state)))
(loop with nfa = (make-instance 'nfa :start-state (new-state))
for c in (cons nil (loop for c across string collect c))
for source = (start-state nfa) then target
for target = (new-state)
do
(link (add-state nfa source) c target)
finally
(setf (end-state nfa) (add-state nfa target))
(return nfa))))
Note that you do not need the progns.
State sounds simple, so I wager it can be a defstruct. That would give
us a make-state function. Then you can make the initform for start-state
be (make-state), and:
(defun v2 (string)
(loop with nfa = (make-instance 'nfa)
for c in (cons nil (loop for c across string collect c))
for source = (start-state nfa) then target
for target = (make-state)
do
(link (add-state nfa source) c target)
finally
(setf (end-state nfa) (add-state nfa target))
(return nfa)))
Anyway, I see room for a lot more improvement than that. I am bothered
by trying to blend initialization in with the looping, and I am
concerned about add-state not being called until a subsequent iteration.
Can you show us the link and add-state functions, as well as the nfa
defclass? ie, My goal is to get to v3:
(loop with nfa = (make-instance 'nfa)
for c across string
do (setf (input nfa) c) ;; see :after method on (setf input)
finally (return (nfa-terminate nfa))
Or even simpler. My thinking is that the machine should work by itself.
kt
--
Cells? : http://www.common-lisp.net/project/cells/
Cello? : http://www.common-lisp.net/project/cello/
Cells-Gtk? : http://www.common-lisp.net/project/cells-gtk/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton <·······@nyc.rr.com> writes:
> Note that you do not need the progns.
It's either the PROGNs or hacking emacs indenting...
(defun v1 (string)
(flet ((new-state () (make-instance 'state)))
(loop with nfa = (make-instance 'nfa :start-state (new-state))
for c in (cons nil (loop for c across string collect c))
for source = (start-state nfa) then target
for target = (new-state)
do (print c)
(link (add-state nfa source) c target)
finally (setf (end-state nfa) (add-state nfa target))
(return nfa))))
vs.:
(defun v1 (string)
(flet ((new-state () (make-instance 'state)))
(loop with nfa = (make-instance 'nfa :start-state (new-state))
for c in (cons nil (loop for c across string collect c))
for source = (start-state nfa) then target
for target = (new-state)
do (progn (print c)
(link (add-state nfa source) c target))
finally (progn (setf (end-state nfa) (add-state nfa target))
(return nfa)))))
--
__Pascal Bourguignon__ http://www.informatimago.com/
Small brave carnivores
Kill pine cones and mosquitoes
Fear vacuum cleaner
Pascal Bourguignon wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>>Note that you do not need the progns.
>
>
> It's either the PROGNs or hacking emacs indenting...
Will you please stop blaming the world for your self-destructive
decision to save some loose change and use "free" crap that forever
sucks the blood out of you? (As if a hacked emacs would give you
anywhere near the productivity of a grown-up Lisp IDE.) Go ahead and use
your toy environment, but for chrissake do not ever suggest I degrade my
code to satisfy your lame environment.
:)
kt
ps. How hard would the emacs indenting be?
--
Cells? : http://www.common-lisp.net/project/cells/
Cello? : http://www.common-lisp.net/project/cello/
Cells-Gtk? : http://www.common-lisp.net/project/cells-gtk/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton <·······@nyc.rr.com> writes:
> Will you please stop blaming the world for your self-destructive
> decision to save some loose change and use "free" crap that forever
> sucks the blood out of you? (As if a hacked emacs would give you
> anywhere near the productivity of a grown-up Lisp IDE.) Go ahead and use
> your toy environment, but for chrissake do not ever suggest I degrade my
> code to satisfy your lame environment.
>
> :)
>
> kt
>
> ps. How hard would the emacs indenting be?
Not hard, just boring. And there exists some code that does it, but
it's of questionable ownership/legality to distribute.
Does any Lisp environment besides Allegro indent LOOP correctly?
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Does any Lisp environment besides Allegro indent LOOP correctly?
Not that I know of.
(I simply put do on a line on its own to increase readbility - a better
compromise than introducing bogus progns, I think)
--
(espen)
On 03 Jun 2005 00:46:03 -0700, ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
> Does any Lisp environment besides Allegro indent LOOP correctly?
AllegroCL does indent LOOP correctly? Using ELI? ELI is GPL AFAIK so
it should be possible to port this.
No, wait, Kenny uses Franz' NotePad emulation, right?
:)
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
There is some code around to extend cl-indent-function to handle LOOP in
a more sensible way. I just cannot find it. :) ACL probably has some
extra hacks to deal also with IF*.
Cheers
--
Marco
Edi Weitz wrote:
> On 03 Jun 2005 00:46:03 -0700, ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
>
>
>>Does any Lisp environment besides Allegro indent LOOP correctly?
>
>
> AllegroCL does indent LOOP correctly? Using ELI? ELI is GPL AFAIK so
> it should be possible to port this.
>
> No, wait, Kenny uses Franz' NotePad emulation, right?
>
> :)
>
> Cheers,
> Edi.
>
Kenny Tilton <·······@nyc.rr.com> writes:
> Pascal Bourguignon wrote:
>> Kenny Tilton <·······@nyc.rr.com> writes:
>>
>>>Note that you do not need the progns.
>> It's either the PROGNs or hacking emacs indenting...
>
> Will you please stop blaming the world for your self-destructive
> decision to save some loose change and use "free" crap that forever
> sucks the blood out of you? (As if a hacked emacs would give you
> anywhere near the productivity of a grown-up Lisp IDE.) Go ahead and
> use your toy environment, but for chrissake do not ever suggest I
> degrade my code to satisfy your lame environment.
>
> :)
I take note. As soon as I'll be millionaire, I'd search one good
commercial IDE with features fullfiling my needs.
> kt
>
> ps. How hard would the emacs indenting be?
To do it correctly, you need an incremental parser.
Currently in emacs it's generally done with regexps, and moving around
the point, (using looking-at), and this is quite deficient because
correct indenting depends on the syntactic (and even sometimes
semantic) context.
Font-locking has similar problems. With an increment parser it would
be done at the same time as the indenting.
climacs does it properly. I could implement an increment parser in
emacs, but I've been wasted on Common-Lisp and I don't want to write
much emacs lisp anymore...
--
__Pascal Bourguignon__ http://www.informatimago.com/
You never feed me.
Perhaps I'll sleep on your face.
That will sure show you.
Kenny Tilton wrote:
> It is commonplace to have something like add-state return the new state.
...
> Note that you do not need the progns.
Ok, that simplifies something.
> State sounds simple, so I wager it can be a defstruct. That would give
> us a make-state function. Then you can make the initform for start-state
> be (make-state), and:
Well, since Peter Seibel's book doesn't mention defstructs, I just
use classes. Probably they're more flexible as well, if I need to
change anything.
> (defun v2 (string)
> (loop with nfa = (make-instance 'nfa)
> for c in (cons nil (loop for c across string collect c))
> for source = (start-state nfa) then target
> for target = (make-state)
> do
> (link (add-state nfa source) c target)
> finally
> (setf (end-state nfa) (add-state nfa target))
> (return nfa)))
I noticed that I only put in the nil for the (useless) case of an
empty string, so I removed it again. I added an init-after method
to NFA and moved the add-state call into link:
(defclass nfa ()
((start-state :accessor start-state)
(end-state :accessor end-state)
(states :accessor states)))
(defmethod initialize-instance :after ((nfa nfa) &key)
(let ((state (make-instance 'state)))
(setf (start-state nfa) state
(end-state nfa) state
(states nfa) (list state))))
(defun add-state (nfa state)
(push state (states nfa))
state)
(defun link (nfa st1 input st2)
(push (make-instance 'transition :input input
:target (add-state nfa st2))
(transitions st1)))
and the loop:
(loop with nfa = (make-instance 'nfa)
for c across string
for source = (start-state nfa) then target
for target = (make-instance 'state)
do (link nfa source c target)
finally
(setf (end-state nfa) target)
(return nfa))
I'm quite happy with it so far. There is to see how it will
handle the other cases when I add them.
> Anyway, I see room for a lot more improvement than that. I am bothered
> by trying to blend initialization in with the looping, and I am
> concerned about add-state not being called until a subsequent iteration.
>
> Can you show us the link and add-state functions, as well as the nfa
> defclass? ie, My goal is to get to v3:
>
> (loop with nfa = (make-instance 'nfa)
> for c across string
> do (setf (input nfa) c) ;; see :after method on (setf input)
> finally (return (nfa-terminate nfa))
>
> Or even simpler. My thinking is that the machine should work by itself.
I'm not sure if that makes sense. I want to add other functions,
such as adding many parallel nodes instead of sequential nodes,
for alternatives. The SETF (INPUT ...) makes implicit from which
node the next transition goes. I'm not sure I want that.
Anyway, thanks a lot for the help and inspirations. I'll also
look up setf-after methods, just in case :)
--
Don't let school interfere with your education. -- Mark Twain
Ulrich Hobelmann wrote:
> Any ideas how to make the loop cleaner and more elegant? This one looks
> too much like Java code to me...
The only way to win loop is not to play it at all.
mkb.
Matthias Buelow wrote:
> Ulrich Hobelmann wrote:
>
>
>>Any ideas how to make the loop cleaner and more elegant? This one looks
>>too much like Java code to me...
>
>
> The only way to win loop is not to play it at all.
Heh, well, sometimes I actually like loop despite its syntax.
Short, concise, and mostly it would take longer and result in less
readable code to use mapc / mapcar and other constructs.
--
Don't let school interfere with your education. -- Mark Twain
Ulrich Hobelmann wrote:
> Heh, well, sometimes I actually like loop despite its syntax. Short,
> concise, and mostly it would take longer and result in less readable
> code to use mapc / mapcar and other constructs.
I think the following quote from Graham's ACL book hits the nail on the
head:
"The loop macro was originally designed to help inexperienced Lisp users
write iterative code. ... Unfortunately, loop is more like English than
its designers ever intended: you can use it in simple cases without
quite understanding how it works, but to understand it in the abstract
is almost impossible. ... almost no one understands it. ... you probably
never will, because the ANSI standard does not really give a formal
specification of its behaviour."
I've always been amazed to see how many code snippets posted on c.l.l
use loop. I would think that something that is so ugly and goes so
badly against the flow of Lisp would be a pariah construct but
apparently the loop virus finds new victims every year.
mkb.
Matthias Buelow wrote:
> I've always been amazed to see how many code snippets posted on c.l.l
> use loop. I would think that something that is so ugly and goes so
> badly against the flow of Lisp would be a pariah construct but
> apparently the loop virus finds new victims every year.
I've liked LOOP for decades. I've never understood the misplaced
puritanism that prefers incomprehensible DO or (shudder) LABELS
constructs. For the things that LOOP does well, its competitors
are manifestly inferior.
Paul
Paul F. Dietz wrote:
> I've liked LOOP for decades. I've never understood the misplaced
> puritanism that prefers incomprehensible DO or (shudder) LABELS
> constructs. For the things that LOOP does well, its competitors
> are manifestly inferior.
Well, I'm only using Lisp for a couple years but I certainly do prefer
LABELS and Scheme-style recursion instead of DO (which I always get
wrong on the first attempt) or the abominable (imho) LOOP. There're
quite a few dark corners in Common Lisp and if I were to redesign it,
LOOP would be the first to go.
mkb.
Matthias Buelow wrote:
> Well, I'm only using Lisp for a couple years but I certainly do prefer
> LABELS and Scheme-style recursion instead of DO (which I always get
> wrong on the first attempt) or the abominable (imho) LOOP.
What can I say? You're wrong. :)
Doing Scheme in Lisp is another pet peeve of mine, btw.
Paul
Paul F. Dietz wrote:
> Matthias Buelow wrote:
>
>> Well, I'm only using Lisp for a couple years but I certainly do prefer
>> LABELS and Scheme-style recursion instead of DO (which I always get
>> wrong on the first attempt) or the abominable (imho) LOOP.
>
>
> What can I say? You're wrong. :)
I will say more in reaching the same conclusion.
To MB: You are not wrong. I was anti-Loop for almost a decade. then with
the help of PCL I broke down and learned it (something or other on
c.l.l. persuaded me to give it another try). Now I do not like using
anything else.
Again, you are not wrong. Loop is not Lisp. (nb: Loop does have a Lispy
alternative syntax.) But iterating comes up enough that the Loop
mini-language is worth learning.
Don't forget: Graham is wrong about CLOS, too. :)
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"If you plan to enter text which our system might consider to be
obscene, check here to certify that you are old enough to hear the
resulting output." -- Bell Labs text-to-speech interactive Web page
Kenny Tilton wrote:
> To MB: You are not wrong. I was anti-Loop for almost a decade. then with
> the help of PCL I broke down and learned it (something or other on
> c.l.l. persuaded me to give it another try). Now I do not like using
> anything else.
I must admit to not having read PCL so far (since I don't have the time
atm.) A cursory look at the online version shows that he introduces
loop pretty early. Also many snippets to new-user questions on c.l.l
use it. That's what I find a bit problematic. If you introduce new
users to loop early, it's like giving them eval right from the
beginning: you'll end up with programs that are basically loop forms
with a bit of ordinary lisp around them. Same with eval: it's too
easily abused by people who do not (yet) know what they're doing. An
experienced user may use loop (or rarely, eval) without doing much harm,
since he knows when to use it (and when not) but for a new user this
looks too much like a panacea to solve all his iteration (and recursion)
needs, just like eval tempts new users to abuse it by constructing forms
on the fly and feeding them to eval. IMHO new lisp users should start
with recursion for doing loops, and ordinary list functions (mapc,
mapcar, apply, ...), and understand them well, and then use iteration
constructs like do, dolist, and only then get introduced -- with
appropriate warnings -- to the loop facility.
mkb.
Matthias Buelow wrote:
> IMHO new lisp users should start
> with recursion for doing loops, and ordinary list functions (mapc,
> mapcar, apply, ...), and understand them well, and then use iteration
> constructs like do, dolist, and only then get introduced -- with
> appropriate warnings -- to the loop facility.
Should they be taught about the possibility that a given Lisp
implementation may or may not optimize tail recursion? Absent
guarantees, teaching Lisp recursion is teaching a non-portable
technique, as code which runs fine in one Lisp may exhaust memory in
another, and code which runs fine for small input may fail for large
input, even though there's no obvious input size dependencies in the code.
Cameron MacKinnon wrote:
> Should they be taught about the possibility that a given Lisp
> implementation may or may not optimize tail recursion? Absent
> guarantees, teaching Lisp recursion is teaching a non-portable
> technique, as code which runs fine in one Lisp may exhaust memory in
> another, and code which runs fine for small input may fail for large
> input, even though there's no obvious input size dependencies in the code.
They should be taught that a good compiler does employ tail
optimization, and that they should dump the rest that doesn't.
mkb.
Matthias Buelow wrote:
> I must admit to not having read PCL so far (since I don't have the time
> atm.) A cursory look at the online version shows that he introduces
> loop pretty early. Also many snippets to new-user questions on c.l.l
> use it. That's what I find a bit problematic. If you introduce new
> users to loop early, it's like giving them eval right from the
> beginning: you'll end up with programs that are basically loop forms
> with a bit of ordinary lisp around them. Same with eval: it's too
> easily abused by people who do not (yet) know what they're doing. An
> experienced user may use loop (or rarely, eval) without doing much harm,
> since he knows when to use it (and when not) but for a new user this
> looks too much like a panacea to solve all his iteration (and recursion)
> needs, just like eval tempts new users to abuse it by constructing forms
> on the fly and feeding them to eval. IMHO new lisp users should start
> with recursion for doing loops, and ordinary list functions (mapc,
> mapcar, apply, ...), and understand them well, and then use iteration
> constructs like do, dolist, and only then get introduced -- with
> appropriate warnings -- to the loop facility.
>
Yes, oh mighty dictator! We bow to your altar of wisdom... we
cannot have people just doing whatever they want. (lead us not
into temptations...)
Wade
Wade Humeniuk wrote:
> Yes, oh mighty dictator! We bow to your altar of wisdom... we
> cannot have people just doing whatever they want. (lead us not
> into temptations...)
Eh? I was just arguing from a didactical point of view. If you want to
criticize this, then please do it in a more substantial way than just
dropping bullshit.
mkb.
Matthias Buelow wrote:
> Eh? I was just arguing from a didactical point of view. If you want to
> criticize this, then please do it in a more substantial way than just
> dropping bullshit.
A didactical point of view that assumes your prejudice
reflects an actual problem.
Paul
Matthias Buelow wrote:
> Wade Humeniuk wrote:
>
>
>>Yes, oh mighty dictator! We bow to your altar of wisdom... we
>>cannot have people just doing whatever they want. (lead us not
>>into temptations...)
>
>
> Eh? I was just arguing from a didactical point of view. If you want to
> criticize this, then please do it in a more substantial way than just
> dropping bullshit.
>
Well.... No, can't help myself, I am a bull after all. You are
bound for an early grave with such a serious controlling attitude.
If you could also redesign c.l.l would I also be the first to go?
Wade
Wade Humeniuk wrote:
> Well.... No, can't help myself, I am a bull after all. You are
> bound for an early grave with such a serious controlling attitude.
> If you could also redesign c.l.l would I also be the first to go?
You can't seem to stand opinions being voiced that are different from yours.
mkb.
Matthias Buelow wrote:
> Wade Humeniuk wrote:
>
>
>>Well.... No, can't help myself, I am a bull after all. You are
>>bound for an early grave with such a serious controlling attitude.
>>If you could also redesign c.l.l would I also be the first to go?
>
>
> You can't seem to stand opinions being voiced that are different from yours.
>
Yes, my Master. Together we shall end this destructive Lisp conflict and
bring peace and order to the galaxy ....
Hoping to be a new Darth and Laughing On a Sunday Morning!
Wade
On 4295 September 1993, Wade Humeniuk wrote:
> Hoping to be a new Darth and Laughing On a Sunday Morning!
But Darth Wade sounds sooo much better than Darth Matthias ...
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"`ar, tar, cpio und rpm2cpio'. Eine Aufz�hlung wie `L�ffel, Messer,
Gabel und Siemens' Spezialschraubenschl�ssel Nr.08/15 f�r den
vollelektronischen Dosen�ffner aus dem 97'er Weihnachtssonderangebot
in Blaumetallic.'" -- Aldo Valente in de.comp.os.unix.linux.misc
Matthias Buelow wrote:
> Wade Humeniuk wrote:
>
>
>>Yes, oh mighty dictator! We bow to your altar of wisdom... we
>>cannot have people just doing whatever they want. (lead us not
>>into temptations...)
>
>
> Eh? I was just arguing from a didactical point of view. If you want to
> criticize this, then please do it in a more substantial way than just
> dropping bullshit.
Sorry, this is comp.lang.lisp, and we are The Savages Thereof. Bullshit
is as sophisticated as we get. If you want nice manners, try the pointy
heads over in comp.lang.scheme.
But seriously folks, I had the same reaction as Wade: humans generally
screw up when they overthink things. I should not as a teacher set
myself so high as to try to save students from abuse I am only imagining
they might make of a feature. You concern is plausible (loop forms qua
programs) but does not justify hiding a cool construct from students who
might apply it judiciously, and benefit from the advantages of loop.
Better to let Nature take its course and just lay the language out there
and let the chips fall where they may. Holdiong back on loop will not
keep abusuers from abusing it anyway.
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"If you plan to enter text which our system might consider to be
obscene, check here to certify that you are old enough to hear the
resulting output." -- Bell Labs text-to-speech interactive Web page
Kenny Tilton wrote:
> Better to let Nature take its course and just lay the language out there
> and let the chips fall where they may. Holdiong back on loop will not
> keep abusuers from abusing it anyway.
But surely you'd want to teach students good programming techniques
first, and only then give them the cheats?
mkb.
Matthias Buelow wrote:
> Kenny Tilton wrote:
>
>
>>Better to let Nature take its course and just lay the language out there
>>and let the chips fall where they may. Holdiong back on loop will not
>>keep abusuers from abusing it anyway.
>
>
> But surely you'd want to teach students good programming techniques
> first, and only then give them the cheats?
Cheat?! It is in the spec, probably because it was deemed to be not just
some random hack, but rather a solid extension to Lisp.
Anyway, the didactic arrow can point in the other direction (other than
simple-first, fancy-later) as often. Sometimes we convey as much power
as painlessly as possible (your so-called "cheats"), and hide ugly
details until (a) some momentum has developed and (b) the higher order
construct breaks down and we need grittier stuff.
btw, I believe the thing that got me to look at loop was that it
provides efficiency for free, which is rare in cheats:
(loop for x in them
when (yada x)
collect x)
vs:
(let (out)
(dolist (x them (nreverse out))
(when (yada x) (push x out)
If I had learned Lisp from PCL I would have grown up with loop as a
native sub-language and not gone seven years without it. As it was, I
knew the do family and was able to get by with that, so why kill a day
learning what looked to be a tangled mess of a sublanguage?
So maybe loop is like skating or skiing: start 'em young so they grow up
with it.
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"If you plan to enter text which our system might consider to be
obscene, check here to certify that you are old enough to hear the
resulting output." -- Bell Labs text-to-speech interactive Web page
Kenny Tilton <·······@nyc.rr.com> schrieb:
> (loop for x in them
> when (yada x)
> collect x)
>
> vs:
>
> (let (out)
> (dolist (x them (nreverse out))
> (when (yada x) (push x out)
What about: (filter #'yada them)
I'm not sure why people are doing so much explicit iteration when map,
fold and friends cover almost everything already.
Adrian Kubala wrote:
> What about: (filter #'yada them)
> I'm not sure why people are doing so much explicit iteration when map,
> fold and friends cover almost everything already.
(remove-if-not #'yada them)
(I have actually seen someone reimplement filter (with labels!),
not realizing CL already had it.)
Paul
>>>>> "PD" == Paul Dietz <············@motorola.com> writes:
[...]
PD> (remove-if-not #'yada them)
PD> (I have actually seen someone reimplement filter (with
PD> labels!), not realizing CL already had it.)
If I turned in anything written in lisp when you were my teacher, that
may well have been me. It took me a looong time to realize this even
though I was aware of the remove-* functions. 'Remove-if-not' somehow
still does not imply 'filter' for me though it seems obvious that it
should. Peter made this explicit in his book, which I thought was an
excellent idea.
cheers,
BM
Bulent Murtezaoglu <··@acm.org> writes:
>>>>>> "PD" == Paul Dietz <············@motorola.com> writes:
> [...]
> PD> (remove-if-not #'yada them)
>
> PD> (I have actually seen someone reimplement filter (with
> PD> labels!), not realizing CL already had it.)
>
> If I turned in anything written in lisp when you were my teacher, that
> may well have been me. It took me a looong time to realize this even
> though I was aware of the remove-* functions. 'Remove-if-not' somehow
> still does not imply 'filter' for me though it seems obvious that it
> should. Peter made this explicit in his book, which I thought was an
> excellent idea.
This is big part of lisp, realizing that two differenly named
operations are actually exactly the same. car = first, cdr = rest,
actors = continuations, remove = filter. It's one of the reasons why
lisp is so powerful.
--
__Pascal Bourguignon__ http://www.informatimago.com/
You never feed me.
Perhaps I'll sleep on your face.
That will sure show you.
Pascal Bourguignon <···@informatimago.com> writes:
> This is big part of lisp, realizing that two differenly named
> operations are actually exactly the same. car = first, cdr = rest,
> actors = continuations, remove = filter. It's one of the reasons why
> lisp is so powerful.
So what looks like inconsistency and redundancy to the uninitiated is
actually a sign of power. Wow. How lucky we are that the CL design
committee had so many different lisps to choose function/ variable/
macro names from. Otherwise we might not have this kind of power. ;-)
Matthias wrote:
> Pascal Bourguignon <···@informatimago.com> writes:
> > This is big part of lisp, realizing that two differenly named
> > operations are actually exactly the same. car = first, cdr = rest,
> > actors = continuations, remove = filter. It's one of the reasons why
> > lisp is so powerful.
>
> So what looks like inconsistency and redundancy to the uninitiated is
> actually a sign of power. Wow. How lucky we are that the CL design
> committee had so many different lisps to choose function/ variable/
> macro names from. Otherwise we might not have this kind of power. ;-)
You miss the point of CAR/CDR. People believe it's at the heart of
Lisp, yet it forms a little language which combines in a most unlispy
way.
It made the (loop for i = ... by #'cddr) example work without much
finger-typing and room for bugs.
There are other mini-languages that people don't think of. Take
numbers: 134217728. That's a mini-language. Certainly redundant, if you
believe that we should have a few primitive numbers and build the rest.
Why not? It doesn't have to be at runtime, so at read-time we can do:
#.(let* ((eight (+ 1 1 1 1 1 1 1 1))
(nine (+ eight 1)))
(expt eight nine)) ; 134217728
This is the lesson of those minimalist SK-combinator languages.
When we finally stop using "redundancy" as a blunt buzzword, we come to
ask where on the spectrum we wish to lie regarding redundancy.
Most successful systems in nature have seeming-redundancy. (Though I
think it's more overlapping and not straight redundancy.) I think Lisp
has remarkably little redundancy, for a system which has undergone its
ice age and is quietly returning to the world.
Does this mean Lisp has the perfect amount? No way!
http://lisp.tech.coop/Lisp%20Gotchas
Now, if you're a "hobbyist", CL is not aimed at you. It's aimed at
people with more industrial needs, which means as a "common" language,
it does not fit all needs. A compromise! And in the world, we see a
cambrian explosion of languages which don't really interoperate well,
except when using sexps-with-pointy-parens, which is all an INSANE
amount of redundancy.
Ergo, Common Lisp.
Tayssir
+ "Tayssir John Gabbour" <···········@yahoo.com>:
| There are other mini-languages that people don't think of. Take
| numbers: 134217728. That's a mini-language. Certainly redundant, if you
| believe that we should have a few primitive numbers and build the rest.
| Why not? It doesn't have to be at runtime, so at read-time we can do:
|
| #.(let* ((eight (+ 1 1 1 1 1 1 1 1))
| (nine (+ eight 1)))
| (expt eight nine)) ; 134217728
Who needs numbers? Bah! When I grew up we only had Church numerals.
They were good enough for me, they should be plenty sufficient for all
your scientific computing needs.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> Who needs numbers? Bah! When I grew up we only had Church numerals.
Bah! That means you have to deal with the lambda calculus and all that
syntactic sugar? What's wrong with good old axiomatic set theory?
--
(espen)
Matthias Buelow wrote:
> Kenny Tilton wrote:
>
>>Better to let Nature take its course and just lay the language out there
>>and let the chips fall where they may. Holdiong back on loop will not
>>keep abusuers from abusing it anyway.
>
> But surely you'd want to teach students good programming techniques
> first, and only then give them the cheats?
Define "good programming techniques".
The discussion boils down to this: What makes you think that you have
seen the light? Your students may not even stick to Lisp...
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Matthias Buelow <···@incubus.de> writes:
> Kenny Tilton wrote:
>
> > Better to let Nature take its course and just lay the language out there
> > and let the chips fall where they may. Holdiong back on loop will not
> > keep abusuers from abusing it anyway.
>
> But surely you'd want to teach students good programming techniques
> first, and only then give them the cheats?
You're absolutely right. Teaching new students how to use the
existing structures that come with the language will only encourage
them to depend on decades of others' experience. Better to have them
build up their own structures from the start. No LOOP, no DO, no
LABELS. For Purity, give them LAMBDA with which they can build their
own Y combinator and with that all else. For Clarity, give them
TAGBODY and GO (or maybe cheat and give them all of PROG) with which
they can build their own loops.
(I'm only half-kidding about PROG, maybe this would help stop the
abuse of boolean state variables in loops)
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
Matthias Buelow wrote:
> Wade Humeniuk wrote:
>
>
>>Yes, oh mighty dictator! We bow to your altar of wisdom... we
>>cannot have people just doing whatever they want. (lead us not
>>into temptations...)
>
>
> Eh? I was just arguing from a didactical point of view. If you want to
> criticize this, then please do it in a more substantial way than just
> dropping bullshit.
Speaking for myself: I used Scheme for some time and SML after
that, so I'm definitely used to recursion instead of looping. In
my first CL program I started using mapcar and mapc in some
places, but now I rewrote them as LOOPs to make them clearer (with
one exception: loop for ex in (mapcar ...)).
To me loop looks like a perfect solution to general iteration
problems, while I'd use mapcar over loop for simple mappings in an
instant.
I think both iteration and recursion are natural in real-world
programming and should be both be stressed for beginners. Clearly
most (good) CS texts, for instance SICP, focus more on the
recursion part, as that's where most beginners have problems
(maybe because in Java iteration is the gold standard, and
recursion at least painful).
--
Don't let school interfere with your education. -- Mark Twain
On Sun, 05 Jun 2005 16:47:28 +0200, Matthias Buelow <···@incubus.de> wrote:
>
> I must admit to not having read PCL so far (since I don't have the time
> atm.) A cursory look at the online version shows that he introduces
> loop pretty early. Also many snippets to new-user questions on c.l.l
> use it. That's what I find a bit problematic. If you introduce new
> users to loop early, it's like giving them eval right from the
> beginning: you'll end up with programs that are basically loop forms
> with a bit of ordinary lisp around them. Same with eval: it's too
> easily abused by people who do not (yet) know what they're doing. An
> experienced user may use loop (or rarely, eval) without doing much harm,
> since he knows when to use it (and when not) but for a new user this
> looks too much like a panacea to solve all his iteration (and recursion)
> needs, just like eval tempts new users to abuse it by constructing forms
> on the fly and feeding them to eval. IMHO new lisp users should start
> with recursion for doing loops, and ordinary list functions (mapc,
> mapcar, apply, ...), and understand them well, and then use iteration
> constructs like do, dolist, and only then get introduced -- with
> appropriate warnings -- to the loop facility.
>
Lisp is all about exploratory programming, right? I'd say new users (like
myself) ought to experiment, and then we can decide for ourselves.
--
Jack
Matthias Buelow wrote:
> I must admit to not having read PCL so far (since I don't have the time
> atm.) A cursory look at the online version shows that he introduces
> loop pretty early. Also many snippets to new-user questions on c.l.l
> use it. That's what I find a bit problematic. If you introduce new
> users to loop early, it's like giving them eval right from the
> beginning: you'll end up with programs that are basically loop forms
> with a bit of ordinary lisp around them. Same with eval: it's too
> easily abused by people who do not (yet) know what they're doing.
This is not a good comparison (and by your own standards too confusing
for beginners). EVAL can lead to problems because it allows you to
execute code on the metalevel, and it's important to understand the
difference between base level and metalevel in order to know what you're
doing when you use EVAL. Nothing exists that remotely resembles these
issues in the case of LOOP vs other iteration constructs.
LOOP is a good example of a 'domain-specific' language designed to solve
certain tasks well while leaving other tasks untouched. I don't see why
it would be a bad message to encourage thinking in terms of
domain-oriented abstractions.
> An
> experienced user may use loop (or rarely, eval) without doing much harm,
> since he knows when to use it (and when not) but for a new user this
> looks too much like a panacea to solve all his iteration (and recursion)
> needs, just like eval tempts new users to abuse it by constructing forms
> on the fly and feeding them to eval. IMHO new lisp users should start
> with recursion for doing loops, and ordinary list functions (mapc,
> mapcar, apply, ...), and understand them well, and then use iteration
> constructs like do, dolist, and only then get introduced -- with
> appropriate warnings -- to the loop facility.
Is this a claim, a conjecture, or an empirical assessment? Can you back
this with references to existing literature?
Or is it that you just don't like LOOP and try to impose your personal
preferences on others?
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Pascal Costanza wrote:
>> on the fly and feeding them to eval. IMHO new lisp users should start
>> with recursion for doing loops, and ordinary list functions (mapc,
>> mapcar, apply, ...), and understand them well, and then use iteration
>> constructs like do, dolist, and only then get introduced -- with
>> appropriate warnings -- to the loop facility.
>
> Is this a claim, a conjecture, or an empirical assessment? Can you back
> this with references to existing literature?
It is a conjecture, resulting from applying common sense. Why should
one teach something that is a) not properly defined, b) ambiguous and c)
totally different in style and workings than the rest of Common Lisp to
a new learner of that language, who wants to get a grasp on the
essentials and the general feeling of the language first, and not on
its, to put it mildly, fanciful outgrowths.
If one could inline a subset of BASIC into Common Lisp, because someone
somewhen deemed that practical for a certain application, would you also
teach beginners BASIC instead of Lisp?
mkb.
Matthias Buelow wrote:
> Pascal Costanza wrote:
>
> >> on the fly and feeding them to eval. IMHO new lisp users should start
> >> with recursion for doing loops, and ordinary list functions (mapc,
> >> mapcar, apply, ...), and understand them well, and then use iteration
> >> constructs like do, dolist, and only then get introduced -- with
> >> appropriate warnings -- to the loop facility.
> >
> > Is this a claim, a conjecture, or an empirical assessment? Can you back
> > this with references to existing literature?
>
> It is a conjecture, resulting from applying common sense. Why should
> one teach something that is a) not properly defined, b) ambiguous and c)
> totally different in style and workings than the rest of Common Lisp to
> a new learner of that language, who wants to get a grasp on the
> essentials and the general feeling of the language first, and not on
> its, to put it mildly, fanciful outgrowths.
My question: is iteration complicated enough that LOOP is appropriate?
I think yes. The universe never guaranteed that it could be neatly
described by an aesthetically "Lispish" form.
In fact, I recall someone found keyword arguments "unlispy" either.
Well, many parts of the world don't bend for Lisp. I personally find
LAMBDA repugnant, and it's part of a main alternative to LOOP. Here's a
user anecdote:
"After trying to 'self-learn' lisp in the 80's I get this physical
reaction to the word 'lambda'...a cold sweat combined with the
involuntary retraction of my testicles to a protected location in my
abdomen (damn unpleasant shit)..."
http://slashdot.org/article.pl?sid=01/11/03/1726251&mode=nocomment
It's a pretentious and lazy name whose purpose in life is to turn
people off to a simple concept, of building little lexical bubbles.
But LOOP? Well, there may be some design problems in it that's fixed by
ITERATE, but I still like LOOP a lot. Think of it as a witticism, a
humorous expression; in particular "loop for key being the hash-keys of
hash using (hash-value val)". That's your programming tool having
character. None of this paved-over Java corporate crap, which is
uniform so commodity coders can be plugged into it.
> If one could inline a subset of BASIC into Common Lisp, because someone
> somewhen deemed that practical for a certain application, would you also
> teach beginners BASIC instead of Lisp?
If BASIC were better than Lisp, most certainly.
Tayssir John Gabbour wrote:
> Matthias Buelow wrote:
> > Pascal Costanza wrote:
> > >> on the fly and feeding them to eval. IMHO new lisp users should start
> > >> with recursion for doing loops, and ordinary list functions (mapc,
> > >> mapcar, apply, ...), and understand them well, and then use iteration
> > >> constructs like do, dolist, and only then get introduced -- with
> > >> appropriate warnings -- to the loop facility.
> > >
> > > Is this a claim, a conjecture, or an empirical assessment? Can you back
> > > this with references to existing literature?
> >
> > It is a conjecture, resulting from applying common sense. Why should
> > one teach something that is a) not properly defined, b) ambiguous and c)
> > totally different in style and workings than the rest of Common Lisp to
> > a new learner of that language, who wants to get a grasp on the
> > essentials and the general feeling of the language first, and not on
> > its, to put it mildly, fanciful outgrowths.
>
> My question: is iteration complicated enough that LOOP is appropriate?
> I think yes. The universe never guaranteed that it could be neatly
> described by an aesthetically "Lispish" form.
>
> In fact, I recall someone found keyword arguments "unlispy" either.
> Well, many parts of the world don't bend for Lisp.
That was Stallman, incidentally, who was a prolific Lisp Machine
developer. I can't find the cite easily though, and I suspect I read
that in a context where he explained he eventually changed his mind.
>>>>> Tayssir John Gabbour <···········@yahoo.com> writes:
> Tayssir John Gabbour wrote:
>> Matthias Buelow wrote:
[snip]
>> My question: is iteration complicated enough that LOOP is appropriate?
>> I think yes. The universe never guaranteed that it could be neatly
>> described by an aesthetically "Lispish" form.
>>
>> In fact, I recall someone found keyword arguments "unlispy" either.
>> Well, many parts of the world don't bend for Lisp.
> That was Stallman, incidentally, who was a prolific Lisp Machine
> developer. I can't find the cite easily though, and I suspect I read
> that in a context where he explained he eventually changed his mind.
Maybe you mean this?
http://www.gnu.org/gnu/rms-lisp.html
(Transcript of Richard Stallman's Speech, 28 Oct 2002, at the
International Lisp Conference)
"One thing I don't like terribly much is keyword arguments. They
don't seem quite Lispy to me; I'll do it sometimes but I minimize
the times when I do that."
HTH
Roland
Tayssir John Gabbour wrote:
> My question: is iteration complicated enough that LOOP is appropriate?
> I think yes. The universe never guaranteed that it could be neatly
> described by an aesthetically "Lispish" form.
Iteration is certainly complicated enough to be a source of many bugs in
code written in many computer languages. It's complicated enough that
Scheme's inventors took a radically different approach to it. It's
complicated enough that there will likely never be consensus among
Lispers about the best construct to express it with.
> I personally find
> LAMBDA repugnant...
> It's a pretentious and lazy name whose purpose in life is to turn
> people off to a simple concept, of building little lexical bubbles.
That's the result, not the original purpose. It's an artifact of
primitive early computers that a symbol which could be written with two
quick strokes of the pencil (and which rather resembled mathematics'
canonical symbol for the generic placeholder) turned into an ugly
looking six keystrokes signifying nothing.
--
Cameron MacKinnon
Toronto, Canada
Matthias Buelow wrote:
> It is a conjecture, resulting from applying common sense. Why should
> one teach something that is a) not properly defined, b) ambiguous and c)
> totally different in style and workings than the rest of Common Lisp to
> a new learner of that language, who wants to get a grasp on the
> essentials and the general feeling of the language first, and not on
> its, to put it mildly, fanciful outgrowths.
Because (a) it is properly defined, in practice(*), (b) is not ambiguous,
as actually used, and (c) more concise and understandable than the
alternatives in Common Lisp.
Loop fills a gap. If you don't like it, well, it's your loss, Matthias.
Paul
(*) There are some problems with corner cases here and there, but that's
true of many other parts of the CL standard as well. Deal with it.
In article <··············@news.dfncis.de>,
Matthias Buelow <···@incubus.de> wrote:
> Pascal Costanza wrote:
>
> >> on the fly and feeding them to eval. IMHO new lisp users should start
> >> with recursion for doing loops, and ordinary list functions (mapc,
> >> mapcar, apply, ...), and understand them well, and then use iteration
> >> constructs like do, dolist, and only then get introduced -- with
> >> appropriate warnings -- to the loop facility.
> >
> > Is this a claim, a conjecture, or an empirical assessment? Can you back
> > this with references to existing literature?
>
> It is a conjecture, resulting from applying common sense. Why should
> one teach something that is a) not properly defined, b) ambiguous and c)
> totally different in style and workings than the rest of Common Lisp to
> a new learner of that language, who wants to get a grasp on the
> essentials and the general feeling of the language first, and not on
> its, to put it mildly, fanciful outgrowths.
>
> If one could inline a subset of BASIC into Common Lisp, because someone
> somewhen deemed that practical for a certain application, would you also
> teach beginners BASIC instead of Lisp?
But there *is* a subset of BASIC embedded in Common Lisp. It's called
PROG. Why do we not have the same arguments about PROG that we do about
LOOP?
There is no sense in arguing about LOOP (or PROG). Some people like it,
some don't. You can't banish it from the language because it's just a
macro (albeit a particularly complicated one) and any user who wants it
can just add it to their own environment. (Aside: I've always thought
one of LOOP's charms was that it served as an illustration of the
tremendous power of macros. Reasonable people can differ whether LOOP
is an illustration of using that power for good or ill, but there is no
denying that the ability for a user to add LOOP to the language if it
did not exist is unique to Lisp.)
Personally, I like LOOP. In many situations it can make code much
easier to read than it otherwise would be, which IMO is all to the good.
One of the reasons for this is precisely that its syntax is not
Lisp-like. If there is anything the Lisp community should have learned
in the last fifty years it is that some people like S-expressions, and
other people don't. IMHO, LOOP demonstrates that Lisp can accommodate
both predilections and thus broaden the appeal of the language.
(Aside2: I've always thought it odd that on the one hand Lisp is touted
as the "programmable programming language" and then on the other hand so
many of Lisp's adherents object so violently when someone actually takes
advantage of this capability.)
It is sometimes argued that popularity is not a good thing because Lisp
is a language for masters and to be popular one must cater to the least
common denominator. It is often true that popular things become that
way because they aim low, but it does not follow that this is
*necessary* for popularity. In particular, the existence of LOOP comes
at very little cost to those who don't like its aesthetics. If you
don't like LOOP, don't use it, and the result is a programming
experience that is identical in every respect to one where LOOP didn't
exist. On the other side of the balance, popularity accrues the
benefits that come with economies of scale: bigger markets, more
availability of employment and employees, less time wasted arguing with
the PHB. So it seems to me that arguing against LOOP is
counterproductive regardless of how you personally feel about it. But,
as I disclosed above, I do have a certain bias.
rg
Matthias Buelow <···@incubus.de> writes:
> Why should one teach something that is a) not properly defined, b)
> ambiguous and c) totally different in style and workings than the
> rest of Common Lisp to a new learner of that language, who wants to
> get a grasp on the essentials and the general feeling of the
> language first, and not on its, to put it mildly, fanciful
> outgrowths.
Primarily because nobody is exposed to Common Lisp as a first
language; they've already got a head full of ideas about how
programming works. And so there are several answers to your question:
* Because the learner comes from languages with convenient constructs
for iteration that fit nicely with those languages' data types, and
you want them to understand that Lisp has analogous constructs.
* Because do/do* requires a lot of parentheses, which will probably
only confirm most parenthophobes' fears of Lisp.
* Because if you don't, then the learner who hasn't yet understood the
use of higher order functions is liable to write things like this:
(dotimes (i (floor (/ (1+ (length some-list)) 2)))
(let ((obj (nth (* 2 i) some-list)))
<body>))
instead of this
(loop for obj in some-list by #'cddr
do <body>)
If they write code like the former, they'll "learn" that Lisp is
slow. (They shouldn't be using lists for much of anything either,
but they're going to anyhow.) And remember, the latest spin on why
CL is cool is that it's an unbounded superset of the languages that
a novice will already know, so we can't just say "Don't write
iterative code for walking lists; you must use map and functions."
* Because exposing a learner to sublanguages embedded in Lisp will
convey the notion that Lisp can mix-n-match lots of different
idioms, and gives an early opportunity to explain that one can add
powerful, expressive language extensions, like loop.
--
Richard
Richard M Kreuter wrote:
> * Because if you don't, then the learner who hasn't yet understood the
> use of higher order functions is liable to write things like this:
>
> (dotimes (i (floor (/ (1+ (length some-list)) 2)))
> (let ((obj (nth (* 2 i) some-list)))
> <body>))
>
> instead of this
>
> (loop for obj in some-list by #'cddr
> do <body>)
I'd present higher-order functions pretty early. Then the learner might
come up with something like the following.
He'd perhaps write a general purpose utility, which is also useful for
future use:
(defun step-list (l s f)
(let ((o (funcall s l)))
(if (car o)
(progn
(funcall f (car o))
(step-list o s f)))))
And then he could use it like:
(step-list '(1 2 3 4 5 6 7 8 9 10 11 12) #'cddr #'princ)
instead of
(loop for obj in '(1 2 3 4 5 6 7 8 9 10 11 12) by #'cddr do (princ obj))
Granted, the loop is faster to write for a one-shot solution of that
kind but as soon as you'd use that construct a second time, the first
approach is faster, and easier to understand.
That's also a problem I sometimes find when reading Lisp source: Instead
of constructing utility functions (and macros), and assembling
algorithms from these utilities, some people write the logics in form of
endlessly nested LOOPs (or DO or whatever), with the result that it is
truly horrible to read, compared to programming by combining
meaningfully named functions.
mkb.
Matthias Buelow wrote:
> I'd present higher-order functions pretty early. Then the learner might
> come up with something like the following.
>
> He'd perhaps write a general purpose utility, which is also useful for
> future use:
>
> (defun step-list (l s f)
> (let ((o (funcall s l)))
> (if (car o)
> (progn
> (funcall f (car o))
> (step-list o s f)))))
>
> And then he could use it like:
>
> (step-list '(1 2 3 4 5 6 7 8 9 10 11 12) #'cddr #'princ)
>
> instead of
>
> (loop for obj in '(1 2 3 4 5 6 7 8 9 10 11 12) by #'cddr do (princ obj))
>
> Granted, the loop is faster to write for a one-shot solution of that
> kind but as soon as you'd use that construct a second time, the first
> approach is faster, and easier to understand.
These two "solutions" are not even remotely similar:
? (step-list '(t 1 nil 2 t 3) #'cddr #'print)
NIL
? (loop for obj in '(t 1 nil 2 t 3) by #'cddr
do (print obj))
T
NIL
T
NIL
Now before correcting one of the two versions, please ask yourself first
the following question: Which of the two is better understandable wrt
what it is supposed to do?
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
> These two "solutions" are not even remotely similar:
>
> ? (step-list '(t 1 nil 2 t 3) #'cddr #'print)
> NIL
> ? (loop for obj in '(t 1 nil 2 t 3) by #'cddr
> do (print obj))
>
> T
> NIL
> T
> NIL
>
> Now before correcting one of the two versions, please ask yourself first
> the following question: Which of the two is better understandable wrt
> what it is supposed to do?
Both are beyond understanding; If you want to say 'every other', say it
in clear words: reduce the list by printing only those at even
positions:
(reduce #'(lambda (odd val) (case odd ((nil) (print val) t) (t nil)))
'(t 1 nil 2 t 3) :initial-value nil)
T
NIL
T
NIL
David
·············@gmail.com" <············@gmail.com> writes:
> Both are beyond understanding; If you want to say 'every other', say it
> in clear words: reduce the list by printing only those at even
> positions:
>
> (reduce #'(lambda (odd val) (case odd ((nil) (print val) t) (t nil)))
> '(t 1 nil 2 t 3) :initial-value nil)
Or use this trick:
(mapc (lambda (x y)
(when y (print x)))
'(1 2 3 4 5 6 7 8 9)
'#1=(t nil . #1#))
Pascal Costanza wrote:
> Matthias Buelow wrote:
>
> > I'd present higher-order functions pretty early. Then the learner might
> > come up with something like the following.
> >
> > He'd perhaps write a general purpose utility, which is also useful for
> > future use:
> >
> > (defun step-list (l s f)
> > (let ((o (funcall s l)))
> > (if (car o)
> > (progn
> > (funcall f (car o))
> > (step-list o s f)))))
> >
> > And then he could use it like:
> >
> > (step-list '(1 2 3 4 5 6 7 8 9 10 11 12) #'cddr #'princ)
> >
> > instead of
> >
> > (loop for obj in '(1 2 3 4 5 6 7 8 9 10 11 12) by #'cddr do (princ obj))
> >
> > Granted, the loop is faster to write for a one-shot solution of that
> > kind but as soon as you'd use that construct a second time, the first
> > approach is faster, and easier to understand.
This might be less buggy and more in the (pseudo?) function-oriented
style:
(defun step-list (step-function list)
"The bizarro world's FILTER/REMOVE. Don't question why it always adds
its first element to the result."
(if list
(cons (first list)
(step-list step-function (funcall step-function list)))
nil))
(mapcar #'princ (step-list #'cddr '(1 2 3 4 5 6 7 8 9 10 11 12)))
prints:
1357911
Now, let's keep in mind that if I were a real functional guy, I'd
probably use Series or even Qi instead of bothering with built-in Lisp.
;)
> These two "solutions" are not even remotely similar:
>
> ? (step-list '(t 1 nil 2 t 3) #'cddr #'print)
> NIL
> ? (loop for obj in '(t 1 nil 2 t 3) by #'cddr
> do (print obj))
>
> T
> NIL
> T
> NIL
>
> Now before correcting one of the two versions, please ask yourself first
> the following question: Which of the two is better understandable wrt
> what it is supposed to do?
A few advantages of function-oriented style:
* Debugging: tools like TRACE
* Debugging: unreadability of macroexpanded LOOPs.
* Maybe less messing around with state... though the statefulness of
LOOP may be overestimated.
Some disadvantages:
* Recursion may mix the looping mechanisms messily into the normal
code.
* You often keep naming things to recurse on them, which leads to
problems if you keep renaming things and don't use some Leitao-ish
refactoring browser.
* Is function-oriented programming a readability silver bullet? When
things get big 'n nasty, does it stay pristine?
* Is it general? If not, there's a testing burden for each little util
you write.
* May require one to combine multiple concepts like IF, PROGN, FUNCALL
and CAR, as in Matthias's example above.
* May have (tail) recursion problems.
* Is so hot with multiple datatypes? Well, maybe there's some CLOS
solution.
Tayssir
Tayssir John Gabbour wrote:
> A few advantages of function-oriented style:
> * Debugging: tools like TRACE
> * Debugging: unreadability of macroexpanded LOOPs.
> * Maybe less messing around with state... though the statefulness of
> LOOP may be overestimated.
One more advantage:
If you think of programming as some kind of verb-object relationship,
you can write clearer code since you can name the verbs. With things
like LOOP (or DO, etc.) the verbs are unexpressive; they are "LOOP" and
its clause keywords, or "DO", etc. The meaning has to be inferred by
the naming of objects (symbol names) alone. With functional
programming, the verbs (often) get proper names that describe what
operation they perform (if the programmer cares about good naming
discipline).
mkb.
Tayssir John Gabbour wrote:
> This might be less buggy and more in the (pseudo?) function-oriented
> style:
>
> (defun step-list (step-function list)
> "The bizarro world's FILTER/REMOVE. Don't question why it always adds
> its first element to the result."
> (if list
> (cons (first list)
> (step-list step-function (funcall step-function list)))
> nil))
This is not tail-recursive. In each recursion, CONS will wait for its
arguments to return values.
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Pascal Costanza wrote:
> Tayssir John Gabbour wrote:
> > This might be less buggy and more in the (pseudo?) function-oriented
> > style:
> >
> > (defun step-list (step-function list)
> > "The bizarro world's FILTER/REMOVE. Don't question why it always adds
> > its first element to the result."
> > (if list
> > (cons (first list)
> > (step-list step-function (funcall step-function list)))
> > nil))
>
> This is not tail-recursive. In each recursion, CONS will wait for its
> arguments to return values.
Yes, but if you're teaching SICP4CL and don't want the conceptual
overhead of LOOP, then why would you add the conceptual overhead of
adding something like an accumulator for tail recursion?
(defun step-list-uglier (step-function list)
(labels ((step-list-helper (list accumulator)
(if list
(step-list-helper (funcall step-function list)
(cons (first list) accumulator))
(nreverse accumulator))))
(step-list-helper list nil)))
Since you're teaching aesthetics and not programming, you won't teach
tail recursion. Because it makes little sense unless you're visualizing
some invisible process in the sourcecode. So we're back to old
non-tail-recursive STEP-LIST.
Tayssir John Gabbour wrote:
>
> Now, let's keep in mind that if I were a real functional guy, I'd
> probably use Series or even Qi instead of bothering with built-in Lisp.
> ;)
>
The ideas in SERIES interests me though I have not used it.
Here is my slightly different way of writing step-list. This
kind of approach is used in the LW PARSERGEN Package and CL-YACC,
where the generator-function below acts like the lexer.
(defun mapgen (mapping-function generator-function)
"Map a function with a generator. Generator functions
need to return the same number of VALUES as the mapping-function
has args. When a generator-function has no more values it needs
to return (VALUES)"
(prog ((result nil))
next
(let ((generation (multiple-value-list (funcall generator-function))))
(if generation
(push (apply mapping-function generation) result)
(return-from mapgen (nreverse result))))
(go next)))
(defun every-second-element (list)
(lambda ()
(if list
(prog1 (car list)
(setf list (cddr list)))
(values))))
(defun step-list (list)
(mapgen #'print (every-second-element list)))
CL-USER 19 > (step-list '(t 1 nil 2 t 3))
T
NIL
T
(T NIL T)
Wade
Pascal Costanza wrote:
> the following question: Which of the two is better understandable wrt
> what it is supposed to do?
Of course the above is a trivial example. If you look at Ulrich's
original loop (as posted in his original posting that started this
thread) the scene is a lot different. 1-clause loops are simple and
easy to understand; it's the loops that use many clauses that soon
degenerate into an incomprehensible mess.
mkb.
Matthias Buelow wrote:
> Pascal Costanza wrote:
>
>>the following question: Which of the two is better understandable wrt
>>what it is supposed to do?
>
> Of course the above is a trivial example. If you look at Ulrich's
> original loop (as posted in his original posting that started this
> thread) the scene is a lot different. 1-clause loops are simple and
> easy to understand; it's the loops that use many clauses that soon
> degenerate into an incomprehensible mess.
Speak for yourself. I haven't had any serious problems understanding
Ulrich's LOOP, and others who actually discussed it didn't seem to either.
The only messy code so far in this thread is your recursive step-list.
So you have not only not backed your claims with actual evidence or some
good rationale, you have even provided an actual counter example to your
own claims.
There is a broad range of cases where LOOP is concise, clearly expresses
what is happening, and furthermore produces efficient code. LOOP takes
some time to understand, but it's worth it. To me, these look like very
good reasons to explain it to people who may be interested.
If you have good reasons for abandoning LOOP, you should actually start
to present them.
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Pascal Costanza wrote:
> Matthias Buelow wrote:
>
>> Pascal Costanza wrote:
>>
>>> the following question: Which of the two is better understandable wrt
>>> what it is supposed to do?
>>
>>
>> Of course the above is a trivial example. If you look at Ulrich's
>> original loop (as posted in his original posting that started this
>> thread) the scene is a lot different. 1-clause loops are simple and
>> easy to understand; it's the loops that use many clauses that soon
>> degenerate into an incomprehensible mess.
>
>
> Speak for yourself. I haven't had any serious problems understanding
> Ulrich's LOOP, and others who actually discussed it didn't seem to either.
Speak for yourself yourself. :) We understood it, but it was horrid,
which is why Ulrich asked for input. In an act of typical cll savagery I
asked about the overall algorithm, and Ulrich obtained nice gains in
readability by reworking the bigger picture.
Exercise for the reader Mathias: rewrite the original as DO or DO*.
Contrast and compare.
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"If you plan to enter text which our system might consider to be
obscene, check here to certify that you are old enough to hear the
resulting output." -- Bell Labs text-to-speech interactive Web page
Kenny Tilton wrote:
>
>
> Pascal Costanza wrote:
>
>> Matthias Buelow wrote:
>>
>>> Pascal Costanza wrote:
>>>
>>>> the following question: Which of the two is better understandable wrt
>>>> what it is supposed to do?
>>>
>>> Of course the above is a trivial example. If you look at Ulrich's
>>> original loop (as posted in his original posting that started this
>>> thread) the scene is a lot different. 1-clause loops are simple and
>>> easy to understand; it's the loops that use many clauses that soon
>>> degenerate into an incomprehensible mess.
>>
>> Speak for yourself. I haven't had any serious problems understanding
>> Ulrich's LOOP, and others who actually discussed it didn't seem to
>> either.
>
> Speak for yourself yourself. :) We understood it, but it was horrid,
> which is why Ulrich asked for input.
I didn't claim it was especially beautiful... ;)
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Pascal Costanza wrote:
> If you have good reasons for abandoning LOOP, you should actually start
> to present them.
Why should I justify _not_ using it to anyone? I don't say that you
should stop using it. I only say that I don't recommend using it.
This whole thread must be quite bizarre for any outsider; I mean, I can
imagine that arguments like this were made already 20 years ago.
Thankfully I'm not dependent on Common Lisp programming (or other
people's LOOP-infested code), so this whole thing is to me, like someone
else already described it, a "pet peeve".
mkb.
Matthias Buelow wrote:
>>If you have good reasons for abandoning LOOP, you should actually start
>>to present them.
>
> Why should I justify _not_ using it to anyone?
You wrote:
[...] if I were to redesign [Common Lisp],
LOOP would be the first to go.
This is 'abandoning' LOOP. Now, are you objecting to
us insisting that you justify your position?
Paul
Paul F. Dietz wrote:
> Matthias Buelow wrote:
>
>>> If you have good reasons for abandoning LOOP, you should actually start
>>> to present them.
>>
>>
>> Why should I justify _not_ using it to anyone?
>
>
> You wrote:
>
> [...] if I were to redesign [Common Lisp],
> LOOP would be the first to go.
>
> This is 'abandoning' LOOP. Now, are you objecting to
> us insisting that you justify your position?
If he doesn't object, I will. "LOOP sucks" isn't a breathtaking new
theory which should require the marshalling of great bodies of evidence
and a spirited defense. It's a sentiment which has been shared and
credibly defended over the decades by various Lisp hackers of high
repute. If you want to know what they said about it, you're free to read
the aforementioned Graham, to peruse The Art of the Interpreter or to
use your favourite search engine to see more reasoning used by those who
hold the opinion.
There is likely nothing new or interesting to be gained by asking the
holder of such a commonly held opinion why he holds it. "LOOP rocks" is
also a common sentiment, one whose defenders' evidence has been on
display for just as long. Pick a camp, and agree to disagree.
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon wrote:
> If he doesn't object, I will. "LOOP sucks" isn't a breathtaking new
> theory which should require the marshalling of great bodies of evidence
> and a spirited defense. It's a sentiment which has been shared and
> credibly defended over the decades by various Lisp hackers of high
> repute. If you want to know what they said about it, you're free to read
> the aforementioned Graham, to peruse The Art of the Interpreter or to
> use your favourite search engine to see more reasoning used by those who
> hold the opinion.
What are the search terms to use to find these numerous reasonings? I
have only found one: http://www.paulgraham.com/loop.html - which seems
to suggest that they have just aimed very high and haven't reached all
their goals. I can live with that.
At last year's European Lisp and Scheme Workshop, the great majority
admitted to use LOOP regularly. (Sven-Olof Nystroem asked the 40
participants to raise their hands for several iteration constructs. LOOP
seems to be strongly favored over other constructs by that "sample
group". And they didn't seem to be unhappy about it.)
"The Art of the Interpreter" doesn't talk about LOOP.
> There is likely nothing new or interesting to be gained by asking the
> holder of such a commonly held opinion why he holds it. "LOOP rocks" is
> also a common sentiment, one whose defenders' evidence has been on
> display for just as long. Pick a camp, and agree to disagree.
We are not just discussing which camp to pick. If this were all this is
about, I wouldn't mind.
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Pascal Costanza <··@p-cos.net> writes:
> Cameron MacKinnon wrote:
>
>> If he doesn't object, I will. "LOOP sucks" isn't a breathtaking new
>> theory which should require the marshalling of great bodies of
>> evidence and a spirited defense. It's a sentiment which has been
>> shared and credibly defended over the decades by various Lisp
>> hackers of high repute. If you want to know what they said about it,
[...]
> What are the search terms to use to find these numerous reasonings? I
You may try something like this with Google:
knee-jerk anti-loopism lisp
which should return references to discussions on LOOP during ANSI
Common Lisp standardization. See for example:
Knee-jerk Anti-LOOPism and other E-mail Phenomena:
Oral, Written, and Electronic Patterns in Computer-Mediated Communication
http://ccs.mit.edu/papers/CCSWP150.html
The ANSI CL working group mailing list archives should provide more
in depth material.
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Paul F. Dietz wrote:
> Matthias Buelow wrote:
>
>>> If you have good reasons for abandoning LOOP, you should actually start
>>> to present them.
>>
>>
>> Why should I justify _not_ using it to anyone?
>
>
> You wrote:
>
> [...] if I were to redesign [Common Lisp],
> LOOP would be the first to go.
>
> This is 'abandoning' LOOP. Now, are you objecting to
> us insisting that you justify your position?
Hey, this is a generally intelligent thread, no "gotcha" games over an
obvious bit of hyperbowl, please.
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"If you plan to enter text which our system might consider to be
obscene, check here to certify that you are old enough to hear the
resulting output." -- Bell Labs text-to-speech interactive Web page
Paul F. Dietz wrote:
> This is 'abandoning' LOOP. Now, are you objecting to
> us insisting that you justify your position?
That's a purely hypothetical context; as for the reason, I think it's
redundant and horrible, is that enough?
[Of course LOOP would be joined by pathnames, and other cruft. I don't
want to go into detail in fear of opening more fronts here and it's
purely hypothetical anyways. I don't really care either.]
mkb.
Matthias Buelow wrote:
> Paul F. Dietz wrote:
>> Matthias Buelow wrote:
>>> [...] if I were to redesign [Common Lisp],
>>> LOOP would be the first to go.
>>
>> This is 'abandoning' LOOP. Now, are you objecting to
>> us insisting that you justify your position?
>
> That's a purely hypothetical context; as for the reason, I think it's
> redundant and horrible, is that enough?
>
> [Of course LOOP would be joined by pathnames, and other cruft. I don't
> want to go into detail in fear of opening more fronts here and it's
> purely hypothetical anyways. I don't really care either.]
First LOOP, then pathnames, then "Why not the Jews?" I think we all
know where this reasoning leads.
Unfortunately, you're posting this from a .de address, making this
comment heavier than I intend...
Tayssir John Gabbour wrote:
>>[Of course LOOP would be joined by pathnames, and other cruft. I don't
>>want to go into detail in fear of opening more fronts here and it's
>>purely hypothetical anyways. I don't really care either.]
>
> First LOOP, then pathnames, then "Why not the Jews?" I think we all
> know where this reasoning leads.
The point is that pathnames are (imho) a remnant from, and stuck in, the
80ies (like so many things in Common Lisp). Today, I'd probably use URIs
as strings, together with a library for constructing them and taking
them apart in all possible ways, and doing mappings from/to the
underlying system's convention.
> Unfortunately, you're posting this from a .de address, making this
> comment heavier than I intend...
Maybe you (subconsciously) just wanted to invoke Hitler in order to end
this thread instantly, as is customary on Usenet.
mkb.
Matthias Buelow wrote:
> Tayssir John Gabbour wrote:
> >>[Of course LOOP would be joined by pathnames, and other cruft. I don't
> >>want to go into detail in fear of opening more fronts here and it's
> >>purely hypothetical anyways. I don't really care either.]
> >
> > First LOOP, then pathnames, then "Why not the Jews?" I think we all
> > know where this reasoning leads.
>
> The point is that pathnames are (imho) a remnant from, and stuck in, the
> 80ies (like so many things in Common Lisp). Today, I'd probably use URIs
> as strings, together with a library for constructing them and taking
> them apart in all possible ways, and doing mappings from/to the
> underlying system's convention.
>
> > Unfortunately, you're posting this from a .de address, making this
> > comment heavier than I intend...
>
> Maybe you (subconsciously) just wanted to invoke Hitler in order to end
> this thread instantly, as is customary on Usenet.
I don't care, though I suspect you feel attacked by the conversation
here. Which I hope is not the case. (But the net is depersonalizing.)
Perhaps you perceive people being fundamentalist on what seems to be a
trivial issue; but there's more than meets the eye about LOOP.
For some people, seeing the good in LOOP is something like a backlash
against the fundamentalist, aesthetic ideologies which plague the
computing world.
Further, there's this rather maddening stigma Lisp has as being all
about functions+lists. It's a real timewaster for many.
Someone on this thread once explained to me that a person's reaction to
LOOP tells you something about her. ;) I think there's a lot to that
idea. Not that LOOP is perfect or another religion, but rather that
person at least has passed one or two ideological obstacles.
But who knows. This is a little thing in many ways.
Tayssir
Tayssir John Gabbour wrote:
> Someone on this thread once explained to me that a person's reaction to
> LOOP tells you something about her. ;) I think there's a lot to that
> idea. Not that LOOP is perfect or another religion, but rather that
> person at least has passed one or two ideological obstacles.
So what you basically claim is that someone who likes loop is on an
intellectually higher level than someone who doesn't.
mkb.
Matthias Buelow wrote:
> Tayssir John Gabbour wrote:
>
> > Someone on this thread once explained to me that a person's reaction to
> > LOOP tells you something about her. ;) I think there's a lot to that
> > idea. Not that LOOP is perfect or another religion, but rather that
> > person at least has passed one or two ideological obstacles.
>
> So what you basically claim is that someone who likes loop is on an
> intellectually higher level than someone who doesn't.
No, that's how you read things, because you have an ideological
worldview. It's very telling that you mentally twisted my words to
include the concept of "intellect," which was not there before. You
seem to value this higher-order, symbolic thinking highly.
Which fits directly in the psychological model of LOOP-acceptance that
was explained to me.
I recommend this video from Alan Kay (skipping over the first half):
http://www.archive.org/details/AlanKeyD1987_2
"Tayssir John Gabbour" <···········@yahoo.com> writes:
> Which fits directly in the psychological model of LOOP-acceptance that
> was explained to me.
LOOPers are doers - they get things done
but DOers are loopers - the loop around in their ideological threadmill
;-)
--
(espen)
Tayssir John Gabbour wrote:
>>>Someone on this thread once explained to me that a person's reaction to
>>>LOOP tells you something about her. ;) I think there's a lot to that
>>>idea. Not that LOOP is perfect or another religion, but rather that
>>>person at least has passed one or two ideological obstacles.
>>
>>So what you basically claim is that someone who likes loop is on an
>>intellectually higher level than someone who doesn't.
>
> No, that's how you read things, because you have an ideological
> worldview. It's very telling that you mentally twisted my words to
> include the concept of "intellect," which was not there before.
Sorry, I was just trying to make sense of your words and hence
reformulated what I thought was your point in a way I understood it, in
order to verify it with you. I probably got it wrong.
> You
> seem to value this higher-order, symbolic thinking highly.
Yes, indeed.
mkb.
Matthias Buelow wrote:
> Tayssir John Gabbour wrote:
> >>>Someone on this thread once explained to me that a person's reaction to
> >>>LOOP tells you something about her. ;) I think there's a lot to that
> >>>idea. Not that LOOP is perfect or another religion, but rather that
> >>>person at least has passed one or two ideological obstacles.
> >>
> >>So what you basically claim is that someone who likes loop is on an
> >>intellectually higher level than someone who doesn't.
> >
> > No, that's how you read things, because you have an ideological
> > worldview. It's very telling that you mentally twisted my words to
> > include the concept of "intellect," which was not there before.
>
> Sorry, I was just trying to make sense of your words and hence
> reformulated what I thought was your point in a way I understood it, in
> order to verify it with you. I probably got it wrong.
No problem. Sometimes it seems I have been at times the most
ideological person I've ever met. (After all I'm an American who grew
up in a big city, bombarded since birth by marketing and half-truths.)
And since there are no facial cues on the low-bandwidth net, I keep
wondering if I've offended someone. ("Did Pascal take that as
unfriendly? Hmm, that would suck...")
> > You seem to value this higher-order, symbolic thinking highly.
>
> Yes, indeed.
Since applied psychology (marketing) generally attacks the more
primitive modes of thinking, I personally have sought refuge in
symbolic thinking. Because it is useful. But when I learned about the
sheer power of the other modes, I sought to get them back too.
So the video I recommended mentions a poll, where a mathematician asked
his buddies how they think when they're doing mathematics. Most
actually didn't use symbolic thought; I think visual was the most
common. I recall Einstein said he felt like he was using his muscles; a
visceral feeling.
The problem with modern academic thought in programming languages is
they don't seem to talk about psychology; only marketing departments
do. Yet there is no programming without psychology. Because AI doesn't
fully write our programs yet.
But I think I've strayed from LOOP. ;) Well, maybe there's a visual
advantage with LOOP; instead of defining new function-names, which
serve as a level of indirection because names are pointers, you often
just stick the code itself into the LOOP. LOOP has locality. Without
needing LAMBDA.
Matthias Buelow <···@incubus.de> writes:
> Pascal Costanza wrote:
>
>> If you have good reasons for abandoning LOOP, you should actually start
>> to present them.
>
> Why should I justify _not_ using it to anyone? I don't say that you
> should stop using it. I only say that I don't recommend using it.
There seems a good reason for pursuing the matter. IIRC, you are a
teacher, and have stated that your opinion of LOOP influences your
teaching. Thus your opinion is not merely personal preference; it
will likely be adopted by many of your students. This raises the
stakes a bit.
> This whole thread must be quite bizarre for any outsider; I mean, I can
> imagine that arguments like this were made already 20 years ago.
Probably not, if the outsider is a programmer who's passionate about
some language. Similar debates over language features are legion on
the net.
Dan Muller wrote:
> There seems a good reason for pursuing the matter. IIRC, you are a
> teacher, and have stated that your opinion of LOOP influences your
> teaching. Thus your opinion is not merely personal preference; it
No, I'm not. Lisp is nothing but a hobby for me.
mkb.
Matthias Buelow wrote:
> Pascal Costanza wrote:
>
>>If you have good reasons for abandoning LOOP, you should actually start
>>to present them.
>
> Why should I justify _not_ using it to anyone? I don't say that you
> should stop using it. I only say that I don't recommend using it.
You have suggested to hide LOOP from newbies and to remove it from the
standard if this were possible. That goes a little bit further than just
not using it yourself, and should therefore be more substantially
justified. [1]
Apart from that: Go ahead, do what you like. Noone forces you to use LOOP.
Pascal
[1] Especially because the Common-Lisp-like dialect that doesn't have
LOOP already exists!
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Pascal Costanza wrote:
> You have suggested to hide LOOP from newbies and to remove it from the
> standard if this were possible. That goes a little bit further than just
> not using it yourself, and should therefore be more substantially
> justified. [1]
Somehow I feel like if I had suggested that GOTO be banished from
whatever Fortran was present at that time. "But it's oh-so practical."
mkb.
Matthias Buelow <···@incubus.de> writes:
> Pascal Costanza wrote:
>
> > You have suggested to hide LOOP from newbies and to remove it from the
> > standard if this were possible. That goes a little bit further than just
> > not using it yourself, and should therefore be more substantially
> > justified. [1]
>
> Somehow I feel like if I had suggested that GOTO be banished from
> whatever Fortran was present at that time. "But it's oh-so practical."
First you argue from the point of view that "of course" LOOP is bad,
and that doesn't need any real defense, and now you do the same with
GO! If you really feel that LAMBDA is the ultimate everything, what
are you doing in c.l.l?
For the record, anyone who wants to argue here against TAGBODY/GO/PROG
had better back themselves up with real arguments, not snarky asides.
You might want to start by considering the arguments in "Structured
programming with go to statements."
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
>>Somehow I feel like if I had suggested that GOTO be banished from
>>whatever Fortran was present at that time. "But it's oh-so practical."
>
> First you argue from the point of view that "of course" LOOP is bad,
> and that doesn't need any real defense, and now you do the same with
> GO! If you really feel that LAMBDA is the ultimate everything, what
> are you doing in c.l.l?
Please note that, with the exception of LOOP, I argued against no such
thing.
mkb.
Matthias Buelow <···@incubus.de> writes:
> Thomas F. Burdick wrote:
>
> >>Somehow I feel like if I had suggested that GOTO be banished from
> >>whatever Fortran was present at that time. "But it's oh-so practical."
> >
> > First you argue from the point of view that "of course" LOOP is bad,
> > and that doesn't need any real defense, and now you do the same with
> > GO! If you really feel that LAMBDA is the ultimate everything, what
> > are you doing in c.l.l?
>
> Please note that, with the exception of LOOP, I argued against no such
> thing.
If that quoted text of yours at the top of this message wasn't
supposed to be arguing against GO, it's certainly easy to misinterpret
it that way. I still don't see any other way to take it, but if you
say you're not arguing against GO, okay...
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
> For the record, anyone who wants to argue here against TAGBODY/GO/PROG
> had better back themselves up with real arguments, not snarky asides.
> You might want to start by considering the arguments in "Structured
> programming with go to statements."
Seemingly noone is arguing against GO (GOTO), but considering the rest
of the thread it's nevertheless appropriate to cite one of my favorite
quotes:
"It has been suggested that certain programming language constructs, in
particular GO TO, lend themselves to obscure coding practices. Some
language designers have even gone so far as to design languages which
purposely omit such familiar constructs as GO TO in an attempt to
constrain the programmer to refrain from particular styles of
programming thought by the language designer to be "bad" in some sense.
But any language with function calls, functional values, conditionals,
correct handling of tail-recursion, and lexical scoping can simulate
such "non-structured" constructs as GO TO statements, call-by-name, and
fluid variables in a _straightforward_ manner. If the language also has
a macro processor or preprocessor, these simulations will even be
convenient to use.
"No amount of language design can _force_ a programmer to write clear
programs. If the programmer's conception of the problem is badly
organized, then his program will also be badly organized. The extent to
which a programming language can help a programmer to organize his
problem is precisely the extent to which it provides features
appropriate to his problem domain. The emphasis should not be on
eliminating "bad" language constructs, but on discovering or inventing
helpful ones."
--- Guy L. Steele, Gerald J. Sussman, "Lambda - The Ultimate Imperative"
See http://library.readscheme.org/page1.html
To which one could add a quote by Kent M. Pitman: "A discussion that
tries to kill a useful feature is not a "practical" discussion but a
"religious" one."
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Pascal Costanza wrote:
> To which one could add a quote by Kent M. Pitman: "A discussion that
> tries to kill a useful feature is not a "practical" discussion but a
> "religious" one."
Abusing Voltaire, a witty quote proves nothing. That aside, there seems
to be a traditional bias among a certain part of Lisp developers that
the more features, the better. That probably isn't what everyone would
agree on (I surely don't.) Redundant features are often just unnecessary
clutter, for example.
mkb.
Pascal Costanza wrote:
> Thomas F. Burdick wrote:
>
>> For the record, anyone who wants to argue here against
>> TAGBODY/GO/PROG had better back themselves up with real arguments,
>> not snarky asides. You might want to start by considering the
>> arguments in "Structured programming with go to statements."
How about some empirical evidence?
·······@fog:~$ ls /usr/share/common-lisp/source/|wc -l
121
There's 121 CL packages on my machine in /usr/share, none of them by me.
·······@fog:~$ find /usr/share/common-lisp/source/ -name '*.lisp'|xargs
grep -li 'tagbody'|sed
's|^/usr/share/common-lisp/source/||;s|/.*$||'|uniq|wc -l
18
Fewer than 1/6 of them use tagbody. Here's the list of the ones that do:
cl-ppcre cmucl odcl screamer
puri cmucl-hemlock paip series
acl-compat cmucl-clx postoffice slime
clx mcclim reversi
iterate cl-menusystem cl-salza
Some of these, it can be assumed, only "use" tagbody because they have
to support all of CL's constructs, and tagbody is one of them. Should
they count?
Peter Siebel's PCL was proofread by many on c.l.l, and the c.l.l
consensus is a positive one. What does it say about tagbody/go?
"rarely used directly... It's handy, however, for translating algorithms
written ... before the structured programming revolution"
That quote is heavily edited, but I trust nobody will say that I've
changed the meaning of what Peter said.
Conclusion: Most people wouldn't miss this structure if access to it
went away.
>
>
> Seemingly noone is arguing against GO (GOTO), but considering the
> rest of the thread it's nevertheless appropriate to cite one of my
> favorite quotes:
>
> "It has been suggested that certain programming language constructs,
> in particular GO TO, lend themselves to obscure coding practices.
> Some language designers have even gone so far as to design languages
> which purposely omit such familiar constructs as GO TO in an attempt
> to constrain the programmer to refrain from particular styles of
> programming thought by the language designer to be "bad" in some
> sense. But any language with function calls, functional values,
> conditionals, correct handling of tail-recursion, and lexical scoping
> can simulate such "non-structured" constructs as GO TO statements,
> call-by-name, and fluid variables in a _straightforward_ manner. If
> the language also has a macro processor or preprocessor, these
> simulations will even be convenient to use.
>
> "No amount of language design can _force_ a programmer to write clear
> programs. If the programmer's conception of the problem is badly
> organized, then his program will also be badly organized. The extent
> to which a programming language can help a programmer to organize his
> problem is precisely the extent to which it provides features
> appropriate to his problem domain. The emphasis should not be on
> eliminating "bad" language constructs, but on discovering or
> inventing helpful ones."
>
> --- Guy L. Steele, Gerald J. Sussman, "Lambda - The Ultimate
> Imperative"
Boiled down, the above states that it's possible to write ugly code in
any language. Big deal. The real question was: Can a given mix of
control constructs make it easier or more difficult to write aesthetic
code than another mix? Few would argue that the "structured programming
revoultion" was harmful.
> To which one could add a quote by Kent M. Pitman: "A discussion that
> tries to kill a useful feature is not a "practical" discussion but a
> "religious" one."
If everyone agrees on the meaning of the word "useful", this reduces to
a tautology. If they don't, it's meaningless.
If ten percent of the users of a feature use it well, but the other
ninety percent botch it and write difficult to read, difficult to
maintain or buggy code, is that feature "useful"? One could easily argue
that on a net basis, economically, the entire community would have been
better off without it. I think it's indisputable that different
structural features have different levels of ease of use/abuse. I don't
think it's helpful at all, from the standpoint of improving overall
software quality, to merely declare misusers of features incompetent.
Easily misused features must share some of the blame.
Theorem: You can tell more about an enlightened programmer by his
attitudes toward LOOP and CALL/CC than by asking him any two other
simple questions.
In another post, I said:
> "LOOP rocks" is also a common sentiment, one whose defenders'
> evidence has been on display for just as long.
I'd like to retract that. In skimming eldersexprhackers' views on LOOP,
I found a number of expressions of disgust, but few unqualified
expressions of love. LOOP's defenders often damned it with faint praise
or equivocal justifications.
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon wrote:
> Pascal Costanza wrote:
>
>> Thomas F. Burdick wrote:
>>
>>> For the record, anyone who wants to argue here against
>>> TAGBODY/GO/PROG had better back themselves up with real arguments,
>>> not snarky asides. You might want to start by considering the
>>> arguments in "Structured programming with go to statements."
>
> How about some empirical evidence?
[...]
> Conclusion: Most people wouldn't miss this structure if access to it
> went away.
I don't care. I had one very good need for it in one project, and I am
thankful that it was available.
>> Seemingly noone is arguing against GO (GOTO), but considering the rest
>> of the thread it's nevertheless appropriate to cite one of my favorite
>> quotes:
>>
>> "It has been suggested that certain programming language constructs,
>> in particular GO TO, lend themselves to obscure coding practices. Some
>> language designers have even gone so far as to design languages which
>> purposely omit such familiar constructs as GO TO in an attempt to
>> constrain the programmer to refrain from particular styles of
>> programming thought by the language designer to be "bad" in some
>> sense. But any language with function calls, functional values,
>> conditionals, correct handling of tail-recursion, and lexical scoping
>> can simulate such "non-structured" constructs as GO TO statements,
>> call-by-name, and fluid variables in a _straightforward_ manner. If
>> the language also has a macro processor or preprocessor, these
>> simulations will even be convenient to use.
>>
>> "No amount of language design can _force_ a programmer to write clear
>> programs. If the programmer's conception of the problem is badly
>> organized, then his program will also be badly organized. The extent
>> to which a programming language can help a programmer to organize his
>> problem is precisely the extent to which it provides features
>> appropriate to his problem domain. The emphasis should not be on
>> eliminating "bad" language constructs, but on discovering or inventing
>> helpful ones."
>>
>> --- Guy L. Steele, Gerald J. Sussman, "Lambda - The Ultimate Imperative"
>
> Boiled down, the above states that it's possible to write ugly code in
> any language. Big deal. The real question was: Can a given mix of
> control constructs make it easier or more difficult to write aesthetic
> code than another mix?
I don't think it's possible to design a language with a restricted set
of features in such a way that all or even most source code will look
beautiful. Guy Steele strongly supports the notion of growable
languages, and in such a growable language your question doesn't make sense.
> Few would argue that the "structured programming
> revoultion" was harmful.
Given that "structured programming" implies abandoning GOTO, I think
that this is the very essence of that quote.
>> To which one could add a quote by Kent M. Pitman: "A discussion that
>> tries to kill a useful feature is not a "practical" discussion but a
>> "religious" one."
>
> If everyone agrees on the meaning of the word "useful", this reduces to
> a tautology. If they don't, it's meaningless.
...unless you learn to accept that other people's notion of "usefulness"
may differ from yours.
> If ten percent of the users of a feature use it well, but the other
> ninety percent botch it and write difficult to read, difficult to
> maintain or buggy code, is that feature "useful"?
Yes, absolutely! (90% find Lisp itself difficult to read, difficult to
maintain, etc. Are you arguing against Lisp here?)
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Cameron MacKinnon <··········@clearspot.net> wrote on Tue, 07 Jun 2005:
> If ten percent of the users of a feature use it well, but the other
> ninety percent botch it and write difficult to read, difficult to
> maintain or buggy code, is that feature "useful"?
The expectation is more that 10% of users would find the feature invaluable,
while the other 90% would basically ignore it as uninteresting.
It's rare that the addition of a feature actively causes most programs to
get worse. A programmer always has the option of using the subset of the
language without that additional feature. Whereas, if you removed it from
the language, the 10% of programmers who find the feature critical don't
have a good replacement option.
> Theorem: You can tell more about an enlightened programmer by his
> attitudes toward LOOP and CALL/CC than by asking him any two other
> simple questions.
Interesting conjecture. You may be right that this sharply divides people
into two camps. I wonder what conclusion you want to draw from the two camps,
though.
For the record: I love LOOP (and use it frequently, in simple forms at
least), while I've never been motivated to use a CALL/CC style.
> In another post, I said:
>> "LOOP rocks" is also a common sentiment, one whose defenders' evidence has
>> been on display for just as long.
> I'd like to retract that. In skimming eldersexprhackers' views on LOOP,
> I found a number of expressions of disgust, but few unqualified
> expressions of love. LOOP's defenders often damned it with faint praise
> or equivocal justifications.
I may not count as one of your "eldersexprhackers", but I love LOOP.
I'd be very frustrated expressing iteration if it were removed from the
language.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
The question of whether a computer can think is no more interesting than the
question of whether a submarine can swim. -- Edsger W. Dijkstra
Don Geddis wrote:
> For the record: I love LOOP (and use it frequently, in simple forms at
> least), while I've never been motivated to use a CALL/CC style.
What does one have to do with the other? You can position call/cc
against tagbody & go but you probably could just aswell build loop on
top of call/cc like it apparently is being done on tagbody & go (of
course it's a bit hard to imagine that any sobre Scheme user would want
to implement loop ;).
mkb.
I wrote:
>> For the record: I love LOOP (and use it frequently, in simple forms at
>> least), while I've never been motivated to use a CALL/CC style.
Matthias Buelow <···@incubus.de> wrote on Thu, 09 Jun 2005:
> What does one have to do with the other?
Nothing at all.
> You can position call/cc against tagbody & go but you probably could just
> aswell build loop on top of call/cc like it apparently is being done on
> tagbody & go
I quoted the text I was responding to, immediately above my reply. You,
in turn, quoted my reply, but edited out the text to which it was a response.
That text was:
>>> Theorem: You can tell more about an enlightened programmer by his
>>> attitudes toward LOOP and CALL/CC than by asking him any two other
>>> simple questions.
Now that my reply is back in context, you can see that nobody was making a
technical connection between LOOP and CALL/CC. Instead, these were intended
to be two independent observations on programmer desires. (I suspect there
is an expectation that those who like LOOP don't like CALL/CC, and vis versa.
But that doesn't mean there is a technical connection between the concepts.)
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
I hope that someday we will be able to put away our fears and prejudices and
just laugh at people. -- Deep Thoughts, by Jack Handey
Don Geddis wrote:
> Now that my reply is back in context, you can see that nobody was making a
> technical connection between LOOP and CALL/CC. Instead, these were intended
> to be two independent observations on programmer desires. (I suspect there
> is an expectation that those who like LOOP don't like CALL/CC, and vis versa.
> But that doesn't mean there is a technical connection between the concepts.)
Yes, I see. But I don't think the predilection towards loop xor call/cc,
as preferrable language features, is true. Maybe Common Lisp + loop vs.
Scheme + call/cc. I'd think the typical "I like features" Common Lisp
programmer wouldn't mind if call/cc popped up somewhere on the feature
list. I'd personally like call/cc in Lisp but I'm aware that it seems to
pose conflicts with certain existing constructs.
mkb.
Matthias Buelow wrote:
> Don Geddis wrote:
>
>>Now that my reply is back in context, you can see that nobody was making a
>>technical connection between LOOP and CALL/CC. Instead, these were intended
>>to be two independent observations on programmer desires. (I suspect there
>>is an expectation that those who like LOOP don't like CALL/CC, and vis versa.
>>But that doesn't mean there is a technical connection between the concepts.)
>
> Yes, I see. But I don't think the predilection towards loop xor call/cc,
> as preferrable language features, is true. Maybe Common Lisp + loop vs.
> Scheme + call/cc. I'd think the typical "I like features" Common Lisp
> programmer wouldn't mind if call/cc popped up somewhere on the feature
> list. I'd personally like call/cc in Lisp but I'm aware that it seems to
> pose conflicts with certain existing constructs.
No, it wouldn't. From a recent discussion here, it seems to me that on a
conceptual level, it would be much easier to add call/cc to Common Lisp
than to add unwind-protect to Scheme. However, call/cc has performance
impliciations (CPUs give you only one fast stack), and may lead to
problems when interacting with foreign code that isn't aware of call/cc,
IIUC.
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Why do you say that it would be easier to add call/cc to lisp than it
would be to add unwind-protect to scheme?
I ask because I read a paper a while back
http://repository.readscheme.org/ftp/papers/sw2003/Unwind.pdf&ei=iOmoQo-IK5iIaJ6u5PsO&sig2=3nniIntrkOh7EfF5wkbj2Q
that claimed that it was not that hard to implement unwind-protect and
a restricted call/cc in terms of the normal call/cc. I have also heard
references to a theoretical result that claims that any control
structure at all can be implemented in terms of call/cc. Is call/cc in
lisp even easier than that?
···········@gmail.com wrote:
> Why do you say that it would be easier to add call/cc to lisp than it
> would be to add unwind-protect to scheme?
>
> I ask because I read a paper a while back
> http://repository.readscheme.org/ftp/papers/sw2003/Unwind.pdf&ei=iOmoQo-IK5iIaJ6u5PsO&sig2=3nniIntrkOh7EfF5wkbj2Q
>
> that claimed that it was not that hard to implement unwind-protect and
> a restricted call/cc in terms of the normal call/cc. I have also heard
> references to a theoretical result that claims that any control
> structure at all can be implemented in terms of call/cc. Is call/cc in
> lisp even easier than that?
I said "add", not "implement". Implementing unwind-protect in Scheme is
indeed easier than implementing call/cc in Common Lisp. However, this is
only half of the story. You also have to define the interaction with the
rest of the language. When you add unwind-protect to Scheme, you need to
distinguish between escaping and non-escaping continuations in some way,
i.e., continuations that will trigger the protect block and those that
don't. [1] "Legacy" Scheme code doesn't make that distinction, so you
are in trouble and have to make an arbitrary decision whether existing
invocations of call/cc are escaping or not. In Common Lisp, it's already
clear for all existing forms that in some sense invoke continuations
(throw, return-from, signalling conditions and handling them) whether
they are escaping or non-escaping. When you would add call/cc, you would
basically just have to add two versions, an escaping and a non-escaping one.
Pascal
[1] Always triggering it, like in dynamic-wind, is not necessarily
correct because there is no before thunk in unwind-protect.
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Cameron MacKinnon wrote:
>> Thomas F. Burdick wrote:
>>
>>> For the record, anyone who wants to argue here against
>>> TAGBODY/GO/PROG had better back themselves up with real arguments,
>>> not snarky asides. You might want to start by considering the
>>> arguments in "Structured programming with go to statements."
>
>
> How about some empirical evidence?
>
> ·······@fog:~$ ls /usr/share/common-lisp/source/|wc -l
> 121
>
> There's 121 CL packages on my machine in /usr/share, none of them by me.
>
> ·······@fog:~$ find /usr/share/common-lisp/source/ -name '*.lisp'|xargs
> grep -li 'tagbody'|sed
> 's|^/usr/share/common-lisp/source/||;s|/.*$||'|uniq|wc -l
> 18
>
> Fewer than 1/6 of them use tagbody. Here's the list of the ones that do:
> cl-ppcre cmucl odcl screamer
> puri cmucl-hemlock paip series
> acl-compat cmucl-clx postoffice slime
> clx mcclim reversi
> iterate cl-menusystem cl-salza
>
> Some of these, it can be assumed, only "use" tagbody because they have
> to support all of CL's constructs, and tagbody is one of them. Should
> they count?
When using GO directly, I think it is much more common to use it in
conjunction with PROG than TAGBODY, since you often want to introduce
some variables. I sometimes use GO/PROG/MACROLET together.
> If ten percent of the users of a feature use it well, but the other
> ninety percent botch it and write difficult to read, difficult to
> maintain or buggy code, is that feature "useful"?
So which 16 of the above 18 packages are the ones that 'botched' it, and
which 2 are the ones which used it well?
> One could easily argue
> that on a net basis, economically, the entire community would have been
> better off without it. I think it's indisputable that different
> structural features have different levels of ease of use/abuse. I don't
> think it's helpful at all, from the standpoint of improving overall
> software quality, to merely declare misusers of features incompetent.
> Easily misused features must share some of the blame.
So which features in CL are easily misused? Popular candidates might be
EVAL and macros, but certainly not TAGBODY, or?
Bj�rn
Cameron MacKinnon <··········@clearspot.net> writes:
> > Thomas F. Burdick wrote:
> >
> >> For the record, anyone who wants to argue here against
> >> TAGBODY/GO/PROG had better back themselves up with real arguments,
> >> not snarky asides. You might want to start by considering the
> >> arguments in "Structured programming with go to statements."
>
> How about some empirical evidence?
What was this supposed to be empirical evidence of? You can measure
any random thing you want, but all you have is a measurement, not
necessarily a measurement of anything meaningful. And for what its
worth, tagbody is not the only thing that introduces targets for GO;
I'd think it would be more interesting to ask if a given package uses
GO, assuming that the question is meaningful in the first place.
> Fewer than 1/6 of them use tagbody. Here's the list of the ones that do:
> cl-ppcre cmucl odcl screamer
> puri cmucl-hemlock paip series
> acl-compat cmucl-clx postoffice slime
> clx mcclim reversi
> iterate cl-menusystem cl-salza
>
> Some of these, it can be assumed, only "use" tagbody because they have
> to support all of CL's constructs, and tagbody is one of them. Should
> they count?
And what about those that "count"? I would assume that cl-ppcre makes
good use of TAGBODY/GO. And how do you measure the inverse, ie
packages that *should* be using GO, or a custom control-structure
built on top of it, but suffer in both performance and readability
because they don't?
> Peter Siebel's PCL was proofread by many on c.l.l, and the c.l.l
> consensus is a positive one. What does it say about tagbody/go?
>
> "rarely used directly... It's handy, however, for translating algorithms
> written ... before the structured programming revolution"
>
> That quote is heavily edited, but I trust nobody will say that I've
> changed the meaning of what Peter said.
First of all, I wouldn't recommend against a book simply because of a
lukewarm recommendation of a part of the language that it only
glancingly covers. However, in a world where the most absurdly
ultraorthodox variant of structured programming is widely accepted, it
would be counterproductive to spend much time promoting structured
programming with go to statements in a book with the aim that PCL has.
If the Java monkies learn to use macros and generic functions, but
still write loops that amount to obscurely interpreting a TAGBODY,
it's a huge win nonetheless. We ought to be rehabilitating PROG in
the advanced texts.
> Conclusion: Most people wouldn't miss this structure if access to it
> went away.
Even if you had demonstrated that, which you did not, what would be
your point? By the same metrics, I bet you'd find a shocking disdain
for special variables, the condition system, and custom method
combinations. I don't repair my glasses very often, but I would hate
to have to use a hammer to do so, just because someone took my little
screwdriver away, telling me that I hardly ever use it.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
> Cameron MacKinnon <··········@clearspot.net> writes:
> > > Thomas F. Burdick wrote:
> > >> For the record, anyone who wants to argue here against
> > >> TAGBODY/GO/PROG had better back themselves up with real arguments,
> > >> not snarky asides. You might want to start by considering the
> > >> arguments in "Structured programming with go to statements."
> >
> > How about some empirical evidence?
>
> What was this supposed to be empirical evidence of? You can measure
> any random thing you want, but all you have is a measurement, not
> necessarily a measurement of anything meaningful. And for what its
> worth, tagbody is not the only thing that introduces targets for GO;
> I'd think it would be more interesting to ask if a given package uses
> GO, assuming that the question is meaningful in the first place.
I think it was a good starting place, even if there was the GO vs.
TAGBODY misconception. Much better than vague arguments we've seen.
Unfortunately, the GOTO Considered Harmful argument is based on a
falsehood: GOTO was never considered harmful. That is, Dijkstra's
original paper was originally titled, "A Case against the GO TO
Statement," but then the editor (Niklaus Wirth) changed it into the
infamous title. Even Dijkstra chided people for reading no more than
the title, treating it as flamewar ammo.
One newbie used GO/TAGBODY to enjoyably explore state machines.
http://www.findinglisp.com/blog/2004/06/basic-automaton-macro.html
http://www.findinglisp.com/blog/2004/06/automaton-meets-loop.html
> Cameron MacKinnon <··········@clearspot.net> writes:
> > Peter Siebel's PCL was proofread by many on c.l.l, and the c.l.l
> > consensus is a positive one. What does it say about tagbody/go?
You know, my name's acknowledged in that book as helping out, and I
don't remember doing squat for Peter. ;) Draw your own conclusions...
Tayssir
Tayssir John Gabbour wrote:
> Thomas F. Burdick wrote:
> > Cameron MacKinnon <··········@clearspot.net> writes:
> > > > Thomas F. Burdick wrote:
> > > >> For the record, anyone who wants to argue here against
> > > >> TAGBODY/GO/PROG had better back themselves up with real arguments,
> > > >> not snarky asides. You might want to start by considering the
> > > >> arguments in "Structured programming with go to statements."
> > >
> > > How about some empirical evidence?
> >
> > What was this supposed to be empirical evidence of? You can measure
> > any random thing you want, but all you have is a measurement, not
> > necessarily a measurement of anything meaningful. And for what its
> > worth, tagbody is not the only thing that introduces targets for GO;
> > I'd think it would be more interesting to ask if a given package uses
> > GO, assuming that the question is meaningful in the first place.
>
> I think it was a good starting place, even if there was the GO vs.
> TAGBODY misconception. Much better than vague arguments we've seen.
>
> Unfortunately, the GOTO Considered Harmful argument is based on a
> falsehood: GOTO was never considered harmful. That is, Dijkstra's
> original paper was originally titled, "A Case against the GO TO
> Statement," but then the editor (Niklaus Wirth) changed it into the
> infamous title. Even Dijkstra chided people for reading no more than
> the title, treating it as flamewar ammo.
>
> One newbie used GO/TAGBODY to enjoyably explore state machines.
> http://www.findinglisp.com/blog/2004/06/basic-automaton-macro.html
> http://www.findinglisp.com/blog/2004/06/automaton-meets-loop.html
>
>
> > Cameron MacKinnon <··········@clearspot.net> writes:
> > > Peter Siebel's PCL was proofread by many on c.l.l, and the c.l.l
> > > consensus is a positive one. What does it say about tagbody/go?
>
> You know, my name's acknowledged in that book as helping out, and I
> don't remember doing squat for Peter. ;) Draw your own conclusions...
(Let me not overstate things, if it might reflect badly on PCL. I did
test things out early on and offered suggestions.)
Thomas F. Burdick wrote:
> What was this supposed to be empirical evidence of? You can measure
> any random thing you want, but all you have is a measurement, not
> necessarily a measurement of anything meaningful. And for what its
> worth, tagbody is not the only thing that introduces targets for GO;
> I'd think it would be more interesting to ask if a given package uses
> GO, assuming that the question is meaningful in the first place.
Something like TAGBODY is necessary to implement these various
macros that allow go labels, so why not expose it to the user?
Paul
Paul Dietz <············@motorola.com> writes:
> Thomas F. Burdick wrote:
>
> > What was this supposed to be empirical evidence of? You can measure
> > any random thing you want, but all you have is a measurement, not
> > necessarily a measurement of anything meaningful. And for what its
> > worth, tagbody is not the only thing that introduces targets for GO;
> > I'd think it would be more interesting to ask if a given package uses
> > GO, assuming that the question is meaningful in the first place.
>
> Something like TAGBODY is necessary to implement these various
> macros that allow go labels, so why not expose it to the user?
I'm not really sure what you mean by your question. In the
above-quoted text, I was trying (apparently not so effectively) to
point out that simply looking for occurrences of TAGBODY isn't a very
good way to check whether a system makes use of TAGBODY/GO.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
>>Something like TAGBODY is necessary to implement these various
>>macros that allow go labels, so why not expose it to the user?
>
>
> I'm not really sure what you mean by your question.
It wasn't really addressed to you. Sorry for not making
that clear.
Paul
Matthias Buelow wrote:
> Pascal Costanza wrote:
>
>>You have suggested to hide LOOP from newbies and to remove it from the
>>standard if this were possible. That goes a little bit further than just
>>not using it yourself, and should therefore be more substantially
>>justified. [1]
>
> Somehow I feel like if I had suggested that GOTO be banished from
> whatever Fortran was present at that time. "But it's oh-so practical."
GOTO _is_ useful when used judiciously. (For example, in generated code.)
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Matthias Buelow wrote:
> Pascal Costanza wrote:
>
>>>on the fly and feeding them to eval. IMHO new lisp users should start
>>>with recursion for doing loops, and ordinary list functions (mapc,
>>>mapcar, apply, ...), and understand them well, and then use iteration
>>>constructs like do, dolist, and only then get introduced -- with
>>>appropriate warnings -- to the loop facility.
>>
>>Is this a claim, a conjecture, or an empirical assessment? Can you back
>>this with references to existing literature?
>
> It is a conjecture, resulting from applying common sense.
See http://en.wikipedia.org/wiki/Common_sense for an overview of "common
sense".
> Why should
> one teach something that is a) not properly defined, b) ambiguous and c)
> totally different in style and workings than the rest of Common Lisp to
> a new learner of that language, who wants to get a grasp on the
> essentials and the general feeling of the language first, and not on
> its, to put it mildly, fanciful outgrowths.
a) LOOP is properly defined. See the ANSI specification.
b) Show us problems you had with LOOP's purported ambiguities. Maybe
someone can help you.
(I think Ulrich found the original discussion in this thread helpful. Do
you seriously suggest not to respond when someone asks a LOOP-specific
question? Apparently yes, given your original statement in this thread.)
c) It's good to show people that you can mix very different programming
styles in one language. That's the whole idea of a multi-paradigm language.
My impression is that you are an advocate of single-paradigm
programming. This is an arguable position to take, but very problematic
because it has a tendency not to accept diverging positions. You can
find advocates of single-paradigm "right-thing" programming in almost
all camps (functional, object-oriented, logic, imperative, static,
dynamic, etc. pp.). They rarely have good rational arguments, except
that their respectively preferred approach is supposedly "obviously"
superior.
They can't all be true. I think none of them is.
So, yes, I think it's a good idea to show people early on that Common
Lisp doesn't force you at all to think in, or use a certain programming
style.
> If one could inline a subset of BASIC into Common Lisp, because someone
> somewhen deemed that practical for a certain application, would you also
> teach beginners BASIC instead of Lisp?
That's a straw man. Noone claimed to exclusively teach LOOP.
It could make a good case study for showing how to embed a specific
language into Common Lisp, though.
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Pascal Costanza wrote:
> c) It's good to show people that you can mix very different programming
> styles in one language. That's the whole idea of a multi-paradigm language.
The "multi-paradigm" way of programming by using macros to extend the
language makes no sense to someone who hasn't yet understood macros. To
understand how loop (and similar constructs) work, you have to
understand macros. For a beginner, who doesn't yet know (much) about
macros, loop is an opaque puzzle, and he'll probably believe it is
special syntax like in other programming languages and hence gets a
completely wrong picture of the language. The good thing about Lisp is
that it can be taught from the ground up, starting with basic things
like conses, a few primitive operators, functions and recursion, and
building the rest of the language on top of it. That way a beginner
will get a thorough grasp of the language. If you just throw all the
finished stuff at him/her, in a how-to or recipe-style way, imho the
student will be a lot more confused.
mkb.
Matthias Buelow wrote:
> Pascal Costanza wrote:
>
>>c) It's good to show people that you can mix very different programming
>>styles in one language. That's the whole idea of a multi-paradigm language.
>
> The "multi-paradigm" way of programming by using macros to extend the
> language makes no sense to someone who hasn't yet understood macros. To
> understand how loop (and similar constructs) work, you have to
> understand macros. For a beginner, who doesn't yet know (much) about
> macros, loop is an opaque puzzle, and he'll probably believe it is
> special syntax like in other programming languages and hence gets a
> completely wrong picture of the language. The good thing about Lisp is
> that it can be taught from the ground up, starting with basic things
> like conses, a few primitive operators, functions and recursion, and
> building the rest of the language on top of it. That way a beginner
> will get a thorough grasp of the language. If you just throw all the
> finished stuff at him/her, in a how-to or recipe-style way, imho the
> student will be a lot more confused.
I spare my "claim, conjecture, assessment" question this time, and hope
you have read the article about common sense.
I don't think that people learn like you seem to suggest. At least when
learning natural languages, it's better to use a top-down approach than
a bottom-up approach. So first learn how to speak, then how to write,
and finally the grammar and how this all is knitted together. You just
don't start by first explaining the Saphir-Whorf-Hypothesis.
Or compare this to mathematics: The first thing you learned was adding
numbers, not category theory, right?
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Matthias Buelow <···@incubus.de> writes:
> The good thing about Lisp is that it can be taught from the ground
> up, starting with basic things like conses, a few primitive
> operators, functions and recursion, and building the rest of the
> language on top of it. That way a beginner will get a thorough
> grasp of the language. If you just throw all the finished stuff at
> him/her, in a how-to or recipe-style way, imho the student will be a
> lot more confused.
I also happen to think that this is a strong point of lisp. But note
that Practical Common Lisp was not written with the beginning
programmer in mind (as were SICP or HtdP) but with a
medium-experienced programmer who is new to CL. I think it's ok not
to bother these people overly with explaining recursion, functions,
etc before getting to the "practical" stuff.
Esp. since SICP already does an excellent job in teaching programming
with lisp in a more fundamental way.
Matthias Buelow <···@incubus.de> writes:
> Why should
> one teach something that is [blah blah blah]
> to a new learner of that language, who wants to get a grasp on the
> essentials and the general feeling of the language first, [SNIP]
The book is called _Practical_ Common Lisp.
Loop is, well, practical. Heck, some even think it useful!
Paul F. Dietz wrote:
> Doing Scheme in Lisp is another pet peeve of mine, btw.
What I'd like would be something in between Scheme and Common Lisp. Not
as stiff and rigid and puritan as Scheme (for example, I like
dynamically scoped "special" variables and the straightforward Common
Lisp macro system) but not as monstrous and inconsistent and full of
archaeological baggage as Common Lisp. Unfortunately such a thing
doesn't seem to exist. Well, maybe Graham's Arc will go in that
direction, once it's out (I hope he'll make it open source).
mkb.
Matthias Buelow wrote:
> Paul F. Dietz wrote:
>
>
>>Doing Scheme in Lisp is another pet peeve of mine, btw.
>
>
> What I'd like would be something in between Scheme and Common Lisp. Not
> as stiff and rigid and puritan as Scheme (for example, I like
> dynamically scoped "special" variables and the straightforward Common
> Lisp macro system) but not as monstrous and inconsistent and full of
> archaeological baggage as Common Lisp. Unfortunately such a thing
> doesn't seem to exist.
You may want to take a look at ISLISP.
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Matthias Buelow <···@incubus.de> writes:
> Paul F. Dietz wrote:
>
>> Doing Scheme in Lisp is another pet peeve of mine, btw.
>
> What I'd like would be something in between Scheme and Common Lisp.
Have you tried plt+swindle?
'as
Matthias Buelow <···@incubus.de> writes:
> What I'd like would be something in between Scheme and Common Lisp.
Oaklisp could be what you dream of :-)
> Not as stiff and rigid and puritan as Scheme (for example, I like
> dynamically scoped "special" variables and the straightforward Common
Yes
> Lisp macro system)
Yes
> but not as monstrous and inconsistent and full of
> archaeological baggage as Common Lisp.
Oaklisp is OO down to the bottom, you can even subclass CONS!
>Unfortunately such a thing
> doesn't seem to exist. Well, maybe Graham's Arc will go in that
> direction, once it's out
Arc has its own syntax, Oaklisp uses the well know s-exp we all love!
Other nice things about Oaklisp:
+ R4RS, including full continuations
+ CL' format (but you probably dislike that beast as well).
+ based on a well documented virtual machine
Contra:
- slow, due to the bytecodes
- too simple compiler
- tiny user base AFAIK
- no sockets
Regards,
Jorg Hohle
Telekom/T-Systems Technology Center
Joerg Hoehle <······@users.sourceforge.net> writes:
>+ CL' format (but you probably dislike that beast as well).
No, imho something like format (or printf) is essential for any usable
general purpose programming language. This has even been realised by
C++ and Java programmers (where it isn't, or at least wasn't, provided
by the base language) and so third-party variations of printf have
appeared. This is one criticism I have with Standard ML (which I
otherwise like), and potentially with other strictly and compile-time
typed languages, where it is next to impossible to write a
format/printf-style function within the language proper because it
won't type-check. Thanks for the oaklisp hint, btw.
mkb.
Matthias Buelow <···@incubus.de> writes:
> Joerg Hoehle <······@users.sourceforge.net> writes:
>
> >+ CL' format (but you probably dislike that beast as well).
>
> No, imho something like format (or printf) is essential for any usable
> general purpose programming language. This has even been realised by
> C++ and Java programmers (where it isn't, or at least wasn't, provided
> by the base language) and so third-party variations of printf have
> appeared. This is one criticism I have with Standard ML (which I
> otherwise like), and potentially with other strictly and compile-time
> typed languages, where it is next to impossible to write a
> format/printf-style function within the language proper because it
> won't type-check. Thanks for the oaklisp hint, btw.
I don't think it's really fair to either printf or format to speak as
though they are roughly equivalent. printf-like functionality is a
part of format, but conditionals, iteration, and goto make format a
significantly different beast. I find its utility often outweighs the
potential awefulness of its line-noise syntax, but I would suspect
most LOOPophobes to be agast at statements like:
(format nil ··@··@[~#*~]~S~}" x)
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
Matthias Buelow wrote:
> Paul F. Dietz wrote:
>
>>I've liked LOOP for decades. I've never understood the misplaced
>>puritanism that prefers incomprehensible DO or (shudder) LABELS
>>constructs. For the things that LOOP does well, its competitors
>>are manifestly inferior.
>
> Well, I'm only using Lisp for a couple years but I certainly do prefer
> LABELS and Scheme-style recursion instead of DO (which I always get
> wrong on the first attempt) or the abominable (imho) LOOP. There're
> quite a few dark corners in Common Lisp and if I were to redesign it,
> LOOP would be the first to go.
See also http://ccs.mit.edu/papers/CCSWP150.html ;)
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Matthias Buelow:
> There're quite a few dark corners in Common Lisp and if I
> were to redesign it, LOOP would be the first to go.
That would be a disaster. The Loopies would use DEFMACRO to
put LOOP back, except that they would take the opportunity
to make their own favourite modifications. Instead of one
LOOP to complain about there would be a hundred subtlely
incompatible variants.
Once a language designer puts DEFMACRO into his language he
gives up the power to exclude constructs he doesn't
like. The /best/ he can do is to provide good standard
versions of the constructs he doesn't like so that they
don't ramify. Ouch.
Alan Crowe
Edinburgh
Scotland
> Well, I'm only using Lisp for a couple years but I certainly do prefer
> LABELS and Scheme-style recursion instead of DO (which I always get
> wrong on the first attempt) or the abominable (imho) LOOP. There're
> quite a few dark corners in Common Lisp and if I were to redesign it,
> LOOP would be the first to go.
LOOP is a domain specific language created using Lisp's macro facility.
One of applications of the DSL approach is to create domain languages
for those who can't use the full power of Lisp and only need it for a
limited subset of tasks. LOOP allows programmers who can't write clean
iteration code in Lisp concisely to catch common cases using LOOP's
domain specific language.
Otherwise, they would write code which is worse than the most horrible
loop.
A real Lisp programmer has a better generic Lisp alternative to LOOP
for general cases, and writes a DSL for his domain with specific
iteration constructs. Those who can't do either, use LOOP.
David
Paul F. Dietz wrote:
> For the things that LOOP does well, its competitors
> are manifestly inferior.
>
I'd be interested to hear how so in the particular case of the iterate
package? (apart from the triviality of loop being in the current ANSI
spec and iterate being an add-on package..). My current thinking is
that loop should be probably be deprecated and iter added to base
cl :-)
On Sun, 05 Jun 2005 12:43:58 +0100, David Golden <············@oceanfree.net> wrote:
> Paul F. Dietz wrote:
>
>> For the things that LOOP does well, its competitors
>> are manifestly inferior.
>
> I'd be interested to hear how so in the particular case of the
> iterate package? (apart from the triviality of loop being in the
> current ANSI spec and iterate being an add-on package..).
That's /not/ a triviality. If you allow any old third-party package
then you can certainly write something that is nicer than LOOP,
especially with hindsight. The /real/ competitors are DO/DO*, MAPC,
etc.
> My current thinking is that loop should be probably be deprecated
> and iter added to base cl :-)
Sure, please open up a new standardization process... :)
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Matthias Buelow wrote:
> Ulrich Hobelmann wrote:
>
>>Heh, well, sometimes I actually like loop despite its syntax. Short,
>>concise, and mostly it would take longer and result in less readable
>>code to use mapc / mapcar and other constructs.
>
> I think the following quote from Graham's ACL book hits the nail on the
> head:
>
> "The loop macro was originally designed to help inexperienced Lisp users
> write iterative code. ... Unfortunately, loop is more like English than
> its designers ever intended: you can use it in simple cases without
> quite understanding how it works, but to understand it in the abstract
> is almost impossible. ... almost no one understands it. ... you probably
> never will, because the ANSI standard does not really give a formal
> specification of its behaviour."
This quote foremostly means that Paul Graham doesn't understand it.
> I've always been amazed to see how many code snippets posted on c.l.l
> use loop. I would think that something that is so ugly and goes so
> badly against the flow of Lisp would be a pariah construct but
> apparently the loop virus finds new victims every year.
LOOP can lead to very compact and very easily understandable code. I
don't care about the dark corners of LOOP, because I can just avoid
them. There are cases when I switch to recursive versions of an
iteration when LOOP loses its steam, but this rarely happens. (And I
still have to learn ITERATE which seems to solve many problems that LOOP
has.)
LOOP doesn't work from first principles. For some people, this is hard
to grasp because they expect programming language design to be some
mathematical exercise, but that's nonsense. [1] In the case of LOOP,
it's important to get rid of this preconception and to learn it just by
practising it. You may not be willing to do that, but don't
overgeneralize your own preconceptions, then.
Pascal
[1] A programming language is a human-computer interface, with the
central idea that it should be designed for the human to be able to
better express ideas. If this weren't the case, assembler would be
enough. In some areas of language design, a mathematically sound basis
helps, but that doesn't make it a general principle.
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Pascal Costanza <··@p-cos.net> writes:
> LOOP can lead to very compact and very easily understandable code. I
> don't care about the dark corners of LOOP, because I can just avoid
> them. There are cases when I switch to recursive versions of an
> iteration when LOOP loses its steam, but this rarely happens. (And I
> still have to learn ITERATE which seems to solve many problems that
> LOOP has.)
I tend to move things to DO-clauses when the conditionals get too
complicated, since complex IF-THEN-ELSE clauses in LOOP IMHO easily
can get unreadble (I recently uttered som loop-scepticism here because
after a bad debugging experience due to complex conditionals).
But IMHO the main shortcoming of loop is that it isn't complete
enough. For instance, LOOP would be even more fun if it had general
sequence accumulation and not only list and number accumulation - I'm
tired of writing e.g. (coerce (loop ... collect ...) 'string)!
> [1] A programming language is a human-computer interface, with the
> central idea that it should be designed for the human to be able to
> better express ideas.
Well, the "provable programs" or even "programs that prove their own
correctness" discipline has had a large impact on many computer
science departments. The mathematical logician in me is somewhat
attracted to those ideas - the hacker in me detests them. Common Lisp
is a good blend of precision, high quality standards and pragmatism,
i.e. just what the dual-natured logician-hacker needs :-)
--
(espen)
Espen Vestre wrote:
> But IMHO the main shortcoming of loop is that it isn't complete
> enough. For instance, LOOP would be even more fun if it had general
> sequence accumulation and not only list and number accumulation - I'm
> tired of writing e.g. (coerce (loop ... collect ...) 'string)!
To generalize this: IMO, the main shortcoming of LOOP (and the way
it most fails to be sufficiently lispish) is that it isn't extensible.
Paul
> To generalize this: IMO, the main shortcoming of LOOP (and the way
> it most fails to be sufficiently lispish) is that it isn't extensible.
>
The main shortcoming of LOOP is that it is a domain unspecific language
whithout means to make it domain specific.
In article <············@avnika.corp.mot.com>,
Paul Dietz <············@motorola.com> wrote:
> Espen Vestre wrote:
>
> > But IMHO the main shortcoming of loop is that it isn't complete
> > enough. For instance, LOOP would be even more fun if it had general
> > sequence accumulation and not only list and number accumulation - I'm
> > tired of writing e.g. (coerce (loop ... collect ...) 'string)!
>
> To generalize this: IMO, the main shortcoming of LOOP (and the way
> it most fails to be sufficiently lispish) is that it isn't extensible.
DO isn't extensible either. For that matter, neither is LAMBDA. This
is not a facetious observation. There are ways in which one might
usefully extend these constructs, but it can't be done within the
language. So this seems like an odd criterion on which to declare LOOP
unlispy.
rg
Ron Garret wrote:
> In article <············@avnika.corp.mot.com>,
> Paul Dietz <············@motorola.com> wrote:
> > Espen Vestre wrote:
> > > But IMHO the main shortcoming of loop is that it isn't complete
> > > enough. For instance, LOOP would be even more fun if it had general
> > > sequence accumulation and not only list and number accumulation - I'm
> > > tired of writing e.g. (coerce (loop ... collect ...) 'string)!
> >
> > To generalize this: IMO, the main shortcoming of LOOP (and the way
> > it most fails to be sufficiently lispish) is that it isn't extensible.
>
> DO isn't extensible either. For that matter, neither is LAMBDA. This
> is not a facetious observation. There are ways in which one might
> usefully extend these constructs, but it can't be done within the
> language. So this seems like an odd criterion on which to declare LOOP
> unlispy.
Speaking of that, I recall one rather popular talk about an extensible
LOOP-substitute. It uses CLOS for this purpose.
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/slides/Nystrom-slides.pdf
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/submissions/Nystrom.pdf
I would be surprised if there weren't some extensible LOOP
implementation in history.
Tayssir
On 6 Jun 2005 17:54:41 -0700, "Tayssir John Gabbour" <···········@yahoo.com> wrote:
> I would be surprised if there weren't some extensible LOOP
> implementation in history.
Several existing Lisp implementations have extensible LOOPs. See
CLSQL for examples.
<http://clsql.b9.com/manual/loop-tuples.html>
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Ron Garret <·········@flownet.com> writes:
>> To generalize this: IMO, the main shortcoming of LOOP (and the way
>> it most fails to be sufficiently lispish) is that it isn't extensible.
>
> DO isn't extensible either. For that matter, neither is LAMBDA.
And some find a pity that they can't use other pattern matching
constructs in LAMBDA than those predesigned. Well, often this requires
changing the overall structure too, c.f. CASE-LAMBDA with many clauses;
patterns make more sense when you can specify what to do when matching
fails, so in the original lambda there is little to extend.
There is even less to extend in DO because it's quite simple. And if
there was, it's simple enough to be reimplemented.
LOOP is not simple, and there are useful ways in which it could be
extended: supporting more sequence types. For example arithmetic
sequences, virtual concatenation of sequences, sequences with a finite
length and the same value as each element, or lazily delivered results
of a DB query.
Lisp doesn't provide mechanisms to view such non-standard sequence
as a single value from which LOOP or other iteration constructs take
elements. The programmer must find and directly use a low level
iterator-like interface.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
In article <··············@qrnik.zagroda>,
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> >> To generalize this: IMO, the main shortcoming of LOOP (and the way
> >> it most fails to be sufficiently lispish) is that it isn't extensible.
> >
> > DO isn't extensible either. For that matter, neither is LAMBDA.
>
> And some find a pity that they can't use other pattern matching
> constructs in LAMBDA than those predesigned. Well, often this requires
> changing the overall structure too, c.f. CASE-LAMBDA with many clauses;
> patterns make more sense when you can specify what to do when matching
> fails, so in the original lambda there is little to extend.
>
> There is even less to extend in DO because it's quite simple. And if
> there was, it's simple enough to be reimplemented.
>
> LOOP is not simple, and there are useful ways in which it could be
> extended: supporting more sequence types. For example arithmetic
> sequences, virtual concatenation of sequences, sequences with a finite
> length and the same value as each element, or lazily delivered results
> of a DB query.
>
> Lisp doesn't provide mechanisms to view such non-standard sequence
> as a single value from which LOOP or other iteration constructs take
> elements. The programmer must find and directly use a low level
> iterator-like interface.
Yes, but this is not unique to LOOP. Many Lisp constructs do not
support general sequence types and are not extensible to support them.
This may well be a design shortcoming of LOOP, but to call it unlispy
for this reason is to call half of Lisp unlispy, which seems odd to me.
rg
Marcin 'Qrczak' Kowalczyk wrote:
> Ron Garret <·········@flownet.com> writes:
>
>
>>>To generalize this: IMO, the main shortcoming of LOOP (and the way
>>>it most fails to be sufficiently lispish) is that it isn't extensible.
>>
>>DO isn't extensible either. For that matter, neither is LAMBDA.
>
>
> And some find a pity that they can't use other pattern matching
> constructs in LAMBDA than those predesigned. Well, often this requires
> changing the overall structure too, c.f. CASE-LAMBDA with many clauses;
> patterns make more sense when you can specify what to do when matching
> fails, so in the original lambda there is little to extend.
A shameless plug is in order here:
http://common-lisp.net/project/cl-unification
Cheers
--
Marco
>
> There is even less to extend in DO because it's quite simple. And if
> there was, it's simple enough to be reimplemented.
>
> LOOP is not simple, and there are useful ways in which it could be
> extended: supporting more sequence types. For example arithmetic
> sequences, virtual concatenation of sequences, sequences with a finite
> length and the same value as each element, or lazily delivered results
> of a DB query.
>
> Lisp doesn't provide mechanisms to view such non-standard sequence
> as a single value from which LOOP or other iteration constructs take
> elements. The programmer must find and directly use a low level
> iterator-like interface.
>
Which gives me the chance to add another shameless plug
http://common-lisp.net/project/cl-enumeration
:)
Cheers
--
Marco
Paul Dietz <············@motorola.com> writes:
> To generalize this: IMO, the main shortcoming of LOOP (and the way
> it most fails to be sufficiently lispish) is that it isn't extensible.
yes, good point.
--
(espen)
Paul Dietz <············@motorola.com> writes:
> Espen Vestre wrote:
>
> > But IMHO the main shortcoming of loop is that it isn't complete
> > enough. For instance, LOOP would be even more fun if it had general
> > sequence accumulation and not only list and number accumulation - I'm
> > tired of writing e.g. (coerce (loop ... collect ...) 'string)!
>
> To generalize this: IMO, the main shortcoming of LOOP (and the way
> it most fails to be sufficiently lispish) is that it isn't extensible.
The LOOP we used in the early 1980s was extensible.
(I thought all the implementations of today were based
on that very same code? It's not ANSI, though.)
Espen Vestre wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>
>>LOOP can lead to very compact and very easily understandable code. I
>>don't care about the dark corners of LOOP, because I can just avoid
>>them. There are cases when I switch to recursive versions of an
>>iteration when LOOP loses its steam, but this rarely happens. (And I
>>still have to learn ITERATE which seems to solve many problems that
>>LOOP has.)
>
>
> I tend to move things to DO-clauses when the conditionals get too
> complicated, since complex IF-THEN-ELSE clauses in LOOP IMHO easily
> can get unreadble (I recently uttered som loop-scepticism here because
> after a bad debugging experience due to complex conditionals).
>
> But IMHO the main shortcoming of loop is that it isn't complete
> enough. For instance, LOOP would be even more fun if it had general
> sequence accumulation and not only list and number accumulation - I'm
> tired of writing e.g. (coerce (loop ... collect ...) 'string)!
It seems to me that ITERATE helps in both regards (IF-THEN-ELSE tangling
and more comprehensive accumulations).
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Catching up from two weeks ago [sorry 'bout that]...
I see there is one thing no-one else mentioned:
Ulrich Hobelmann <···········@web.de> wrote:
+---------------
| (loop with first = (make-instance 'state)
| with nfa = (make-instance 'nfa :start-state first)
| for c in (cons nil (loop for c across string collect c))
| ...[and the rest]...
+---------------
Yes, I know you later got rid of the CONS and can now use ACROSS
instead of IN, but if for some reason you hadn't done that, you
might be able to get a mild performance improvement by replacing:
for c in (cons nil (loop for c across string collect c))
with this:
for c in (cons nil (coerce string 'list)))
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607