`cond'
David Bakhash
it finds the first non-nil predicate?
in other words, I'm looking for something that will just sequence a
bunch of `when' statements. It's an easy enough macro, but I thought
I'd look around for it before writing it.
dave
Barry Margolin
>does CL have something like (cond ...), but which doesn't return after
>it finds the first non-nil predicate?
No. I seem to recall something called COND-EVERY in some Lisp dialect, but
I don't remember where.
>in other words, I'm looking for something that will just sequence a
>bunch of `when' statements. It's an easy enough macro, but I thought
>I'd look around for it before writing it.
It hardly even seems necessary. All it saves is repeating the word
"when". The main benefit of COND is that it doesn't get as heavily nested
as a series of if/then/else constructs, e.g.
(if cond1
(progn then1)
(if cond2
(progn then2)
(if cond3
(progn then3)
(progn else))))
vs.
(cond (cond1 then1)
(cond2 then2)
(cond3 then3)
(t else))
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Don't bother cc'ing followups to me.
Rainer Joswig
> does CL have something like (cond ...), but which doesn't return after
> it finds the first non-nil predicate?
>
> in other words, I'm looking for something that will just sequence a
> bunch of `when' statements. It's an easy enough macro, but I thought
> I'd look around for it before writing it.
>
> dave
From the CL-HTTP sources:
(define-macro cond-every (&rest clauses)
(loop for (cond . forms) in clauses
collect (if
(eql cond 't)
`(progn . ,forms)
`(when ,cond ,@forms))
into code
finally (return `(progn . ,code))))
Kelly Murray
macros to create "funny" basic language control structures
such as COND-EVERY
just makes the code harder for others to understand, particularly
novices and those coming from other languages.
Furthermore it makes source-code
stepping and debugging a hard problem.
So, just another plug for jkf's IF syntax, which conforms to
to the principle espoused by eliminating even WHEN
(if cond then ...) == (when cond ...)
(if cond then ... else ..) == (if cond (progn ..) (progn ..))
(if cond1 then ...
elseif cond2 then .. == (cond (cond1 ...) (cond2 ...))
elseif cond3 then .. (cond3 ...) (t ...))
else ..
)
Barry Margolin wrote:
>
> In article <cxjiufs...@engc.bu.edu>, David Bakhash <ca...@bu.edu> wrote:
> >does CL have something like (cond ...), but which doesn't return after
> >it finds the first non-nil predicate?
>
> No. I seem to recall something called COND-EVERY in some Lisp dialect, but
> I don't remember where.
>
> >in other words, I'm looking for something that will just sequence a
> >bunch of `when' statements. It's an easy enough macro, but I thought
> >I'd look around for it before writing it.
>
Mike McDonald
Kelly Murray <k...@IntelliMarket.Com> writes:
> I also agree it shouldn't be necessary, and in fact think using
> macros to create "funny" basic language control structures
> such as COND-EVERY
> just makes the code harder for others to understand, particularly
> novices and those coming from other languages.
> Furthermore it makes source-code
> stepping and debugging a hard problem.
>
> So, just another plug for jkf's IF syntax, which conforms to
> to the principle espoused by eliminating even WHEN
So, why is COND-EVERY "funny" but this bastardized version of IF good?
Mike McDonald
mik...@mikemac.com
Duane Rettig
Kelly Murray <k...@IntelliMarket.Com> writes:
> So, just another plug for jkf's IF syntax, which conforms to
> to the principle espoused by eliminating even WHEN
Just to clarify: it is jkf's IF* syntax, not IF (note the asterisk
on the alternate-syntax version). This used to be the alternate form
of the if macro in Franz Lisp (not to be confused with Franz's Allegro
CL) and when the similar functionality was added to Allegro CL as an
extension its name was changed to EXCL:IF* so as not to conflict with
proper CL use of IF.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
Kelly Murray
>
> In article <36685545...@intellimarket.com>,
> Kelly Murray <k...@IntelliMarket.Com> writes:
> > I also agree it shouldn't be necessary, and in fact think using
> > macros to create "funny" basic language control structures
> > such as COND-EVERY
> > just makes the code harder for others to understand, particularly
> > novices and those coming from other languages.
> > Furthermore it makes source-code
> > stepping and debugging a hard problem.
> >
> > to the principle espoused by eliminating even WHEN
>
>
Why?
Because it shouldn't be necessary, and in fact I think using
macros to create "funny" basic language control structures
just makes the code harder for others to understand, particularly
novices and those coming from other languages.
Furthermore it makes source-code stepping and debugging a hard problem.
Why is COND-EVERY not a "bastardized" version of COND?
Mike McDonald
I was refering to your preference for using IF*, which contains all of those
syntaxtic keywords such as then, else, elseif, ... IF* appears to me to be a
macro to create a "funny" basic language control structure.
So the question remains, why is IF* OK but COND-EVERY not? IF* isn't
necessary, makes the code harder to understand, isn't standard, ...
Mike McDonald
mik...@mikemac.com
Barry Margolin
Kelly Murray <k...@IntelliMarket.Com> wrote:
>Mike McDonald wrote:
>> So, why is COND-EVERY "funny" but this bastardized version of IF good?
>>
>
>Why?
>
>Because it shouldn't be necessary, and in fact I think using
>macros to create "funny" basic language control structures
>just makes the code harder for others to understand, particularly
>novices and those coming from other languages.
>Furthermore it makes source-code stepping and debugging a hard problem.
How is this a justification for the IF* macro? Isn't it just as hard on
stepping as COND-EVERY would be?
It seems to me that IF* is to COND as LOOP is to DO. They provide
English-like syntax to make relatively complex control structures easier to
understand.
Kelly Murray
My point is having ONLY the funny bastardized english-like IF
would be better, because THEN code would be easier to understand
by everyone and source-code steppers only special-case one operator.
But clearly it appears that notion is foreign to this lisp community.
David Bakhash
this is what I did, pretty much, after I sent out that post.
I like having a cond that doesn't stop. I Don't think it's bad at all
to have such a macro around.
(defmacro cond-every (&rest items)
(cons 'progn
(loop for item in items
collect
`(when ,(first item)
,@(rest item)))))
dave
David Cooper
>
> My point is having ONLY the funny bastardized english-like IF
> would be better, because THEN code would be easier to understand
>
A colleague of mine refuses to use WHEN (``IF is shorter to type,''
he says, ``and has the same effect as WHEN if there is no ELSE
clause.'').
I am not sure his real reasons for behaving this way, but he has
a few odd idiosycrancies like that.
Anyway, I sometimes find it slightly annoying to read his code,
because to me when I see the word WHEN then I *know* immediately
that this form is expected to return a non-nil value when the
condition is non-nil, and NIL otherwise. When I see IF, I always
have to slow down a bit and figure out what this form is really
trying to do.
This problem I have with my colleague's code might be slightly
improved if we had a THEN ... [ELSE] following the IF, but I doubt
it. It would lose its Lispyness, and I would have to hunt around for
an ELSE every time I see an IF to figure out if it's really a WHEN
in disguise or not.
I have always found this idea of trying to shoehorn a so-called
English-like syntax into Lisp (a la LOOP) mighty puzzling. If we
we are hell-bent on an English-like syntax above all else, why
not use just use COBOL or FORTRAN or something? John McCarthy himself
made the strong point in his keynote at the LUGM that the Lisp
using the List data structure as its primary syntactical structure
for programs is crucial (although he acknowledged that technically he
didn't invent this originally, it sounds like it pretty much fell out
as a natural consequence of what he did invent). He asked those in
the room to raise their hands if they used this feature on a regular
basis, and a good 3/4 of the room raised their hands.
-djc
Kelly Murray
>
> Kelly Murray wrote:
> >
> > My point is having ONLY the funny bastardized english-like IF
> > would be better, because THEN code would be easier to understand
> >
> an ELSE every time I see an IF to figure out if it's really a WHEN
> in disguise or not.
I agree WHEN is handy and conveys more information,
but in fact, if you need an else clause later, its more work to add.
Lispyness appears to have at least one meaning: syntax represented
only using parenthesis, and if you use even more than needed, so
much the better. All I can say is the evidence is overwhelming:
for the majority of programmers this is one reason they don't like Lisp.
Go ahead and just tell these
people they are "stupid" and should come join the enlightened smarter
people who don't care about syntax (yeah, right) and focus on semantics.
This attitude/approach has not help lisp to expand its programmer ranks.
I'll make another point, that Lispers can hold their syntax sacred
to their grave, but in the end we'll lose it completely when we have to
write code in other languages, namely Java. Ask XEROX Parc's
Gregor, author of CLOS, who just gave up "fighting", and adopted
Java. Sure, complain about a less-lispy syntax,
but in the end you don't even get LISP, let alone all-parenthesis
syntax. At least with Dylan you got LISP if not the syntax.
BTW, I do appreciate the responses, don't mean to flame anyone.
(I mean to flame everyone.. ;)
-Kelly Murray k...@intellimarket.com
Chris Double
> A colleague of mine refuses to use WHEN (``IF is shorter to type,''
>he says, ``and has the same effect as WHEN if there is no ELSE
>clause.'').
Coming from a C/C++ background I had similar thoughts with WHEN in Dylan.
Why use it if it is the same as if? But it grew on me over time I must admit
and now I use it most of the time - when rereading the code I find it
documents the fact that I didn't want an 'else' to occur. Now when I see an
'if' without an 'else' I find myself wondering if I intenionally left the
'else' out or if it was a programming error.
Try as I might though I have huge difficulties in getting my head around
UNLESS. I know what it does, and it should be simple, but I look at an
UNLESS form and it takes me ten times as long to think about what happens. I
think my brain is broken in that area <g>.
Chris.
ch...@cnd.co.nz
David Cooper
>
> Sure, complain about a less-lispy syntax, but in the end
> you don't even get LISP, let alone all-parenthesis syntax.
>
I don't? Speak for yourself.
Is someone forcing you to use Java on the server side for
your Web server project? I think not.
Were you in Paul Graham's talk at the LUGM conference?
Perhaps I have lived a charmed life so far (and if so knock
on wood...) but so far I have not felt this need to start
distracting myself thinking about some hybridized language
to make some anonymous peanut gallery happy (other than
occasionally on this newsgroup).
Why does this community seem to have this neurotic complex
of always being on the defensive?
BTW, I certainly do not advocate using more parentheses than necessary
(where did you get that idea from?), just the sufficient number
for conciseness and correctness.
The parentheses are just there for convenience, anyway. Any
experienced Lisper knows that you read code by indentation and
your eyes just end up skipping over the parentheses. I point this
out to my students on their first day of Lisp/ICAD training and
never once have I heard any of them complain about parentheses.
It may sound a bit snobbish, but I think the much easier solution
is to continue to stress education about the fact that the
parentheses are incidental, and you read using indentation,
rather than propogating yet another language, when we haven't
even begun to tap into the power of this one.
As an afterthought, it occurs to me that perhaps in ICAD
the parenthesis issue is not as much of an issue, because
all the expressions are broken down into attributes, whose
expressions are typically pretty short. If they get too
long, most people start breaking them up into smaller
attributes. So you usually don't get into too many levels
of hairy nested parens as you would when writing big
defuns or defmethods.
One of these days I will post some example code to illustrate
this, as well as a toy defpart macro which has been bouncing
around for a while so others can play around in this ``attribute
grammar'' syntax if they wish. Someone remind me if I space
out on doing this and a couple months go by.
As another afterthought, I should mention that yes, we will
soon be deploying some Java-based UI's on the client side for
ICAD applications. But, these will mostly be done with a
Visaj or JBuilder GUI tool and will not involve writing
much if any actual Java code. The Java code will basically
just be data out there. (BTW, where is that Lisp Netscape
plugin I keep hearing about...?)
-djc
Barry Margolin
Chris Double <ch...@cnd.co.nz> wrote:
>Coming from a C/C++ background I had similar thoughts with WHEN in Dylan.
>Why use it if it is the same as if?
The main benefit of WHEN is the implicit PROGN it provides. The original
poster on this subthread said that WHEN is two characters more than IF, but
that's only if there's a single consequence form. More often, it's used
as:
(when <condition>
<form>
<form>
<form>
...)
which is less typing and indentation than
(if <condition>
(progn
<form>
<form>
<form>
...))
Of course, this would also be an argument in favor of the IF* macro that
was mentioned a few days ago.
However, it's also simpler to read, because you don't have to look to see
if there's an else clause.
Steve Gonedes
Kelly Murray <k...@IntelliMarket.Com> writes:
< Lispyness appears to have at least one meaning: syntax represented
< only using parenthesis, and if you use even more than needed, so
< much the better. All I can say is the evidence is overwhelming: for
< the majority of programmers this is one reason they don't like Lisp.
< Go ahead and just tell these people they are "stupid" and should
< come join the enlightened smarter people who don't care about syntax
< (yeah, right) and focus on semantics. This attitude/approach has not
< help lisp to expand its programmer ranks.
if (startpos == pos && (((((enum Lisp_Type) ((((((&(((union Lisp_Misc *) ((overlay) & ((((int) 1)<< 28) - 1))) ->u_overlay)) ->end))) >> 28) & ((((int) 1)<< 3) - 1))) == Lisp_Misc) && ((&(((union Lisp_Misc *) ((((&(((union Lisp_Misc *) ((overlay) & ((((int) 1)<< 28) - 1))) ->u_overlay)) ->end)) & ((((int) 1)<< 28) - 1))) ->u_marker)) ->type) == Lisp_Misc_Marker) ? marker_position (((&(((union Lisp_Misc *) ((overlay) & ((((int) 1)<< 28) - 1))) ->u_overlay)) ->end)) : (abort (), 0)) == pos
&& ! (((Foverlay_get (overlay, Qevaporate)) + 0) == ((Qnil) + 0)))
hit_list = Fcons (overlay, hit_list);
I don't think it's an issue of too many parenthesis... Maybe it's
those blasted newlines and spaces?
(source from emacs, gcc -E ... I have seen _*MUCH*_ worse, but don't
feel like looking for it :)
Rainer Joswig
<k...@IntelliMarket.Com> wrote:
> write code in other languages, namely Java. Ask XEROX Parc's
> Gregor, author of CLOS, who just gave up "fighting", and adopted
> Java. Sure, complain about a less-lispy syntax,
Isn't he still working in Lisp? For Java?
Gareth McCaughan
[someone mentioned parens as a reason why people don't like Lisp]
> if (startpos == pos && (((((enum Lisp_Type) ((((((&(((union Lisp_Misc *) ((overlay) & ((((int) 1)<< 28) - 1))) ->u_overlay)) ->end))) >> 28) & ((((int) 1)<< 3) - 1))) == Lisp_Misc) && ((&(((union Lisp_Misc *) ((((&(((union Lisp_Misc *) ((overlay) & ((((int) 1)<< 28) - 1))) ->u_overlay)) ->end)) & ((((int) 1)<< 28) - 1))) ->u_marker)) ->type) == Lisp_Misc_Marker) ? marker_position (((&(((union Lisp_Misc *) ((overlay) & ((((int) 1)<< 28) - 1))) ->u_overlay)) ->end)) : (abort (), 0)) == pos
> && ! (((Foverlay_get (overlay, Qevaporate)) + 0) == ((Qnil) + 0)))
> hit_list = Fcons (overlay, hit_list);
...
> (source from emacs, gcc -E ... I have seen _*MUCH*_ worse, but don't
> feel like looking for it :)
If you're comparing with *preprocessed* C, you'd better compare it
with the output of MACROEXPAND. In which case a trivial loop can
easily turn into
(LET ((I 1))
(DECLARE (TYPE REAL I))
(LET ((J NIL) (#:G772 THE-LIST))
(DECLARE (TYPE LIST #:G772))
(ANSI-LOOP::WITH-LOOP-LIST-COLLECTION-HEAD
(#:G773 #:G774)
(BLOCK NIL
(ANSI-LOOP::LOOP-BODY NIL
(NIL NIL NIL NIL
(WHEN (ENDP #:G772)
(GO
ANSI-LOOP::END-LOOP))
(ANSI-LOOP::LOOP-REALLY-DESETQ
J
(CAR #:G772))
NIL
(ANSI-LOOP::LOOP-REALLY-DESETQ
#:G772
(CDR #:G772)))
((ANSI-LOOP::LOOP-COLLECT-RPLACD
(#:G773 #:G774)
(LIST
(CONS I J))))
(NIL
(ANSI-LOOP::LOOP-REALLY-DESETQ
I
(1+ I))
(WHEN (> I '10)
(GO
ANSI-LOOP::END-LOOP))
NIL
(WHEN (ENDP #:G772)
(GO
ANSI-LOOP::END-LOOP))
(ANSI-LOOP::LOOP-REALLY-DESETQ
J
(CAR #:G772))
NIL
(ANSI-LOOP::LOOP-REALLY-DESETQ
#:G772
(CDR #:G772)))
((RETURN-FROM NIL
(ANSI-LOOP::LOOP-COLLECT-ANSWER
#:G773))))))))
which is not, in my opinion, any better than the monstrosity you
quote above.
How many parens were there in the macro invocation that produced the
C code you quote? I'd guess it looked something like
if (startpos==pos && CAREFUL_MARKER_POSITION(END(overlay))==pos
&& !EVAPORATES(overlay))
hit_list = Fcons(overlay, hit_list);
which is hardly overburdened with parentheses.
I agree that Lisp's very heavy use of parentheses doesn't have
to be a problem, but it seems clear that it *is* a reason why
many people run away screaming when they first see some Lisp
code. The fact that preprocessed C usually has lots of parens,
to avoid precedence lossage, isn't very relevant.
--
Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics,
gj...@dpmms.cam.ac.uk Cambridge University, England.
Steve Gonedes
Gareth McCaughan <gj...@dpmms.cam.ac.uk> writes:
< I agree that Lisp's very heavy use of parentheses doesn't have
< to be a problem, but it seems clear that it *is* a reason why
< many people run away screaming when they first see some Lisp
< code. The fact that preprocessed C usually has lots of parens,
< to avoid precedence lossage, isn't very relevant.
It is relevant in that there are lots of parenthesis.
My point is that people are not intrinsically frightened of
parenthesis. I would bet that the polish notation would be more
shocking than the use of parenthesis. You can change the parenthesis
to backets or braces - but this wouldn't solve the "unfamiliar" polish
notation.
Martin Rodgers
says...
> Why does this community seem to have this neurotic complex
> of always being on the defensive?
Could the years of attacks from C/C++ programmers have anything to do
with it? I just wonder. It can be fun reminding Java programmers that
Lispers have been thru it all before. Been There, Done That, etc.
Unfortunately, some of us carry the battle scars, and that's not so good.
--
Remove insect from address to email me | You can never browse enough
will write code that writes code that writes code for food
Martin Rodgers
says...
> The fact that preprocessed C usually has lots of parens,
> to avoid precedence lossage, isn't very relevant.
I've always used more parens in C than most other C programmers. That's
probably because I've always been uncomfortable with precedence.
Curiously, few editors and none of the dedicated C++ IDEs that I've used
support parens matching. I've even seen this mentioned in a Windows
developers magazine! So, at least _some_ C programmers miss this feature.
Sometimes my image of programmers who choose to use C/C++ is of
masochists with hygiene problems. Instead of asking themselves why
they're banging nails into their flesh, they'll sharpen and perhaps wash
the nails, then call that a massive improvement!
Any editor that does parens matching is a joy to use.
rusty craine
Steve Gonedes wrote in message ...
>
>My point is that people are not intrinsically frightened of
>parenthesis. I would bet that the polish notation would be more
>shocking than the use of parenthesis. You can change the parenthesis
>to backets or braces - but this wouldn't solve the "unfamiliar" polish
>notation.
>
aminoglycoside doses and schedules (both drugs rather toxic). If floating
point doesn't scare you enough, polish notation will make for many many late
nights of testing. I guess it shouldn't be any harder but in rather complex
second order equations, making sure the precedence is correct is always
worrisome to me.
lethal drugs with narrow theaputic indices makes you very good a testing
programs
rusty
Michael Tuchman
> Lispyness appears to have at least one meaning: syntax represented
> only using parenthesis, and if you use even more than needed, so
> much the better. All I can say is the evidence is overwhelming:
> for the majority of programmers this is one reason they don't like Lisp.
> Go ahead and just tell these
> people they are "stupid" and should come join the enlightened smarter
> people who don't care about syntax (yeah, right) and focus on semantics.
> This attitude/approach has not help lisp to expand its programmer ranks.
Really this is all boiling down to an isomorphic copy of the LOOP
vs. DO debate, a topic that is now discouraged in the faq. If you
want to write a macro to make lisp look however you want, you
shouldn't feel guilty about it. That's part of what LISP is for.
On the other hand, I don't think we should back down from our
traditional forms and ways of expressing things. Those prejudiced
people who insist on bashing what they don't want to learn will always
have plenty of excuses, parentheses being one of many. So I think the
whining about amount of parentheses is really just a pretense for some
deeper more hateful feelings.
Besides, most lisp interpretations won't allow an "excess" of
parentheses. They usually signal a warning of some sort :-)
My point is that terms like "excess" and "lispyiness" turn out to be
matters of personal style and that it is therefore difficult to have
rational discourse on a subject for which participants will not agree
on a meaning. No point being at each others throats when there are so
many others willing to do that for us!
--
Michael Tuchman
A Great way to avoid flame wars: all.SCORE has ("vs\\.?" -1000 nil r)
Michael Tuchman
Mike McDonald
Barry Margolin <bar...@bbnplanet.com> writes:
> The main benefit of WHEN is the implicit PROGN it provides. The original
> poster on this subthread said that WHEN is two characters more than IF, but
> that's only if there's a single consequence form. More often, it's used
> as:
>
> (when <condition>
> <form>
> <form>
> <form>
> ...)
>
> which is less typing and indentation than
>
> (if <condition>
> (progn
> <form>
> <form>
> <form>
> ...))
>
> Of course, this would also be an argument in favor of the IF* macro that
> was mentioned a few days ago.
Or COND! In lisp, whenever I want an if-then-elseif- ..., I use COND. Works
great without needing a new syntax!
Mike McDonald
mik...@mikemac.com
Zachary Turner
>In article <861zmck...@g.pet.cam.ac.uk>, gj...@dpmms.cam.ac.uk
>says...
>
>> The fact that preprocessed C usually has lots of parens,
>> to avoid precedence lossage, isn't very relevant.
>
>I've always used more parens in C than most other C programmers. That's
>probably because I've always been uncomfortable with precedence.
>Curiously, few editors and none of the dedicated C++ IDEs that I've used
>support parens matching. I've even seen this mentioned in a Windows
>developers magazine! So, at least _some_ C programmers miss this feature.
>
>Sometimes my image of programmers who choose to use C/C++ is of
>masochists with hygiene problems. Instead of asking themselves why
>they're banging nails into their flesh, they'll sharpen and perhaps wash
>the nails, then call that a massive improvement!
>
>Any editor that does parens matching is a joy to use.
The reason C/C++ editors don't do parens matching is because it just isn't
necessary. There rarely is a case when you have more than 2 parenthesis
right next to each other. In Lisp it's a given that you need parenthesis
matching, because that's how you read the language. Just like in C/C++ most
editors support auto-indenting, because that's how you read C/C++ code.
Putting parens matching in a C/C++ editor is like cracking a walnut with a
sledgehammer.
Martin Rodgers
> Putting parens matching in a C/C++ editor is like cracking a walnut with a
> sledgehammer.
What was I saying about hammering nails into flesh?
Raffael Cavallaro
<jgon...@worldnet.att.net> wrote:
>My point is that people are not intrinsically frightened of
>parenthesis.
I'd have to disagree strongly on this one. Most programmers I know detest
what they see as unnecessary parens in lisp. The point they miss, is that
the parens are necessary because they (and the syntax they represent) give
you the ability to treat code as data (i.e., lists) easily. Since they're
not used to having this ability, they don't miss it, and don't see why
they should put up with an ugly syntax for what they (incorrectly) see as
no additional functionality.
Raf
--
Raffael Cavallaro
Kelly Murray
>
> Kelly Murray <k...@IntelliMarket.Com> writes:
>
> > Lispyness appears to have at least one meaning: syntax represented
> > only using parenthesis, and if you use even more than needed, so
> > much the better. All I can say is the evidence is overwhelming:
> > for the majority of programmers this is one reason they don't like Lisp.
> > Go ahead and just tell these
> > people they are "stupid" and should come join the enlightened smarter
> > people who don't care about syntax (yeah, right) and focus on semantics.
> > This attitude/approach has not help lisp to expand its programmer ranks.
>
> My point is that terms like "excess" and "lispyiness" turn out to be
> matters of personal style and that it is therefore difficult to have
> rational discourse on a subject for which participants will not agree
> on a meaning. No point being at each others throats when there are so
> many others willing to do that for us!
I agree, and believe this reinforces my point: people who don't like
the parens of LISP do so for perhaps personal, irrational or stylistic
reasons -- and therefore telling them they should like it, or educating
them on why they should like it, is just arrogant and ineffective.
I'm certainly being arrogant and ineffective telling this community
to use a different syntax, right? It goes both ways..
>raf...@mediaone.net (Raffael Cavallaro) writes:
>
>><jgon...@worldnet.att.net> wrote:
>>My point is that people are not intrinsically frightened of
>>parenthesis.
>I'd have to disagree strongly on this one. Most programmers I know >detest
>what they see as unnecessary parens in lisp. The point they miss, is >that
>the parens are necessary because they (and the syntax they represent) >give
>you the ability to treat code as data (i.e., lists) easily.
>Since they're
>not used to having this ability, they don't miss it, and don't see why
>they should put up with an ugly syntax for what they (incorrectly) see >as no additional functionality.
The good news is one can have both a less-parenthesis syntax,
and at the same time still represent the code internally as lists.
Such is what I've tried to achieve using LOOP, IF*, and my
LET "bastard": (let a = 10 b = 20 do ...)
Let me say finally that people can and do learn to deal with
all sorts of strangeness when they need to. Programmers in particular
have a high level of "contortionist" by the very nature of our job,
at least if you're good at it. So clearly people would learn
whatever weird syntax if doing so got them something else of value, and
over time, would associate that weirdness with the positive
parts of the experience -- just like some people like being tied-up
and whipped... or the taste of coffee..or beer.
Which means people would be switching over to Lisp if it had
enough value to warrant getting over their initial distaste
for the syntax. As Richard Gabriel said at the 40th conference,
right now Lisp is perceived as the gateway to hell,
while Java is the gateway to the internet.
We must change the perception of what the gateway leads to,
that is the educational part of our job.
Just changing the syntax isn't going to
change what the gateway leads to, but why have an obstacle?
Sorry for raising the ruckus, I'll go back to work now.
-Kelly Murray k...@intellimarket.com
David Steuber The Interloper
claimed or asked:
% Try as I might though I have huge difficulties in getting my head around
% UNLESS. I know what it does, and it should be simple, but I look at an
% UNLESS form and it takes me ten times as long to think about what happens. I
% think my brain is broken in that area <g>.
I'm sure you find unless more appealing than when-not. In perl, there
is the bizzar construct like this:
statement unless cond;
statement if cond;
The statement gets executed if cond is the appropriate value for the
given key word. I found to to be quite weird initially, but it grew
on me. unless is the same way. If some condition is not met, I want
to execute a block of code.
--
David Steuber (ver 1.31.3a)
http://www.david-steuber.com
To reply by e-mail, replace trashcan with david.
May the source be with you...
David B. Lamkins
<ztu...@elsitech.com> wrote:
>The reason C/C++ editors don't do parens matching is because it just isn't
>necessary. There rarely is a case when you have more than 2 parenthesis
>right next to each other. In Lisp it's a given that you need parenthesis
>matching, because that's how you read the language. Just like in C/C++ most
>editors support auto-indenting, because that's how you read C/C++ code.
No, no, no, no, NO!
This ground has been covered again and again in this forum, but it bears
repeating once more just to set the record straight.
Lisp programmers -- as a general rule -- neither count nor match parens
explicitly. Editors that automatically indent Lisp code have been around
for a long, long time. Emacs does it, of course. As do the editors in the
IDEs of all of the PC and Macintosh hosted Lisp systems I've ever seen
(freeware, shareware and commercial)...
The same editors typically provide keyboard navigation functions to move the
cursor by various syntactic units, which is of course a useful thing to do
in Lisp because all of the syntax is consistent.
--
David B. Lamkins <http://www.teleport.com/~dlamkins/>
((lambda (x) (list x (list 'quote x)))
'(lambda (x) (list x (list 'quote x))))
Erik Naggum
| Most programmers I know detest what they see as unnecessary parens in
| lisp.
my take on this is that parens are necessary in lesser languages only
when the operator precedence no longer make sense, and thus signal that
something is more "complex" than it would have been without parentheses,
and perhaps adding parentheses is something the programmer does only
after hours of debugging, reinforcing the pain factor. further, any C or
C++ programmer knows that parens are actually dangerous in that they can
mean any one of about 4711 different things depending on context you
can't possibly squeeze into a single screen, no matter how big. thus the
parenthophobia would come from exposure badly designed languages. one
way to test this hypothesis is to see if people who are not exposed to
badly designed languages (C/C++/etc) are equally afraid of parentheses.
it's not exactly a scientifically valid argument, but I have never met a
person who has seen Lisp in the important formative years who has this
angst for parentheses, so I'll believe that the problem is that (some)
people carry a lot of mental baggage from working with stupid languages.
it sometimes helps to explain to these people that parentheses in Lisp
are on par with {} and ; in C, and agree with them that C's parentheses
are badly designed and horrible, because no matter how smart they are in
Lisp, they _are_ a f*cking pain in the b*tt in C/C++/etc.
#:Erik
--
The Microsoft Dating Program -- where do you want to crash tonight?
Erik Naggum
| I agree, and believe this reinforces my point: people who don't like
| the parens of LISP do so for perhaps personal, irrational or stylistic
| reasons -- and therefore telling them they should like it, or educating
| them on why they should like it, is just arrogant and ineffective.
this is not my experience. telling people that their parenthophobia is
misplaced in stupid languages is arrogant and ineffective because they
have a reason to fear them. however, people also need to learn, pretty
damn quick, that just because some two things look the same doesn't mean
they are the same if they occur in two very different contexts. telling
people that is perhaps arrogant, but it is effective, because it is true
and those who stick to "once-and-for-all" learning aren't useful, anyway.
Tim Bradshaw
> The reason C/C++ editors don't do parens matching is because it just isn't
> necessary. There rarely is a case when you have more than 2 parenthesis
> right next to each other. In Lisp it's a given that you need parenthesis
> matching, because that's how you read the language. Just like in C/C++ most
> editors support auto-indenting, because that's how you read C/C++ code.
> sledgehammer.
It isn't how you read the language! It's how *lisp* reads the
language. You read the language by *ignoring* the parens and looking
at how the words sit on the screen. That's why indentation is so
important for Lisp (and why the rules are hairier than most `indent n
spaces' languages), and also why you put all the closing parens on one
line -- if you're not reading them there's no point in them eating
space.
It's also why paren matching is so important in editors for Lisp -- if
you're not keeping track of them, the editor had better.
--tim
Johan Kullstam
> The reason C/C++ editors don't do parens matching is because it just isn't
> necessary.
my editor (emacs) does paratheses matching. i find it helpful for C/C++.
> There rarely is a case when you have more than 2 parenthesis
> right next to each other.
i find that parentheses get nested quite frequently. i am doing
number crunching oriented stuff so perhaps i get more than you. it
may be just a matter of personal coding style.
> In Lisp it's a given that you need parenthesis
> matching, because that's how you read the language.
not at all. when using a decent editor (emacs again), i just look at
the indentation. the parens take care of themselves. especially
closing parens. but then my editor helps me out.
there are many reasons to dislike lisp but the irrational fear of
parentheses has to be the most inane. all it says is, i saw a lisp
program and was afraid because i didn't immediately understand it.
anyone who has used the language for longer than five minutes can come
up with more relevant critism.
> Just like in C/C++ most
> editors support auto-indenting, because that's how you read C/C++ code.
> Putting parens matching in a C/C++ editor is like cracking a walnut with a
> sledgehammer.
i like my sledgehammer thank you very much. emacs - the swiss army
sledgehammer of editors.
--
johan kullstam
rusty craine
>>
>> My point is having ONLY the funny bastardized english-like IF
>> would be better, because THEN code would be easier to understand
>>
>
>he says, ``and has the same effect as WHEN if there is no ELSE
>clause.'').
A wonderful thing about lisp [in general] is that you can program in the
sytle you want to and lisp doesn't mind at all. Below is the lisp I fell in
love with years ago, and the exact program that did it for me. I still find
the goto's and all very readable, understandable, and pragmatic. Over the
years I have collected all the "queens" programs in lisp I could find. I
don't know if the later ones are any more readable or understandable then
this old one. As the general programming paradigms move, lisp moves with
them but [most of the time] doesn't force them on you. That is a good
thing.
Rusty
Place n queens on a board (graphical version)
; See Winston and Horn Ch. 11
;
; Usage:
; (queens <n>)
; where <n> is an integer -- the size of the board - try (queens 4)
;
; I do not know who the original Author of this is but it was found with
some
; XLISP example lisp programs. This has been slightly modified to run on
; PC-LISP V2.13.
;
; Peter Ashwood-Smith
; August 22nd, 1986
; Do two queens threaten each other ?
(defun threat (i j a b)
(or (= i a) ;Same row
(= j b) ;Same column
(= (- i j) (- a b)) ;One diag.
(= (+ i j) (+ a b)))) ;the other diagonal
; Is poistion (n,m) on the board safe for a queen ?
(defun conflict (n m board)
(cond ((null board) nil)
((threat n m (caar board) (cadar board)) t)
(t (conflict n m (cdr board)))))
; Place queens on a board of size SIZE
(defun queens (size)
(prog (n m board soln)
(setq soln 0) ;Solution #
(setq board ())
(setq n 1) ;Try the first row
loop-n
(setq m 1) ;Column 1
loop-m
(cond ((conflict n m board) (go un-do-m))) ;Check for conflict
(setq board (cons (list n m) board)) ; Add queen to board
(cond ((> (setq n (1+ n)) size) ; Placed N queens ?
(print-board (reverse board) (setq soln (1+ soln))))) ; Print it
(go loop-n) ; Next row which column?
un-do-n
(cond ((null board) (return 'Done))) ; Tried all possibilities
(setq m (cadar board)) ; No, Undo last queen placed
(setq n (caar board))
(setq board (cdr board))
un-do-m
(cond ((> (setq m (1+ m)) size) ; Go try next column
(go un-do-n))
(t (go loop-m)))))
;Print a board
(defun print-board (board soln)
(prog (size)
(setq size (length board)) ;we can find our own size
(princ "\f\n\t\tSolution: ")
(princ soln)
(princ "\n\n\t")
(print-header size 1)
(princ "\n")
(print-board-aux board size 1)
(princ "\n")
)
)
; Put Column #'s on top
(defun print-header (size n)
(cond ((> n size) (princ "\n"))
(t (prog () (patom n)
(princ " ")
(print-header size (1+ n))))))
(defun print-board-aux (board size row)
(princ "\n")
(cond ((null board) ())
(t (prog ()
(princ row) ;print the row #
(princ "\t")
(print-board-row (cadar board) size 1) ;Print the row
(print-board-aux (cdr board) size (1+ row)))))) ;Next row
(defun print-board-row (column size n)
(cond ((> n size)())
(t (prog ()
(cond ((equal column n) (princ "Q"))
(t (princ ".")))
(princ " ")
(print-board-row column size (1+ n))))))
Michael L. Harper
If you have ACL 5.0 (maybe only in the Enterprise version), its in the
distribution tree thats installed from the CD.
Mike Harper
Raffael Cavallaro
> my take on this is that parens are necessary in lesser languages only
> when the operator precedence no longer make sense, and thus signal that
> something is more "complex" than it would have been without parentheses,
> and perhaps adding parentheses is something the programmer does only
> after hours of debugging, reinforcing the pain factor.
And these painful experiences have impressed upon them the importance of
balancing parens. So they get one look at lisp code and say to themselves
"Aaagh! I can't balance all those parens - I'll *never* understand this
code," when of course nobody in their right mind tries to read lisp code
by balancing parens (editors do that for you) but rather from indentation,
and familiartiy with the indentation structure of common functions and
macros.
Unfortunately, most programmers *are* exposed to c-like languages before
they see lisp. The solution should be obvious to any enlightened school
board - make lisp instruction a required part of the kindergarten
curriculum ; )
Raf
--
Raffael Cavallaro
Christopher Browne
>Martin Rodgers wrote in message ...
>
>right next to each other. In Lisp it's a given that you need parenthesis
>matching, because that's how you read the language. Just like in C/C++ most
>editors support auto-indenting, because that's how you read C/C++ code.
>Putting parens matching in a C/C++ editor is like cracking a walnut with a
>sledgehammer.
But having parens matching (with the various varieties; [], (), {}) is:
a) Easy to do, and
b) A natural component of an "electric mode" where code is automagically
indented according to my favored policy.
--
cbbr...@ntlug.org- <http://www.ntlug.org/~cbbrowne/langlisp.html>
Oscar A. Chappel
programming in LISP for about 10 years. I had the opportunity to learn
and use the language long after I had been exposed to FORTRAN.
Fortunately, it was also long enough since I had used FORTRAN that I had
forgotten most of the syntax, so the parentheses were not such a
challenge.
Over the years, I have learned C++ and Java, out of necessity. I find
that working in these languages with the requirement to balance {} and
() and make sure that the ;s and ,s are in the right place is much more
distracting than programming LISP using an EMACS editor ever could be.
I think the problem with LISP's reputation stems from introductory or
survey courses that do not go into the depth of the language and provide
accurate discussions of the purpose of the parenthesis. I also believe
that students are not provided the opportunity to explore the power and
expressiveness of LISP. People are exposed to LISP as an AI language
with "Lots of Insipid Simple Parentheses" rather that a robust language
that supports the development of elegant solutions in a very few lines
of code and by-the-way, also supports AI work.
It appears to me that Java is a C/C++ programmers attempt to achieve the
capabilities that LISP has displayed for 40 years in a syntax that is
most familiar to C/C++ programmers.
Oscar Chappel <ocha...@aol.com>
Raffael Cavallaro
<ocha...@mitre.org> wrote:
>People are exposed to LISP as an AI language
>with "Lots of Insipid Simple Parentheses" rather that a robust language
I think that's "Lots of Irritatingly Superfluous Parentheses" ; )
>It appears to me that Java is a C/C++ programmers attempt to achieve the
>capabilities that LISP has displayed for 40 years in a syntax that is
>most familiar to C/C++ programmers.
It might be more accurate to say java is an attempt to achieve the
capabilities of Smalltalk in a syntax that C/C++ programmers (read, Sun's
large cadre of unix c hackers) could understand. Of course Smalltalk was
itself inspired by lisp, so... But seriously, the kind of capabilites
found in lisp closures (or Smalltalk closures, for that matter) are only
tacked on to Java as a poorly implemented afterthought.
Raf
--
Raffael Cavallaro
Will Hartung
>is the bizzar construct like this:
>
>statement unless cond;
>statement if cond;
This used to be popular in VAX BASIC (or as we called it at the time,
BASCALTRAN).
You could do frightening things like
sum=sum+a[i] for i = 1 to 10 unless dontsumit=1
In some senses I like it in a stream-of-consciousness kind of way.
Will Hartung
(wi...@msoft.com)