do...until wisdom needed...
Ken Peek
"do...until" construct in Python. This would be preferable to using a "while"
construct if you wanted to make sure the loop will execute at least once. You
CAN do this with a "while" construct, but it requires fiddling with the loop
condition before the "while" construct, which is "messy". An example:
condition = TRUE # make sure loop runs at least once
while (condition):
# do some stuff
# do some more stuff
condition = whatever_stops_the _loop
Here is my question-- If Python WERE to have a "do...until" construct, what
would be the best way to implement the syntactical rules?
For example:
do:
# some stuff
# some more stuff
until (condition == TRUE) # ("until" must be last statement or there is an
error)
OR:
do:
# some stuff
# some more stuff
until (condition == TRUE)
OR: ???
Ixokai
construct is:
while 1:
statements
if condition:
break
Its in-elegant, and even ugly, IMHO. I think there's a reason that there is
no do-while construct, otherwise I can't fathom why they wouldn't have put
it in yet.. this is something that comes up frequently.
--Stephen
(replace 'NOSPAM' with 'myseraph' to respond in email)
"Ken Peek" <Pe...@LVCM.comNOSPAM> wrote in message
news:tdku4kq...@corp.supernews.com...
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Terry Reedy
what
> would be the best way to implement the syntactical rules?
This has been discussed ad nauseum for years with no agreement. If and
when maillist or newsgroup archives are available, you can review at your
leisure.
deadmeat
what
> would be the best way to implement the syntactical rules?
until a == b:
some
thing
ie. the same as while, except until guarantees at least a single recursion.
this would mean very little change to Python to implement, just a minor
modification on the while handler.
it's not as clear as do (code) until but I don't like ending code blocks
with with control structures... esp. not in Python.
Ken Peek
it will be implemented or not. I am looking for what would be the correct
"Pythonic" construct if it WERE implemented...
"Terry Reedy" <tjr...@udel.edu> wrote in message
news:9bdv6f$quq$1...@news.udel.edu...
Ken Peek
before the loop starts, and it is not obvious that the loop executes once
anyway.) I too share your dislike for the control structures at the end of code
blocks-- but, what to do? (Pun intended!)
"deadmeat" <root@[127.0.0.1]> wrote in message
news:HZvC6.2488$p5....@news1.rivrw1.nsw.optushome.com.au...
Andrew Dalke
>Thank you for the history lesson. My question still stands-- I
>don't care if it will be implemented or not. I am looking for
>what would be the correct "Pythonic" construct if it WERE implemented...
>"Terry Reedy" <tjr...@udel.edu> wrote:
>> This has been discussed ad nauseum for years with no agreement. If and
>> when maillist or newsgroup archives are available, you can review at your
>> leisure.
But that's Terry's point. No one has decided on a "Pythonic"
construct, and there have been arguments on that topic. Nor
did he mention anything about implementation.
I just did a www.python.org/search for "do while until". The
first hit was to:
http://groups.google.com/groups?q=do+while+until&hl=en&lr=&group=comp.lang.p
ython.*&safe=off&rnum=1&seld=943960637&ic=1
and since I don't know if that link will really work, the thread
is named "why no "do : until"? and took place last December.
(There are older threads, but not indexed by Google.)
The consensus seems to be that there is no Pythonic syntax for
a do/until construct. It boils down to indentation. Both your
suggestions were proposed and it was decided that they didn't
make sufficient sense:
do:
spam
until cond
was found to be nothing more than an alias for
while 1:
spam
if not cond: break
and not worth introducing new syntax.
The other proposal is:
do:
spam
until cond
but this "does not fit a pythonic pattern for statements"
(Martijn Faassen). Reread the full thread for details.
So why didn't you believe that this exact history you were
looking for already existed in the easily searchable archives,
even after Terry pointed it out?
Andrew
da...@acm.org
Alex Martelli
news:3ada7eb9$1...@goliath2.newsfeeds.com...
> The standard Python Idiom (tm of someone, I'm sure :)) for a do-while
> construct is:
>
> while 1:
> statements
> if condition:
> break
Right.
> Its in-elegant, and even ugly, IMHO. I think there's a reason that there
is
> no do-while construct, otherwise I can't fathom why they wouldn't have put
> it in yet.. this is something that comes up frequently.
I think it's just the general Python approach -- _try_ not to provide many
equivalent ways to express the same design idea, but, rather, _one_
'obviously
right' way. Of course, this is just an ideal -- in practice, there often
are many
ways to express one idea in Python -- and it's indeed provably impossible to
actually meet it, since people's minds work in sufficiently diverse ways
that
even the most 'obviously right' choices won't be obvious nor feel right to
SOME individuals. It's still a good idea, "to reach the moon, aim for the
stars", since the alternative, to stuff a language with as many diverse ways
of expression as anybody can possibly think of, leads to language bloat a
la PL/I, Ada, C++, Perl. The ideal of avoiding redundant features at least
keeps a language _reasonably_ small, although inevitably it will irk those
who have particular attachment to some of the excluded features.
Alex
Alex Martelli
news:tdku4kq...@corp.supernews.com...
> Here is my question-- If Python WERE to have a "do...until" construct,
what
> would be the best way to implement the syntactical rules?
It would be best to have one general guarded-loop construct implementing
the Knuthian "N and 1/2 times" loop, rather than two different constructs
each implementing only a special case of it. Exact syntax sugar could be
endlessly (and fruitlessly) debated, but the general idea might be:
loop:
[suite 1]
while [condition]:
[suite 2]
The 'loop' keyword and associated [suite 1] would be optional, so that just
by omitting this clause one would get back to today's while-loop. It is
highly debatable whether [suite 2] could be made optional (together with
the trailing colon on the while clause) -- it might look nice but I think it
would run counter to all of Python's regular syntax (colons are never
optional; where a suite is undesired one writes the pass statement).
In today's Python syntax, this general loop can be expressed with exactly
this Knuthian semantic, BUT the guard clause must be indented the same
as the guarded suites in the loop body -- that would be the main difference.
(Curiously, [suite 2] in today's syntax DOES turn out to be optional!).
Minor differences, strictly sugary ones, are on the spelling of the
clauses --
today, 'loop:' is spelled 'while 1:' and 'while condition:' is spelled
'if not condition: break'.
Alex
Ken Peek
I will repeat a private email I sent to Paul Foley:
I am writing my own language based on Python for deeply embedded systems. I
am not trying to change the Python language. I would like all of the
traditional looping constructs in my new language, and so was trying to get
your opinion as to the best way to implement a "do...until" construct. Yes,
I know that the "while" construct CAN be used, but it is not the "syntactic
candy" that we have all come to know and love. I also plan on adding a
logical XOR operator, a logical shift right, and a few other things such as
absolute static typing, constants, constant pointers (for directing absolute
I/O in memory mapped I/O systems), etc. etc.
So, now that you know that I really am asking what I said I was asking, how
about answering my original question?
--Thanks
"Andrew Dalke" <da...@acm.org> wrote in message
news:9be82a$eq7$1...@slb6.atl.mindspring.net...
Ken Peek
Ken Peek
Fredrik Lundh
> So, now that you know that I really am asking what I said I was asking, how
> about answering my original question?
you still haven't explained why you're too lazy to check the news-
group archives, though...
compared to everything you need to deal with when reimplementing
Python, typing a few words into google's search box cannot be that
hard, can it?
Cheers /F
Ken Peek
and read that, and my questions were still not adequately answered. I think now
that I am looking more for a philosophical answer, not a "how to... in
Python"...
The do/until construct is *still* needed IMHO, to allow for a more structured
approach to programming. Many folks have given excellent suggestions on how I
could FORCE the "while" construct to do what I want, but then I *could* use a
bunch of "goto's" (if they were available. All of these will work, but are
still not good structured constructs. They are also not intuitive to newbies of
the language...
Now, if you please,-- Just make believe that Guido announced that he was going
to put a "do/until" construct into the next release, and wants your opinion of
how the syntax should work. You have no choice-- it IS going into the language.
Comments?
"Fredrik Lundh" <fre...@pythonware.com> wrote in message
news:k8DC6.7505$4N4.1...@newsc.telia.net...
Steve Lamb
>The do/until construct is *still* needed IMHO, to allow for a more structured
>approach to programming.
Operative word, opinion. Personally, I quite like not having a gaggle of
loop constructs to go through. 2 suits me just fine. One that loops over a
block of code until I tell it to break for some reason or another and one that
loops over a list until the list is finished or I tell it to break for one
reason or another. That covers darn near all cases that I can think of
without getting into special cases and trying to remember symantics of one
versus another. Granted, iterating over a list could be done within the
confines of the other loop but it is something done often enough that I agree
with Alex in that it deserves its own syntax.
Everything else, no.
>Many folks have given excellent suggestions on how I could FORCE the "while"
>construct to do what I want,
Then you question was answered.
>Now, if you please,-- Just make believe that Guido announced that he was
>going to put a "do/until" construct into the next release, and wants your
>opinion of how the syntax should work. You have no choice-- it IS going into
>the language.
This is how it would be done:
while (1):
do.stuff()
if condition:
break
You wanted to know the Python way, that /IS/ the Python way. It may be
idiomatic, it may piss you off, it may offend your sensibilities, but to me it
is far easier to read than:
do:
do.stuff()
until condition
Why? Because I have to remember what the difference is between do and
while (and C/Perl's for since I'm sure you're in love with that construct as
well). Of course let's not even get into mentioning that in neither case does
the keyword actually tell you anything about the loop itself as both can
contain escape or shortcut conditions.
To give an example of why more keywords are a bad thing, look at Perl. I
have to because that is my job as much as I wish I could work in Python. But
look at Perl and let's take something even far simpler than a loop. Let's
take a simple conditional statement.
print("I'm a packet!") unless (packet_loss);
Simple enough. Readable enough right? Well, what happens if you wanted
to put an else? Well, now you have to change it around, right?
unless (packet_loss) {
print("I'm a packet!");
}
else {
print("I'm lost!");
}
Whoops, problem, no else on unless. So now we have to change it around.
if (!packet_loss) {
print("I'm a packet!");
else {
print("I'm lost!");
}
Well, lookie here, we've gone from a "readable" line to, well, a block
that most likely looks like a dozen other blocks of code. What that means is
the first syntax I gave is a specialized case that needs to be learned in
addition to the mainstay case. In perl there are 4 ways to express the above
simple example, 4 different things that need to be learned. Python, 1. Guess
which one many people consider easier to learn, read and write.
So, you want to know what the Python way would be? You were told. You
want to reimplement the language for your embedded system and include a
do..until loop? Fine. But remember that is /your/ language, the final
decision rests with you, and chances are it won't be Pythonic if you implement
do..until.
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
ICQ: 5107343 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------
Steve Lamb
>print("I'm a packet!") unless (packet_loss);
[snippage]
>In perl there are 4 ways to express the above simple example, 4 different
>things that need to be learned.
Hmmm, as always upon rereading I realized that I was wrong in saying 4.
Forgiving the differences once can have in indention...
statement unless (condition)
statement if (!condition)
statement if (not condition)
unless (condition){statement}
if (!condition) {statement}
if (not condition) {statement}
6. I forgot about ! versus not. Now, raise your hand if you know that
there is a difference between ! and not. Keep it raised if you can, without
looking at any reference book, explain the exact difference between ! and not.
Keep it raised if you can further explain the differences (if any) between
not, ! and unless in the above examples. Remember, no peeking at a book.
Benjamin.Altman
"until" like:
# do some stuff
# do some more stuff
until condition == true
Remco Gerlich
So how would you put that after another block?
while cond():
#bla
#bla
#bla
#do some stuff
until cond2()
That doesn't work. You need a proper non-indented block start.
Besides, it's ugly :).
--
Remco Gerlich
Andrew Dalke
>I am writing my own language based on Python for deeply embedded systems.
I
>am not trying to change the Python language. I would like all of the
>traditional looping constructs in my new language, and so was trying to get
>your opinion as to the best way to implement a "do...until" construct
>So, now that you know that I really am asking what I said I was asking,
>how about answering my original question?
Your original question:
> If Python WERE to have a "do...until" construct, what
> would be the best way to implement the syntactical rules?
These two questions aren't the same. Your original one refers to
Python, which means amoung other things a viewpoint that a minimal
number of contructs - but not the absolute minimum because there
are practical reasons for non-orthogonality - is appropriate.
In my C code (I've written order(100KLOCs) of production code)
I use "do" about once a year. Every time I use it I need to pull
out K&R or grep existing code because I've forgotten the syntax.
The pythonic view is that this construct saves at most two lines
which does not justify the effort of having to remember how
a do..until is used.
BTW, in my C code I now use while(1) { code; if (cond) break;}
I pulled out K&R 2nd edition, section 3.6 pp63-64 talks about
C's Do-while loop. It says:
] Experience shows that do-while is much less used than while
] and for. Nonetheless, from time to time it is valuable, as
] in the following function itoa ...
The atoi code could be rewritten to use a while with overall
two more lines of code. If you agree that do..while is used
5% of the time while is used, and while construct syntax takes
up less than 1% of working code, then there is a 0.1% increase
in code size at the expense of understanding.
That's one fundamental reason why do..until is not Pythonic.
The other one is that no one could think of a nice way to
do the indentation given that it requires two control statements,
and all control statements in Python are dedented, end with a :
and have code following the statement. The "until" clause
breaks one of those, unless you always follow it with a dummy
"pass" statement.
Now to your real question:
> I would like all of the traditional looping constructs in
> my new language, and so was trying to get your opinion as to
> the best way to implement a "do...until" construct.
By all means, use
do:
code
until condition
That's not Pythonic and won't be added to Python, but you
aren't talking Python. Although I would suggest using 'while'
because of the parallel with C and because it saves a keyword.
Andrew
da...@acm.org
Benjamin.Altman
would have to do:
while cond():
#bla
#bla
#bla
#do some stuff
until cond2()
So the #do some stuff is done until cond2() is satisfied. The until is inline with the
#bla code and the contents of the until are indented one level further.
Benjamin.Altman
Why couldn't you just say that "all control statements in Python are dedented,
end with a :" _because they_ "have code following the statement."? So if one
would be created that doesn't have code following, there would be no need for it
to end with a ":" and it could be dedetended from the other end...
Steve Lamb
wrote:
>Ugliness aside, it would work since it is dependant on indentation. In your
>example you
>would have to do:
> while cond():
> #bla
> #bla
> #bla
>
> #do some stuff
> until cond2()
>
Please, no jeopardy quoting, it makes it hard to keep a discussion
readable.
>> Benjamin.Altman <benjami...@noaa.gov> wrote in comp.lang.python:
>> So how would you put that after another block?
>>
>> while cond():
>> #bla
>> #bla
>> #bla
>>
>> #do some stuff
>> until cond2()
No, he was asking a very valid question. Take the following example.
for x in y:
do_something()
while(1):
do_another_thing()
if condition:
break
Well, since we're discussing taking a while(1):...break and turning it
into a do..until /and/ your suggestion is to do a reverse off the until
keyword now translate the above block into your proposed syntax.
for x in y:
do_something()
do_another_thing()
until cond()
Uhm, how do you tell the two loops apart? AFAICT, he was not asking about
one loop nested inside another, he was asking about one loop following
another.
Benjamin.Altman
Marcin 'Qrczak' Kowalczyk
> statement unless (condition)
> statement if (!condition)
> statement if (not condition)
> unless (condition){statement}
> if (!condition) {statement}
> if (not condition) {statement}
Don't forget:
condition or statement;
!condition and statement;
not condition and statement;
condition || statement;
!condition && statement;
(not condition) && statement;
--
__("< Marcin Kowalczyk * qrc...@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
Steve Lamb
wrote:
>Mon, 16 Apr 2001 16:19:42 -0000, Steve Lamb <gr...@despair.rpglink.com> pisze:
>> statement unless (condition)
>> statement if (!condition)
>> statement if (not condition)
>> unless (condition){statement}
>> if (!condition) {statement}
>> if (not condition) {statement}
>Don't forget:
>condition or statement;
>!condition and statement;
>not condition and statement;
>condition || statement;
>!condition && statement;
>(not condition) && statement;
Well, these start delving into compound conditions, I was purposely
keeping with the simplistic view but, yes, those are other methods of doing
so. :)
Alex Martelli
> Please see my answer to Andrew Dalke in a sub-thread above...
I've seen it, and in no way does it address my response. I repeat
the meaningful part:
"""
It would be best to have one general guarded-loop construct implementing
the Knuthian "N and 1/2 times" loop, rather than two different constructs
each implementing only a special case of it. Exact syntax sugar could be
endlessly (and fruitlessly) debated, but the general idea might be:
loop:
[suite 1]
while [condition]:
[suite 2]
The 'loop' keyword and associated [suite 1] would be optional, so that just
by omitting this clause one would get back to today's while-loop.
"""
If you want to tweak the syntax sugar by having, e.g., 'do:' instead of
'loop:', this strikes me as crazy (why imply something is just "done",
which does NOT communicate repetition, when "loop" DOES?!), but,
hey, it's your fune^H^H^H^H language, go right ahead. Similarly
for other potential atrocities such as introducing 'until floop' as a
synonym or replacement of 'while not floop'.
It IS better to have one general tool than two special-purpose tools
(which, together, don't equal the expressivity of the former!), if and
only if the general tool doesn't make you pay a price in terms of
_simplicity_. The Knuthian loop/while is utterly simple. You may
choose to make it a bit richer still without adding _complexity_ (nor
real complication) by having more optional clauses, a la:
loop [while condition1] [:
[suite1]]
{while conditionN[:
suiteN]
}
where metasyntax [...] indicates an optional part (0 or 1 times)
and { ... } indicates repeatability (0 to N times for any N). This
gives "more than one way to do it" for typical constructs such
as while-loops, so it would be inappropriate in Pythonic terms,
but the language you're designing is not Python. Alternatively,
you might choose to make the 'loop' keyword NON-optional:
have it introduce ALL loops and gain regularity. Classic loops
would then be:
loop while condition:
suite
for a normal while loop (test-at-start, 0-or-more-times),
loop:
suite
while condition
for a test-at-end (1-or-more-times) loop. Knuthian
N-and-1/2-times (test-in-the-middle) would be:
loop:
suite1
while condition:
suite2
and you could have more than one 'while' for the same loop
for non-classic variants (you could choose to prohibit them,
mandating "exactly one while clause per loop", if you wish).
Alex
Douglas Alan
> Exact syntax sugar could be endlessly (and fruitlessly) debated, but
> the general idea might be:
Python should have procedural macros like Lisp. Then whenever anyone
asks a question about why Python doesn't have syntactic feature xyzzy,
the answer can always be, "You can already do what you want by loading
the following macro...."
|>oug
Alex Martelli
news:lcbspw1...@gaffa.mit.edu...
Yes, 'hygienic macros' WOULD help cut these discussions short. Pity
this benefit (basically restricted to c.l.p) would be balanced by the
productivity loss engendered by the actual existence of such macros
in the language -- a language which may have ANY 'syntactic feature'
ensures any given program is impossible to understand unless you
first study the exact set of macros used by its author:-).
Alex
Douglas Alan
> "Douglas Alan" <nes...@mit.edu> wrote in message
> > "Alex Martelli" <ale...@yahoo.com> writes:
What happened to giving programmers enough rope to hang themselves?
What happened to the desire for flexibility and expressive power?
Sure, macros are a long rope, but some tasks require a long rope.
Take a look at Guy Steele's maxim that a large language is impossible
to design well, but a small language is doomed to die. A language
needs to be able to grow over time. Procedural macros in Lisp allowed
Lisp to continue to evolve over time, so that even though it was
invented in the '50's, it remains today one of the most modern of
languages. It was able to do this, in part, by allowing every user to
experiment with adding language features, not just the language
Illuminati.
And macros don't ensure that *any* given program is impossible to
understand -- it only helps nutty programmers make programs that are
impossible to understand. Conversely, macros can help wise
programmers in making programs that are shorter, easier to understand,
easier to code, and easier to maintain.
|>oug
Courageous
>Thank you for the history lesson. My question still stands-- I don't care if
>it will be implemented or not. I am looking for what would be the correct
>"Pythonic" construct if it WERE implemented...
The correct "Pythonic" construct is:
C//
Courageous
>Sometimes, when writing code, I find it would be nice if there were a
>"do...until" construct in Python.
One of the essential appeals of Python is its small number of forms. This small
number of forms ensures that new Python programmers are more likely to be
able to read code written by experienced Python programmers.
There's a thousand people who have "it would be nice" recommendations for
new Python forms. This, however, is unPythonic. Try another language. Or get
the Python source and add all the forms you want. You might call it:
"PythonWithExtraStuffToMakeItHarderToLearn".
C//
Andrew Henshaw
for a suitable 'until' syntax. However, I have advocated that 'do' as an
alias for 'while 1', would be cleaner, more elegant, and simpler to grasp
for new programmers (e.g., children).
Therefore, in a half-attempt to answer your question, I believe that most
Pythonic implementation of do-until would be:
do:
some code
if condition:
break
Andrew Henshaw
Sheila King
<andrew_dot_henshaw_at_earthling_dot_net> wrote in comp.lang.python in article
<tdnbgap...@corp.supernews.com>:
:However, I have advocated that 'do' as an
:alias for 'while 1', would be cleaner, more elegant, and simpler to grasp
:for new programmers (e.g., children).
:
:Therefore, in a half-attempt to answer your question, I believe that most
:Pythonic implementation of do-until would be:
:
:do:
: some code
: if condition:
: break
But, as already mentioned in this thread, the word "do" doesn't necessarily
imply looping.
Wouldn't this be even more preferable?
loop:
some code
if condition:
break
--
Sheila King
http://www.thinkspot.net/sheila/
http://www.k12groups.org/
Ken Peek
To the "others", I say:
"If the only tool you have is a hammer, then every problem looks like a nail."--
Happy nailing!
Steve Lamb
It seems you me you're the one with a lot of wood for do..until even
though it has been explained why it is a bad thing.
Alex Martelli
[snip]
> > Yes, 'hygienic macros' WOULD help cut these discussions short. Pity
> > this benefit (basically restricted to c.l.p) would be balanced by
> > the productivity loss engendered by the actual existence of such
> > macros in the language -- a language which may have ANY 'syntactic
> > feature' ensures any given program is impossible to understand
> > unless you first study the exact set of macros used by its
> > author:-).
>
> What happened to giving programmers enough rope to hang themselves?
That's C++'s specialty (it's actually "enough rope to shoot
themselves in the foot" -- unless you mix metaphors a LOT,
you ain't gonna grok C++ nohow).
> What happened to the desire for flexibility and expressive power?
At a MICRO level ("programming in the small") it's never been
part of Python's design goals to provide many ways to express
one design idea. "There should be ONE 'obviously correct' way
to do it" is one of the Python mantras -- clearly an ideal, one
that is totally unattainable of one dreams of something being
'obvious' to ALL the nutty individuals that write on Usenet
(you'll never get 100 out of 100 regular Usenet posters to
agree on ANY single issue -- I await expressions of total
disagreement about that, of course), and unattainable in its
totality even on a pragmatical plane where one is satisfied to
cater for sensible people. It's still a wonderful ideal in
the "to reach the moon, aim at the stars" spirit: by aiming
consistently at this unattainable goal, Python still manages to
get better stylistic uniformity across its disparate user base
than any other widespread language (in my limited experience:
I have NOT used ALL widespread languages enough to get a real
good feeling about stylistic variety among programmers).
The only real downside of this is that it DOES make for
interminable Usenet discussion with people who don't understand
the import of "If you want X, you know where to find it" (see
http://info.astrian.net/jargon/terms/i/If_you_want_X_you_know_where_to_find_
it.html
) for suitable values of X.
Programming languages, like political parties, come as
"packages". You won't like _everything_ you find there,
that is almost guaranteed: to get enough people together
to call it a "party", SOME aspect of the party's program
is likely to be very unpleasant for any given member.
Alternatives are: form your own party, whose program is
EXACTLY the set of your ideas about things (this seems
to be the currently preferred Italian solution, as we
have many dozens of parties with representatives in
Parliament -- of course, to hope to form a _government_,
they have to group into coalitions, meta-parties, so
on one side you find everybody from communists to a
guy who spent 20 years as the director of the IMF --
on the other side, everybody from post-fascist paladins
of a strong centralized state to would-be-secessionists
whose dream is to make of Lombardia a separate state...
so the "package" problem perks up again:-).
This strategy is apparently the one the original poster
to this thread is following -- he's bent on designing
his own language and is just asking for suggestions on
how to about designing it. Fine!
Or else, join an existing party and try to influence it
so its political program becomes closer to your wishes.
Which is also fine. But you have to learn enough about
political parties to see what aspects of their program
ARE ones you can influence -- "superficial" ones, so to
speak, the kind that ARE going to be changeable -- and
which ones are the VERY NATURE of the party. If the
things you find unacceptable are deep-rooted ones in
the party's membership and history, then, in general,
striving to change them is similar to trying to teach
a pig to whistle -- it wastes your time, and annoys
the pig. And it's unlikely to produce the kind of
melody that will make the resulting MP3 a real hit.
It appears to me that the changes you want to see in
Python are very much of the pig-whistling kind: you
want variables to be declared (in another thread), you
want infinitely variable syntax sugar via macros (at
least, I hope, of the hygienic kind). Hmmm, you sure
you wouldn't want some sort of explicit bracketing in
lieu of indentation for grouping, or inheritance to
be restricted to single rather than multiple, or...?-)
Are you perchance at the same time an activist in the
Republican Party striving to make the party support
higher taxes, stricter Federal control on States, and
more welfare including free health-care for all...?
[The funny thing is that such epochal changes in a
party's fundamentals DO happen -- once per epoch.
Certain core values may apparently vanish (or we
would not see a pro-business, fiscally prudent
Labour government!) and others are born and take
roots (the Tories' current Euro-hostility, for
example). The mutation of Algol into Algol-68 is
an example of a similar epochal event in the field
of programming languages. Of course, it DID spell
the death of Algol as a practical-use language --
just like a non-type-safe, non-class-centered
Eiffel, a non-pure, non-lazy Haskell, or a Python
with declarations and hygienic macros, would have
no real reason to survive. Such disintegrations
due to "loss of core values" don't ALWAYS happen --
the old _name_ may happen to survive even as the
deep nature of the language is totally changed,
cfr. Fortran -- but they happen regularly enough
to explain why somebody who particularly cares for
a language's (or a party's) current core-values
will react to the proposal of so-called
"improvements" which are in fact rather obvious
attacks against its core.].
> Sure, macros are a long rope, but some tasks require a long rope.
IF there are tasks that require a year-light worth of
rope (a separate debate), it's still extremely silly
to want to attach that thread to unsuitable frames.
There are so MANY languages whose core values do *NOT*
include simplicity and stylistic uniformity, that it's
truly perverse to strive to destroy such uniformity
and simplicity in one of its few "safe harbors".
> Take a look at Guy Steele's maxim that a large language is impossible
> to design well, but a small language is doomed to die. A language
The obvious consequence if one believed that would be to
design a mid-size language -- isn't that what Steele tried
to do in Java? Python is clearly large enough to survive
(the steady, unflagging growth of interest in it over the
years attests to that) -- some of its fanatics think it's
TOO big (or threatens to become so) with the introduction
of list comprehensions or nested scopes. So, if you like
this maxim, considering Python "mid-size" makes sense.
> needs to be able to grow over time. Procedural macros in Lisp allowed
> Lisp to continue to evolve over time, so that even though it was
> invented in the '50's, it remains today one of the most modern of
> languages. It was able to do this, in part, by allowing every user to
> experiment with adding language features, not just the language
> Illuminati.
So use Lisp! Who's holding you back? It IS an excellent
language and has splendid implementations. Why do you want
to make Python into Lisp?
Some of us believe Common Lisp is too complex. Some of
us think that hygienic macros make _Scheme_ too big too.
Even _Dylan_, for all of its beauty, and the true awesome
power of multi-methods, is not what I use, in good part
*BECAUSE* of the complication macros engender in my view.
You have not explained, I think, why _YOU_ would want to
use Python rather than Common Lisp, Scheme, or Dylan. They
have hygienic macros AND variable declarations too. You
say that's what you want -- OK, there they are. What does
Python have that they lack, EXCEPT the simplicity (and
fluidity &c due to lack of declarations) that you would
rob from it if you had your way?!
> And macros don't ensure that *any* given program is impossible to
> understand -- it only helps nutty programmers make programs that are
> impossible to understand. Conversely, macros can help wise
> programmers in making programs that are shorter, easier to understand,
> easier to code, and easier to maintain.
Sure -- a perfect programmer (a very hypothetical beast) will
use ANY given tool perfectly (by definition). All you say
here applies just identically to the NON-hygienic macros of
C, for example. They CAN in fact be used to good effect
(cfr. the Python C API for some good, typical examples), and
C would not be half as successful as it is if it didn't have
its preprocessor or some other equivalent tool. _IN PRACTICE_,
out in the field, you'll find C macro abuse rampant -- one of
the most serious causes of maintenance nightmares.
Python can live without macros as it has the expressive
power needed to express any design idea it could express
with macros, _net of syntax-sugar considerations_. See
the recent thread about '#define' for some examples.
You can't arbitrarily alter syntax-sugar to introduce
an 'unless condition:' synonym for 'if not condition:',
etc -- true. And *GOOD* in the Python Weltanschauung!!!
As you seem totally unwilling or unable to understand that
Weltanschauung to any extent, I don't see how you could
bring Python any constructive enhancement (except perhaps
by some random mechanism akin to monkeys banging away on
typewriters until 'Hamlet' comes out, I guess).
Alex
Christopher A. Craig
> What happened to giving programmers enough rope to hang themselves?
> What happened to the desire for flexibility and expressive power?
You can still get this, just not in Python. If you want a long rope,
you still have Lisp, C, C++, and Perl. One of the principles that
makes Python so popular is its simplicity. Any reasonably skilled
programmer can learn every important part of the Python syntax in less
than a day. Sure C++ is a more flexible language than Python. But, I
have read the entire language reference for Python, it took a couple
hours; it would take me a couple hours to carry the C++ language
reference up to my 4th floor desk. I have never seen a Python program
that I couldn't sit down and read with little effort; I rarely see a
Perl program that I can.
If you go adding macros to Python then you remove that simplicity.
You would make it so that any programmer can add arbitrary levels of
complexity to the syntax used in the program, and thus before reading
through code a programmer would have to read and understand the macros
used. You can do this now by passing your program through m4 before
Python parsing it, but you wouldn't be programming in Python. And
that really is the point.
--
Christopher A. Craig <ccr...@ccraig.org>
"You could shoot Microsoft Office off the planet and this country would
run better. You would see everyone standing around saying, 'I've got
so much time now.' " Scott McNealy (CEO of Sun)
Christopher A. Craig
Douglas Alan <nes...@mit.edu> writes:
> What happened to giving programmers enough rope to hang themselves?
> What happened to the desire for flexibility and expressive power?
You can still get this, just not in Python. If you want a long rope,
you still have Lisp, C, C++, and Perl. One of the principles that
makes Python so popular is its simplicity. Any reasonably skilled
programmer can learn every important part of the Python syntax in less
than a day. Sure C++ is a more flexible language than Python. But, I
have read the entire language reference for Python, it took a couple
hours; it would take me a couple hours to carry the C++ language
reference up to my 4th floor desk. I have never seen a Python program
that I couldn't sit down and read with little effort; I rarely see a
Perl program that I can.
If you go adding macros to Python then you remove that simplicity.
You would make it so that any programmer can add arbitrary levels of
complexity to the syntax used in the program, and thus before reading
through code a programmer would have to read and understand the macros
used. You can do this now by passing your program through m4 before
Python parsing it, but you wouldn't be programming in Python. And
that really is the point.
--
Christopher A. Craig <com-n...@ccraig.org>
D-Man
| (you'll never get 100 out of 100 regular Usenet posters to
| agree on ANY single issue -- I await expressions of total
| disagreement about that, of course),
I disagree with you. If I didn't your statement would
backfire <wink>.
-D
Benjamin.Altman
how it is so complicated. Even the c equivalent isn't that complicated - it is
almost intuative. Someone in this thread mentioned that they needed to go back
to k&h to recall it and I can't quite understand why (even though you might say
that recollection and simplicity are mutually exclusive).
Ben.
Benjamin.Altman
did they create the lambda notation?
Steve Lamb
>(you'll never get 100 out of 100 regular Usenet posters to
>agree on ANY single issue -- I await expressions of total
>disagreement about that, of course)
I dunno, Hitler could find a way.
Yess, that was an attempt at Godwin. No offense, Alex. :)
Aahz Maruch
Benjamin.Altman <benjami...@noaa.gov> wrote:
>
>If Python is supposed to provide one obviously correct way of doing
>things why did they create the lambda notation?
It was a mistake. Seriously. Ask Guido sometime.
--
--- Aahz <*> (Copyright 2001 by aa...@pobox.com)
Androgynous poly kinky vanilla queer het Pythonista http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6
"If we had some ham, we could have ham & eggs, if we had some eggs." --RH
Steve Lamb
wrote:
>While I wouldn't care either way for a loop.. until construct, I don't quite
>see how it is so complicated.
It isn't complicated in and of itself. Look at my example of Perl's
handling of a simple conditional expression. 6 different ways to express one
concept. Taken individually each is not that difficult to understand. Taken
together it is a maintenance nightmare. I should know, I have to deal with
the "simplicity" of those 6 different ways to express one concept on a daily
basis at work. My way of handling it is to force myself to standardize on the
most common and extensible format (if (!condition){}) and rewrite all other
forms to that when encountered. Even then I am only reducing it to one of two
possible formats and dealing with precidence issues.
Well, actually, 12 as someone has pointed out. I'm sure we're missing
more. 12 with their own slightly variant way of doing things. That is where
the complexity comes in.
No, do..until is not that hard. Heck, IIRC the language I learned
procedural programming in, Turbo Pascal, has it. But having it when it
clearly isn't needed only adds unneeded complexity.
What I find most ironic is this discussion was spawned by someone who
wants to reimpliment Python for an embedded system. One would think that on
an embedded system that one would want to conserve space by using the least
number of variations of common concepts, not waste it implementing several
special cases.
Dave LeBlanc
to make rope out of ((((((jello)))))).
Dave LeBlanc
Dave LeBlanc
statement_list
:while condition
Dave LeBlanc
On Mon, 16 Apr 2001 23:05:10 -0700, "Ken Peek" <Pe...@LVCM.comNOSPAM>
wrote:
>Thanks to all for all of the great suggestions!
Alex Martelli
news:3ADC4E60...@noaa.gov...
> If Python is supposed to provide one obviously correct way of doing things
why
> did they create the lambda notation?
Historically, I believe, because some user way back
when supplied patches for that and map/reduce/filter,
and the normally very sensitive screens of our BDFL
didn't trigger. But I wasn't around then, so I have
it second-hand. Today, of course, many long-time
users are hopelessly in love with lambdas, so it's
out of the question that they'll ever be removed
(I think even the mythical Py3k never dreamed about
doing that).
Surely SOME old-timer who HAS been around throughout
can give more solid info on this historical-interest-
only item...?
Alex
Aahz Maruch
Steve Lamb <morp...@here.not.there> wrote:
>
> Yess, that was an attempt at Godwin. No offense, Alex. :)
One of the corollaries to Godwin is that deliberately invoking Godwin
doesn't count.
Douglas Alan
> Douglas Alan <nes...@mit.edu> writes:
> > What happened to giving programmers enough rope to hang themselves?
> > What happened to the desire for flexibility and expressive power?
> You can still get this, just not in Python. If you want a long rope,
> you still have Lisp, C, C++, and Perl.
A common answer I see in this newsgroup is that Python gives you a
long rope. For instance, when people complain that they get bugs due
to accidentally assigning to the wrong variable because variables
don't have to be declared, people respond by saying that Python gives
you a long rope. These people apparently they don't want to suffer,
even for significantly increased reliability, the very minor
limitations that variables declarations would entail. But then if
someone complains that Python doesn't give them a long enough rope in
some other area, the answer is that the proposed feature would allow
poor programmers to write unreadable programms. C'mon guys, be
consistent!
Personally, I want a language that gives me all the rope I need, but
doesn't make it a chore to write good programs. Writing good programs
in Perl is a chore; hence Perl sucks. If Python had procedural
macros, writing good programs would be less of a chore, not more of a
chore.
I don't want my language trying to force bad programmers to write good
code. If this is some sort of official design goal of Python, then it
is a misguided and impossible one.
Regarding Perl, it is the worst attrocity foisted on humanity since
the black plague. Regarding C and C++, they are not dynamic
languages. Regarding Lisp, I'd be happy to use it if it there was a
free implementation that had been ported to every platform known to
man, started up in a small fraction of a second, was particularly
well-suited to scripting, and came with the massive library and
user-base that Python does. But there isn't. Besides, I have plenty
of nits to pick with Lisp too.
> One of the principles that makes Python so popular is its
> simplicity.
"Everything should be as simple as possible, but no simpler."
> Any reasonably skilled programmer can learn every important part of
> the Python syntax in less than a day.
A macro capability doesn't detract from this.
> Sure C++ is a more flexible language than Python.
Not really. It's flexibility is along different axes.
> But, I have read the entire language reference for Python, it took a
> couple hours; it would take me a couple hours to carry the C++
> language reference up to my 4th floor desk. I have never seen a
> Python program that I couldn't sit down and read with little effort;
> I rarely see a Perl program that I can.
That's because Perl is the worst attrocity foisted on humanity since
the black plague.
> If you go adding macros to Python then you remove that simplicity.
Any feature added a language makes the language less simple. Python
is hardly a simple language anymore. It has a simple core, and that's
very important. C++ and Perl have no simple cores (unless, for C++,
you just stick to the C core). Every feature in these languages
interacts with other features in strange ways, so you better
understand the whole thing or you're asking for trouble. The motto of
the language "Logo" was "no threshold, no bounds". This should be the
motto of any langauge. A language should be easy to learn, but offer
untold power. If Python had procedural macros, the language wouldn't
be any harder to learn since this is not something a newbie would have
to worry about for quite some time. I programmed quite happily in
Lisp for more than a year without every worrying myself about how
macros worked. But when I needed them, there they were.
> You would make it so that any programmer can add arbitrary levels of
> complexity to the syntax used in the program, and thus before reading
> through code a programmer would have to read and understand the macros
> used.
A bad programmer has many tools available to him in Python, as it is,
to make hard to understand code. I don't think it would go over well
to remove useful features from the language to prevent this.
> You can do this now by passing your program through m4 before Python
> parsing it,
M4 is a far cry from procedural macros.
> but you wouldn't be programming in Python. And that
> really is the point.
Lisp didn't always have macros. But when they added them, it was
still Lisp.
|>oug
Steve Lamb
>A common answer I see in this newsgroup is that Python gives you a
>long rope. For instance, when people complain that they get bugs due
>to accidentally assigning to the wrong variable because variables
>don't have to be declared, people respond by saying that Python gives
>you a long rope. These people apparently they don't want to suffer,
>even for significantly increased reliability, the very minor
>limitations that variables declarations would entail. But then if
>someone complains that Python doesn't give them a long enough rope in
>some other area, the answer is that the proposed feature would allow
>poor programmers to write unreadable programms. C'mon guys, be
>consistent!
Personally I'd answer the former charge not with stating that Python gives
you a long rope, but that Python is doing the sensible thing. Variable
declaration has to be one of the most tedious thing held over from programming
for a different aim.
>Personally, I want a language that gives me all the rope I need, but
>doesn't make it a chore to write good programs. Writing good programs
>in Perl is a chore; hence Perl sucks.
Perl gives you all the rope that you need. Writing good programs in Perl
is not a chore. Maintaining good programs in Perl is a chore.
>If Python had procedural macros, writing good programs would be less of a
>chore, not more of a chore.
Writing good programs in Python now isn't a chore. The more I program in
Perl, the more I want to program in Python because of the fact that there are
less ways to do something. By giving macros you'd be giving more ways to do
something and lower the maintainability of the code.
The problem isn't that the language isn't flexible enough; it is plenty
flexible for the aims it has. The problem is that the programmers aren't
flexible enough in their laziness. It is something that I've had to overcome
time and again in my Python programming because of my Perl background. As
I've said, however, I prefer Python because I know that I'm quite likely to be
able to maintain someone else's three year old code without having to puzzle
over it for an hour and spend another three rewriting it to a maintainable
form.
>I don't want my language trying to force bad programmers to write good
>code. If this is some sort of official design goal of Python, then it
>is a misguided and impossible one.
I'd like to think that Python encourages programmers, good and bad, to
write maintainable/readable code. The quality of the code is immaterial.
As many people have pointed out even the loosest of languages do not force you
to write bad code any more than the tightest of languages force you to write
good code. In both cases it is entirely possible to add an element to an
array by first copying the array into another array and then adding the single
element instead of using a simple push() or .append().
The difference, however, in providing only what is needed and providing
6-12 different ways to express something, each with a slight variation on
behavior, is that in the former you only need to learn that one.
do..until is just a loop with the exit clause near the end of the loop
instead of the beginning. In Python, that is clear. while is the loop
keyword, if cond: break is the ending condition. No need to try to remember,
"OK, this looping keyword will iterate over the loop until the end except on a
full moon, in which case it will break before the first addition of two
integers unless it is also a Friday the 13th..."
>Regarding Perl, it is the worst attrocity foisted on humanity since
>the black plague.
Yet it provides exactly what you want, TIMTOWTDI.
>> Any reasonably skilled programmer can learn every important part of
>> the Python syntax in less than a day.
>A macro capability doesn't detract from this.
Yes, it does. It means that a person, beginner or expert, has to relearn
a particular person's idioms before being able to do anything productive. It
means every time you come in contact with a new person's programs you have to
relearn thier particular dialect of the language. That is not something that
can be learned in a day.
>That's because Perl is the worst attrocity foisted on humanity since
>the black plague.
Yet it offers exactly what you want. So why, then, do you want to turn
Python into the worst attrocity foisted on humanity since the black plague?
>Any feature added a language makes the language less simple.
Any feature which adds a massive layer of complexity (macros) or is
redundant (do..until) add needless complexity without adding an appropriate
benefit. A feature which is flat out missing and is not redundant of another
feature adds little complexity and a lot of appropriate benefit.
>Python is hardly a simple language anymore.
It is the simpliest of the several that I've come in contact with thus far
and I certainly appreciate it for that fact.
>A language should be easy to learn, but offer untold power.
Thus far I don't see many limits to Python's power because of its
simplicity. All I see are programmers who are whining that they can't have
their favorite construct instead of learning a new way to do things. Ironic
in that to implement their pet prodecure they are requiring everyone /ELSE/ to
learn something new.
>If Python had procedural macros, the language wouldn't be any harder to learn
>since this is not something a newbie would have to worry about for quite some
>time.
But is something that every expert would have to relearn each time they
tuch someone else's code.
>A bad programmer has many tools available to him in Python, as it is,
>to make hard to understand code. I don't think it would go over well
>to remove useful features from the language to prevent this.
This, of course, is also not an argument to add features which serve very
little purpose and add untold complexity. You said you programmed quite
happily in Lisp for over a year without macros. I contend that if the macros
weren't there you could have still programmed just as happily.
Douglas Alan
> "There should be ONE 'obviously correct' way to do it" is one of the
> Python mantras
This is a BAD mantra. Not as bad as the Perl mantra, "There should be
3294369 ways to do it", but extremes are rarely ideal. "The truth lies
somewhere in the middle."
Besides, there are many uses for procedural macros other than for
providing trivial syntactic sugars that are best done by using the
sugar already provided. It's not a good idea to throw the baby out
with the bathwater just because something can be misused.
> Or else, join an existing party and try to influence it so its
> political program becomes closer to your wishes. Which is also
> fine. But you have to learn enough about political parties to see
> what aspects of their program ARE ones you can influence --
> "superficial" ones, so to speak, the kind that ARE going to be
> changeable -- and which ones are the VERY NATURE of the party. If
> the things you find unacceptable are deep-rooted ones in the party's
> membership and history, then, in general, striving to change them is
> similar to trying to teach a pig to whistle -- it wastes your time,
> and annoys the pig. And it's unlikely to produce the kind of melody
> that will make the resulting MP3 a real hit.
I've been programming in Python plenty long enough to understand its
essence. Just because many people misstate its essence (by
overgeneralizing or undergeneralizing), doesn't make them right.
> It appears to me that the changes you want to see in Python are very
> much of the pig-whistling kind: you want variables to be declared
> (in another thread), you want infinitely variable syntax sugar via
> macros (at least, I hope, of the hygienic kind).
Of course, of the hygenic kind. I'm not a barbarian. But hygenic
*and* procedural. Not the annoying kind that they added to Scheme.
> Hmmm, you sure you wouldn't want some sort of explicit bracketing in
> lieu of indentation for grouping, or inheritance to be restricted to
> single rather than multiple, or...?-)
No, of course I wouldn't.
> Are you perchance at the same time an activist in the Republican
> Party striving to make the party support higher taxes, stricter
> Federal control on States, and more welfare including free
> health-care for all...?
I'd never have anything whatsoever to do with the Republican party.
> just like a non-type-safe, non-class-centered Eiffel
Eiffel isn't (compile-time) safe as it is.
> a non-pure, non-lazy Haskell,
Purely applicative languages are rarely applicative, so Haskell seals
its own fate. But that doesn't mean that something good, and somewhat
less pure won't rise from its ashes.
> or a Python with declarations and hygienic macros, would have no
> real reason to survive.
That's nonsense. It would be an even better langauge, with more
safety and more power, and more likely to be able to continue to
evolve to meet the needs of an ever-changing tomorrow.
> Such disintegrations due to "loss of core values" don't ALWAYS
> happen -- the old _name_ may happen to survive even as the deep
> nature of the language is totally changed, cfr. Fortran -- but they
> happen regularly enough to explain why somebody who particularly
> cares for a language's (or a party's) current core-values will react
> to the proposal of so-called "improvements" which are in fact rather
> obvious attacks against its core.].
See Guy Steele, "Growing a Language":
http://cm.bell-labs.com/cm/cs/who/wadler/gj/Documents/steele-oopsla98.pdf
"We need to put tools for language growth in the hands of the users"
> > Sure, macros are a long rope, but some tasks require a long rope.
> IF there are tasks that require a year-light worth of rope (a
> separate debate), it's still extremely silly to want to attach that
> thread to unsuitable frames.
> There are so MANY languages whose core values do *NOT* include
> simplicity and stylistic uniformity, that it's truly perverse to
> strive to destroy such uniformity and simplicity in one of its few
> "safe harbors".
Simplicity is maintained with a simple understandable model, and a
clean, elegant core, not by resistance to new features that would be
very useful. Stylistic uniformity sounds like some sort of communist
manifesto to me, and I want nothing to do with it. I prefer a
language that helps me implement my vision with style and panache.
Python does that just fine, thank you, and with a few improvements it
would do so even better.
> > Take a look at Guy Steele's maxim that a large language is impossible
> > to design well, but a small language is doomed to die. A language
> The obvious consequence if one believed that would be to design a
> mid-size language
No, his point is that *any* language, if it is to survive and be
widely used, will someday become a large language. Since a large
language cannot be designed up front, if you want the large language
that your small language will become to remain an elegant language, it
behooves you to plan well for the inevitable and unrelenting growth of
your language from a small one to a large one.
> -- isn't that what Steele tried to do in Java?
Guy Steele didn't design Java. His comments are aimed, I think, in
part, in implying in that Java must change if it is to survive. It
needs, for instance, parameterized types, operator overloading,
and lightweight objects.
> > needs to be able to grow over time. Procedural macros in Lisp allowed
> > Lisp to continue to evolve over time, so that even though it was
> > invented in the '50's, it remains today one of the most modern of
> > languages. It was able to do this, in part, by allowing every user to
> > experiment with adding language features, not just the language
> > Illuminati.
> So use Lisp! Who's holding you back? It IS an excellent language
> and has splendid implementations. Why do you want to make Python
> into Lisp?
And should I also move to New Zealand because I don't like the fact
that Amtrak sells information to the DEA? I don't respect the Not
Invented Here syndrome -- I see it time and time again in the
intransigence of people to take good ideas from other sources because
they didn't think of it themselves. Good ideas are good ideas, and it
behoves us to accept them where we find them.
There are plenty of reasons why I don't use Lisp for scripting, and if
you have used both of them, you would know *many* possible answers to
this question.
> Some of us believe Common Lisp is too complex.
Indeed it is. "The truth lies somewhere in the middle."
> Some of us think that hygienic macros make _Scheme_ too big too.
You would be wrong about that. But Scheme-style hygenic macros are
cumbersome and unpleasant to use for real-world problems. What one
really wants is procedural macros like Common Lisp, but that are also
hygenic.
> Even _Dylan_, for all of its beauty, and the true awesome power of
> multi-methods, is not what I use, in good part *BECAUSE* of the
> complication macros engender in my view.
I don't use Dylan because no one else uses it.
> You have not explained, I think, why _YOU_ would want to use Python
> rather than Common Lisp, Scheme, or Dylan.
There are numerous reasons. The fact that the others are not widely
used, are not tuned for scripting, do not have as elegant a syntax,
are not as easy to learn, are not available on every platform known to
man, do not start up in a fraction of a second, do not come with a
huge library of useful tools, etc., are all salient reasons. And yet
there remain others.
> They have hygienic macros AND variable declarations too. You say
> that's what you want -- OK, there they are.
Great. They also lack things that Python has. If I switched to them,
and wanted to bring the things I like about Python to them, no doubt
their Illuminati would tell me that I should go back to using Python.
Well, here I am.
> > And macros don't ensure that *any* given program is impossible to
> > understand -- it only helps nutty programmers make programs that are
> > impossible to understand. Conversely, macros can help wise
> > programmers in making programs that are shorter, easier to understand,
> > easier to code, and easier to maintain.
> Sure -- a perfect programmer (a very hypothetical beast) will use
> ANY given tool perfectly (by definition). All you say here applies
> just identically to the NON-hygienic macros of C, for example. They
> CAN in fact be used to good effect (cfr. the Python C API for some
> good, typical examples), and C would not be half as successful as it
> is if it didn't have its preprocessor or some other equivalent tool.
> _IN PRACTICE_, out in the field, you'll find C macro abuse rampant
> -- one of the most serious causes of maintenance nightmares.
C macros are a monstrosity, so it's no wonder that in the practice
there is rampant macro abuse. _IN PRACTICE_ there is not rampant
macro abuse in the Lisp world. Macros are typically used to good
effect and typically make programs easier to understand, rather than
harder. Often they are essential to making certain programs
maintainable. In another language, you would have to resort to
prepossessing or data driven code-generation instead.
> As you seem totally unwilling or unable to understand that
> Weltanschauung to any extent, I don't see how you could bring Python
> any constructive enhancement (except perhaps by some random
> mechanism akin to monkeys banging away on typewriters until 'Hamlet'
> comes out, I guess).
$#@# you too. You are very rude.
|>oug
Douglas Alan
> > Personally, I want a language that gives me all the rope I need,
> > but doesn't make it a chore to write good programs. Writing good
> > programs in Perl is a chore; hence Perl sucks.
> Perl gives you all the rope that you need. Writing good programs in
> Perl is not a chore. Maintaining good programs in Perl is a chore.
Good for *you*. *I* find everything to do with Perl a chore. Reading
the manual is a chore, writing programs in it is a chore, maintaining
programs in it is a chore, talking to fans of it is a chore. It is
utterly unpleasant from the ground up.
> Writing good programs in Python now isn't a chore. The more I
> program in Perl, the more I want to program in Python because of the
> fact that there are less ways to do something. By giving macros
> you'd be giving more ways to do something and lower the
> maintainability of the code.
How do you know? Have you ever programmed in a language with
procedural macros? I have. And I know from direct, first-hand
experience, that maintaining programs that judiciously use procedural
macros *increases* the maintainability of the code, not decreases it.
> The problem isn't that the language isn't flexible enough; it is
> plenty flexible for the aims it has. The problem is that the
> programmers aren't flexible enough in their laziness. It is
> something that I've had to overcome time and again in my Python
> programming because of my Perl background. As I've said, however, I
> prefer Python because I know that I'm quite likely to be able to
> maintain someone else's three year old code without having to puzzle
> over it for an hour and spend another three rewriting it to a
> maintainable form.
Yes, a good argument against Perl. Not a good argument against
procedural macros.
> > Regarding Perl, it is the worst attrocity foisted on humanity
> > since the black plague.
> Yet it provides exactly what you want, TIMTOWTDI.
No it doesn't. Perl is an attrocity. Please don't compare my desire
for procedural macros to a desire anything like Perl. Lisp has
procedural macros -- it is *nothing* like Perl.
> Yes, it does. It means that a person, beginner or expert, has to
> relearn a particular person's idioms before being able to do
> anything productive.
You speak using armchair logic and not from real-world experience.
This has never been a problem with Lisp code that I have worked on.
Good programmers are sane enough to not make their code particularly
idiomatic and bad programmers can always find a way to make their code
unbearable, even in Python.
> It means every time you come in contact with a new person's programs
> you have to relearn thier particular dialect of the language. That
> is not something that can be learned in a day.
In *theory* perhaps. In the real world, no.
> > That's because Perl is the worst attrocity foisted on humanity since
> > the black plague.
> Yet it offers exactly what you want. So why, then, do you want to turn
> Python into the worst attrocity foisted on humanity since the black plague?
You speak in non-sequitors. I don't want Python to be *anything* like
Perl. If anything, I want it to borrow some good ideas from Lisp.
Lisp is nothing like Perl. Lisp, like Python, is a wonderful
language, it it would behove both languages to learn lessons gleaned
by the other.
> > A language should be easy to learn, but offer untold power.
> Thus far I don't see many limits to Python's power because of its
> simplicity.
A language without procedural macros is clearly less expressive than
one that has them. This statement needs no support. For instance,
if I had procedural macros, I wouldn't need to bug the language
implementers to add variable declarations -- I could do it myself.
This would significantly reduce the amount of time I spend debugging
mistakes that should have been caught by the language. This should
make everyone happy.
> All I see are programmers who are whining that they can't have their
> favorite construct instead of learning a new way to do things.
I understand perfectly well the Python way of doing things. In my
case, the supposed Python way isn't always up to snuff. It has
nothing to do with not willing to learn something new -- it has to do
with me having years of experience knowing what I need to be as
productive as possible.
> Ironic in that to implement their pet prodecure they are requiring
> everyone /ELSE/ to learn something new.
Why is everyone here such a cynic? I hear claims that the Python
community is supposed to be filled with such nice people. You could
have fooled me. It seems to be filled with people that like to talk
down to others, patronize them, and trivialize their concerns.
> > If Python had procedural macros, the language wouldn't be any
> > harder to learn since this is not something a newbie would have to
> > worry about for quite some time.
> But is something that every expert would have to relearn each time they
> tuch someone else's code.
Everytime you read someone else's code you have to understand the
functions they've defined before you can understand their code. Let's
get rid of functions too!
> > A bad programmer has many tools available to him in Python, as it
> > is, to make hard to understand code. I don't think it would go
> > over well to remove useful features from the language to prevent
> > this.
> This, of course, is also not an argument to add features which serve very
> little purpose and add untold complexity.
If you think that procedural macros "serve very little purpose and add
untold complexity", then you are profoundly ignorant on the history of
just how useful they have been in the programming languages that have them.
> You said you programmed quite happily in Lisp for over a year
> without macros. I contend that if the macros weren't there you
> could have still programmed just as happily.
Actually, you are quite wrong. I got to a point where I needed
certain features (like object-orientation and exceptions) that weren't
in the language, and I needed to implement them in order to accomplish
my task.
|>oug
Neelakantan Krishnaswami
>
> Yes, 'hygienic macros' WOULD help cut these discussions short. Pity
> this benefit (basically restricted to c.l.p) would be balanced by
> the productivity loss engendered by the actual existence of such
> macros in the language -- a language which may have ANY 'syntactic
> feature' ensures any given program is impossible to understand
> unless you first study the exact set of macros used by its
> author:-).
I note that precisely the same argument can be made about adding
functions to a language.
Neel
Courageous
>> But is something that every expert would have to relearn each time they
>> tuch someone else's code.
>
>Everytime you read someone else's code you have to understand the
>functions they've defined before you can understand their code. Let's
>get rid of functions too!
This remark is quite apropros: as a professional lisp programmer (not
necessarily by preference, but so it goes), I find maintaining code with
the occasional hygienic macro to be no more difficult than understanding
someone else's functions. I believe this is a very apt analogy.
Now one thing that I would say is that, if hygienic macros were present
in Python, the primary Python distributions themselves should not add
additional looping construct macros or other language-altering macros
as part of any particular release. The addition of a "standard core of
language transmogrifying macros" (ala the proliferation of a dozen or
so looping constructs in Lisp) would probably create the very problem
that the other poster is referring to.
C//
Andrew Dalke
> Someone in this thread mentioned that they needed to go back
> to k&h to recall it and I can't quite understand why (even though
> you might say that recollection and simplicity are mutually
> exclusive).
That was me. I use that construct in C so infrequently that it
merges with my memories of the same construct in other languages
so I forget if it's
do { .. } while();
do { .. } until();
repeat { .. } while();
or
repeat { .. } until();
The name of this thread shows the problem. Why is it
named "do...until" instead of "do...while" ?
Andrew
da...@acm.org
Steve Lamb
>Good for *you*. *I* find everything to do with Perl a chore. Reading
>the manual is a chore, writing programs in it is a chore, maintaining
>programs in it is a chore, talking to fans of it is a chore. It is
>utterly unpleasant from the ground up.
I dunno, I find most of what I write in it quite easy compared to Python
at the moment. Of course, this are the simple cases where while(<>){}, or
while(<FOO>){} is far easier than the comparable Python loops. OTOH, I would
not trade in the Python loops since it, too, has its advantages. Mainly if
not meaning if not and only if not meaning if not.
>How do you know? Have you ever programmed in a language with
>procedural macros? I have. And I know from direct, first-hand
>experience, that maintaining programs that judiciously use procedural
>macros *increases* the maintainability of the code, not decreases it.
Just as maintaining programs that are judiciously programmed in Perl
increases the maintainability of the code. Just as maintaining programs that
are judiciously programmed in Python increases the maintainability of the
code. The operative word is judicious, not procedural macros.
>Yes, a good argument against Perl. Not a good argument against
>procedural macros.
Incorrect, it is a good argument against both.
>No it doesn't. Perl is an attrocity. Please don't compare my desire
>for procedural macros to a desire anything like Perl. Lisp has
>procedural macros -- it is *nothing* like Perl.
I call it like it is. You want a way to do the same thing multiple ways
that causes a maintenance nightmare for anyone else who has to even look at
your code. Perl has that, hence you are aspiring to Perl, which you dispise.
Kinda like that whole homophobes are closet gays. You're a closet Perl
zealot.
>You speak using armchair logic and not from real-world experience.
I speak using real-world experience.
>This has never been a problem with Lisp code that I have worked on.
>Good programmers are sane enough to not make their code particularly
>idiomatic and bad programmers can always find a way to make their code
>unbearable, even in Python.
Yes, and? This has no bearing on the fact that providing multiple ways to
do things makes a language complex out of perportion of the benefits provided.
>> It means every time you come in contact with a new person's programs
>> you have to relearn thier particular dialect of the language. That
>> is not something that can be learned in a day.
>In *theory* perhaps. In the real world, no.
Hint, you're the one with the theory. Here's the real world; touch
someone else's code where they can modify semantics and you have to learn
their dialect.
>> > That's because Perl is the worst attrocity foisted on humanity since
>> > the black plague.
>> Yet it offers exactly what you want. So why, then, do you want to turn
>> Python into the worst attrocity foisted on humanity since the black plague?
>You speak in non-sequitors. I don't want Python to be *anything* like
>Perl.
Yes, you do. You want to be able to provide multiple ways to do the same
thing.
>A language without procedural macros is clearly less expressive than
>one that has them.
A language without procedural macros is clearly easier to maintain. To
me, that is power.
>This statement needs no support.
Wow. Really? This statement needs no support either: *plonk*.
>For instance, if I had procedural macros, I wouldn't need to bug the language
>implementers to add variable declarations -- I could do it myself. This
>would significantly reduce the amount of time I spend debugging mistakes that
>should have been caught by the language. This should make everyone happy.
Except for those who have to touch your code and then wonder why the
language doesn't work like they learned it. They then need to learn your
particular dialect of the language. Try to 'no support' your way out of that.
>> All I see are programmers who are whining that they can't have their
>> favorite construct instead of learning a new way to do things.
>I understand perfectly well the Python way of doing things. In my
>case, the supposed Python way isn't always up to snuff. It has
>nothing to do with not willing to learn something new -- it has to do
>with me having years of experience knowing what I need to be as
>productive as possible.
>> All I see are programmers who are whining that they can't have their
>> favorite construct instead of learning a new way to do things.
Am I prophetic, or what?
>> Ironic in that to implement their pet prodecure they are requiring
>> everyone /ELSE/ to learn something new.
>Why is everyone here such a cynic? I hear claims that the Python
>community is supposed to be filled with such nice people. You could
>have fooled me. It seems to be filled with people that like to talk
>down to others, patronize them, and trivialize their concerns.
Prime example, |>ouglas "1 sp3@k d00d" Alan. Take a look at your comments
on Perl sometime.
>> But is something that every expert would have to relearn each time they
>> tuch someone else's code.
>Everytime you read someone else's code you have to understand the
>functions they've defined before you can understand their code. Let's
>get rid of functions too!
That is a part of the language. Redefining the very semantics and syntax
of the language means it is a new dialect. If the big words are hard for you
to understand visit <http://www.m-w.com>.
Steve Lamb
wrote:
>I note that precisely the same argument can be made about adding
>functions to a language.
Not so. Adding a fuction to the language means it is part of the language
that all would know. A function is added, I can go to www.python.org and look
it up. In fact I have done so when my Beazley book, written for 1.5.2, failed
me when I was working on Python 2.0.
However, the macros provide for undocumented contructs, undocumented
dialects. One would then need to first learn those macros, those dialects,
before even reading the code. Note that this is different than having to read
the functions that the person has written. Why? Functions are written in the
language, the macros /alter/ the language.
To take it to an analogy of natural languages (which is I say 'dialect' so
often) take American "standard" English, British "standard" English and a sub
dialect of each of those languages (Ebonics and Cockney?).
They all come from the same roots. Use those most common roots and
chances are high everyone will understand. Words (keywords) are used to form
sentences (statements). From those sentences come paragraphs
(functions/methods). From paragraphs come chapters (libraries/classes). From
the chapters come a book (program). Even though each book (program) is
written from a set of chapters (libraries/classes) made of up paragraphs
(functions/methods) composed of sentences (statements) that must be read to
understand where the narrative is going (program is doing) one can read it
quite efficiently.
However, change the dialect (macros), alter what the words (keywords) mean
and now it becomes a chore to even read the sentences (statements). One must
then first study the dialect (macros) before being able to do more than muttle
through the sentences (statements) puzzling over each seemingly familiar word
which may or may not have the same definition as the one you've previously
learned.
To me it is clear that there is a world of difference between reading a
new book (reading new code) in a language and dialect you are fluent in than
reading a new book in a dilect which is similar to but suffciently different
to the one you're accustomed to (code with macros). Now imagine the variety
of dialects in the common national languages and imagine if each person could
redefine any given word in any manner they chose. Right now we only have
regional differences and that is tough enough. But a programmer with a macro
system on top of a programming language isn't really limited to regional
differences, is he? As long as the code works, FOR HIM, then it works.
So, again, I find it laughable that adding the complexity of having to
relearn the language for each programmer's whimsy is somehow lauded as an
exercise in simplicity and efficiency. More so when it is proven that
maintainability in such an open and free environment (Perl, in spite of what
Douglas Alan says) is hard to obtain.
No, give me one dialect. It may have limitations, to be sure, but the
massive increase in maintainability far outweigh any limitations there are.
Douglas Alan
> >How do you know? Have you ever programmed in a language with
> >procedural macros? I have. And I know from direct, first-hand
> >experience, that maintaining programs that judiciously use procedural
> >macros *increases* the maintainability of the code, not decreases it.
> Just as maintaining programs that are judiciously programmed in Perl
> increases the maintainability of the code. Just as maintaining programs that
> are judiciously programmed in Python increases the maintainability of the
> code. The operative word is judicious, not procedural macros.
I can't make "judicious use of procedural macros" if I don't *have*
procedural macros. Thus, without procedural macros, some avenues
opened up to me for making my code more readable are lost.
You seem to be claiming that "judicious use of procedural macros"
could not *possibly* make my code more readable. If that is what you
are claiming, I have much real world experience that says you are wrong.
> >Yes, a good argument against Perl. Not a good argument against
> >procedural macros.
> Incorrect, it is a good argument against both.
You are wrong for two reasons: (1) My problems with Perl run far, far
deeper than that it gives you too many ways to do the same thing. (2)
Yes, procedural macros *can* be used by the novice to just give you
yet another way to do something that you can do easily enough using a
built-in, but that is not where their strengths lie. Their strength
lie in allowing the user to make a wholesale extension to the language
that greatly simplifies a complex task. Can this be misused? Most
definitely. Have they proven themselves to also allow incredible
gains? Absolutely.
For instance, procedural macros allowed Lisp to turn itself from a
procedural language to an OO language without changing the language at
all. A very capable OO extention (one that supported multimethods and
a meta-object protocol) could be added to the language using only
macros. The language was able to *grow* without any centralized
control.
> >No it doesn't. Perl is an attrocity. Please don't compare my desire
> >for procedural macros to a desire anything like Perl. Lisp has
> >procedural macros -- it is *nothing* like Perl.
> I call it like it is. You want a way to do the same thing multiple ways
> that causes a maintenance nightmare for anyone else who has to even look at
> your code.
I don't want to be able to so the same thing multiple ways. I want to
be able to add extensions to the language, and to be able to reduce
redundant code by being able to parameterize such code using macros.
> Perl has that, hence you are aspiring to Perl, which you dispise.
> Kinda like that whole homophobes are closet gays. You're a closet
> Perl zealot.
You get nowhere with such reasoning, except to make me think that you
are ignorant about procedural macros and wish to remain that way.
> > You speak using armchair logic and not from real-world experience.
> I speak using real-world experience.
You do? Have you ever programmed in Lisp using procedural macros?
> > This has never been a problem with Lisp code that I have worked
> > on. Good programmers are sane enough to not make their code
> > particularly idiomatic and bad programmers can always find a way
> > to make their code unbearable, even in Python.
> Yes, and? This has no bearing on the fact that providing
> multiple ways to do things makes a language complex out of
> perportion of the benefits provided.
This is a straw man. The "benefit" you mention is not the benefit I
care about.
> >> It means every time you come in contact with a new person's programs
> >> you have to relearn thier particular dialect of the language. That
> >> is not something that can be learned in a day.
> >In *theory* perhaps. In the real world, no.
> Hint, you're the one with the theory. Here's the real world; touch
> someone else's code where they can modify semantics and you have to learn
> their dialect.
I'm not speaking from theory -- I am speaking from direct experience.
I have used Lisp extensively and I *know* what benefits and pitfals
procedure macros entail.
By the way, procedural macros do not "modify semantics" -- they only
allow the programmer to define new syntactic forms. They don't change
the meaning of the syntactic forms that are already there.
> > You speak in non-sequitors. I don't want Python to be *anything*
> > like Perl.
> Yes, you do. You want to be able to provide multiple ways to do the
> same thing.
Straw man.
> > A language without procedural macros is clearly less expressive
> > than one that has them.
> A language without procedural macros is clearly easier to maintain. To
> me, that is power.
Untrue. As I said before, I speak from direct experience that
procedural macros typically make programs easier to maintain, not more
difficult.
> > For instance, if I had procedural macros, I wouldn't need to bug
> > the language implementers to add variable declarations -- I could
> > do it myself. This would significantly reduce the amount of time
> > I spend debugging mistakes that should have been caught by the
> > language. This should make everyone happy.
> Except for those who have to touch your code and then wonder why the
> language doesn't work like they learned it.
The language will still work exactly the way that they learned it. It
will just be the case that there will be a new syntactic form. The
new syntactic form will be no more difficult to understand than if I
defined a new function and used it.
> They then need to learn your particular dialect of the language.
By your definition, they need to learn a "new dialect" every time I
define a new function.
> >Why is everyone here such a cynic? I hear claims that the Python
> >community is supposed to be filled with such nice people. You could
> >have fooled me. It seems to be filled with people that like to talk
> >down to others, patronize them, and trivialize their concerns.
> Prime example, |>ouglas "1 sp3@k d00d" Alan. Take a look at your comments
> on Perl sometime.
If you want to use Perl go ahead. I just want *nothing* to do with
Perl, okay? I don't talk down to people who ask me *Python*
questions, or *Lisp* questions, or *C++* questions, or *Java*
questions, if the questioner does so with even the slightest amount of
respect in their tone.
> > Everytime you read someone else's code you have to understand the
> > functions they've defined before you can understand their code.
> > Let's get rid of functions too!
> That is a part of the language.
So? It still allows programmers to define new terms that you have to
do some work to understand. If procedural macros were added to the
language, then they'd be part of the language too, would they not?
> Redefining the very semantics and syntax of the language means it is
> a new dialect.
Procedural macros don't allow you to "redefine the very semantics and
syntax of the language". They only allow you to add new terms to the
language, just as defining functions and objects allows you to add new
terms. The type of term you can add to Python with a function is
somewhat limited compared to what you could add with procedural
macros. Sometimes a more powerful term-adding capability is
incredibly useful and allows you to make programs that are more
elegant and easier to maintain.
> If the big words are hard for you to understand visit
> <http://www.m-w.com>.
%#@% you too.
|>oug
Douglas Alan
> So, again, I find it laughable that adding the complexity of having to
> relearn the language for each programmer's whimsy is somehow lauded as an
> exercise in simplicity and efficiency. More so when it is proven that
> maintainability in such an open and free environment (Perl, in spite of what
> Douglas Alan says) is hard to obtain.
Go program in Lisp for a couple of years and then come back and make
these claims. In the meantime, you just come across as someone who is
profoundly ignorant, is satisfied with remaining profoundly ignorant,
and doesn't mind spouting off about things about which he is
profoundly ignorant.
|>oug
Andrew Henshaw
"Sheila King" <she...@spamcop.net> wrote in message
> But, as already mentioned in this thread, the word "do" doesn't
necessarily
> imply looping.
>
> Wouldn't this be even more preferable?
>
> loop:
> some code
> if condition:
> break
>
Yes it would. Or maybe 'repeat'.
Andrew Dalke
> Everytime you read someone else's code you have to understand the
> functions they've defined before you can understand their code.
> Let's get rid of functions too!
Ohh! Ohh! I've got a quote about that!
> "The truth lies somewhere in the middle."
:)
Trust me, if I could get rid of functions I would. It's getting
to the point where I'm starting to get tired of learning
yet-another-library. The only thing that makes that decent in
Python is that the structure of those programs can't be as, ahem,
wildly creative as I've seen in other code and the core set
of data structures Python provides are good enough that the
different libraries each don't decide to rewrite a list, or
string, or hash table implementation.
Even then, there's times where I give up and rewrite the code
myself because I can't figure out what's going on. I shudder
at giving still more flexibility in how to write those functions.
Andrew
da...@acm.org
Andrew Dalke
>> "There should be ONE 'obviously correct' way to do it" is one of the
>> Python mantras
Douglas Alan responded:
>This is a BAD mantra. Not as bad as the Perl mantra, "There should be
>3294369 ways to do it", but extremes are rarely ideal. "The truth lies
>somewhere in the middle."
Huh? His mantra isn't an extreme. "There must be only one way
to do it" is an extreme. That is, pure orthogonality is an extreme.
Saying there "should be one 'obviously correct' way" means there
could be other obviously correct ways as well as non-obvious ways,
but those designs aren't Pythonic.
>Besides, there are many uses for procedural macros other than for
>providing trivial syntactic sugars that are best done by using the
>sugar already provided.
You all are going to have to explain things to me. My physics
degree never told me what "procedural macros", "hygenic macros",
etc. mean. My best guess is they are transformations which act
on parse trees before finalizing the parsing, vaguely like what
templates do for C++ (which my physics degree did tell me about).
If that's the case then I can see how they would be useful,
because one nice thing about templates is to allow A = B + n * C
to be implemented element-wise for matricies without producing
intermediates.
But every time I look to see how templates work I sigh in
relief that someone else has done the hard work. C++ aside,
could you present an example of how these might be used in
Python? I'm finding it hard to conceive of significantly
better ways to write code than what Python has already. (I
don't see list comprehensions or string method as all that
significant.)
By example I mean how it might look written in Python, not
how it is done in Lisp, Scheme, Dylan or other language not
used by computational physicists/chemists/biologists.
Mind you also that justifications based on performance (as
with my element-wise addition) don't have much weight with
me. For that I rewrite in C. My main, number one concern
is to have a programming language where both software
developers and life scientists (medicinal chemists,
biophysicists, structual biologists, etc.) can use it and
enjoy using it. I would need to be convinced that someone
whose programming training is a semester of FORTRAN and
a couple of years of shell scripting can learn how 90% of
the features in a language works without having to get any
special training beyond help from coworkers and books.
>See Guy Steele, "Growing a Language":
>
>
http://cm.bell-labs.com/cm/cs/who/wadler/gj/Documents/steele-oopsla98.pdf
>
>"We need to put tools for language growth in the hands of the users"
That tools is the C (or Java) implementation, no? Otherwise growth
into forms like Stackless and Alice never would have taken place.
I use Python because I don't think one language provides everything.
So really I don't use Python, I use Python and C/C++ .. and
http and popen and .... So CPython does provide the tools I
(as a user) need to help the language grow. And I've done so
by contributing code back to Python.
>> You have not explained, I think, why _YOU_ would want to use Python
>> rather than Common Lisp, Scheme, or Dylan.
>
>There are numerous reasons. The fact that the others are not widely
>used, are not tuned for scripting, do not have as elegant a syntax,
>are not as easy to learn, are not available on every platform known to
>man, do not start up in a fraction of a second, do not come with a
>huge library of useful tools, etc., are all salient reasons. And yet
>there remain others.
How does this jibe with your statement that Lisp
"even though it was invented in the '50's, ... remains
today one of the most modern of languages."
Does this mean with 40+ years of development, Lisp does not have
features of some modern language, in that it isn't widely
used, not tuned, etc.? Those two statements don't go together,
unless you split "language" features of a language from "lets you
do work" features of an implementation. As mentioned, I'm
heavily weighted towards the latter. I feel it is the job
of language designers to convince me the former really is
useful and my job to evaluate if they've done a good job.
Python passes that test.
>Macros are typically used to good
>effect and typically make programs easier to understand, rather than
>harder. Often they are essential to making certain programs
>maintainable. In another language, you would have to resort to
>prepossessing or data driven code-generation instead.
So if my job is to evaluate if a language designer has done
a good job, I would need to see an example relevant to how
Python works. Could you show how this might be used in a
Python-like deriviative? Cases I can think of from my C
background can all be done with things like:
if cond:
def spam():
pass
else:
def spam():
pass
or
def make_spam(data):
def spam(n = len(data)):
return n
return spam
or
klass = new.classobj("Spam", (), {})
or (*very* rarely)
d = {}
exec "def Spam():\n\tpass\n" in d
func = d["Spam"]
In another branch of this thread you said:
> A language without procedural macros is clearly less expressive than
> one that has them. This statement needs no support.
I don't necessarily want that expressiveness. I can write (and
have written) Python code which takes a C function definition,
builds it as a Python extension and imports it into Python. That
is clearly more expressive than stock Python but it isn't something
I want available because it scares me having to think that every
module I use can have a mix of C and Python code.
So what needs support is not the expressiveness itself but the
usefulness of the expressiveness.
> For instance,
> if I had procedural macros, I wouldn't need to bug the language
> implementers to add variable declarations -- I could do it myself.
In my limited understanding of hygenic macros, wouldn't you only
be able to apply macros to a sufficiently Python-like language,
in order to transform it internally to a Python representation?
That is, you couldn't use hygenic macros to convert Pascal
code into Python. (Is that what the 'hygenic' part means?)
Suppose your user tests show that the best way to add variable
declarations to Python is via a language syntax the current
implementation doesn't have, so cannot be handled through macros.
What would you do then?
Andrew
da...@acm.org
Erik Max Francis
> In article <slrn9dooe...@teleute.dmiyu.org>,
> Steve Lamb <morp...@here.not.there> wrote:
>
> > Yess, that was an attempt at Godwin. No offense, Alex. :)
>
> One of the corollaries to Godwin is that deliberately invoking Godwin
> doesn't count.
Except that Godwin's law is just a statistical observation. It's the
_convention_ that people often use that talks about threads ending;
Godwin's law proper says nothing at all about that.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ I want to know God's thought; the rest are details.
\__/ Albert Einstein
Physics reference / http://www.alcyone.com/max/reference/physics/
A physics reference.
Andrew Dalke
>For instance, procedural macros allowed Lisp to turn itself from a
>procedural language to an OO language without changing the language at
>all. A very capable OO extention (one that supported multimethods and
>a meta-object protocol) could be added to the language using only
>macros. The language was able to *grow* without any centralized
>control.
Here's me asking for clarification on the meaning of "procedural
macros" again. Would Tcl be considered a language based almost
entirely on procedural macros? It let you introduce your own
loop constructs, classes, exception framework, etc.
Quoting Steve Lamb:
>> Redefining the very semantics and syntax of the language means it is
>> a new dialect.
>
>Procedural macros don't allow you to "redefine the very semantics and
>syntax of the language". They only allow you to add new terms to the
>language, just as defining functions and objects allows you to add new
>terms.
At one of my clients there are at least three different vocabularies
for essentially the same thing - the words used in the literatur,
the words used by the chemists and the words used by the
implementation of the chemists viewpoint on a computer.
The software suffers as a consequence because aliases for the same
ideas are used through the system and docs, and there isn't a
precise idea of when one word should be used over another.
I've always been concerned about languages which allow you to
define new terms to the language because it would just exacerbate
the language problems people already have.
> The type of term you can add to Python with a function is
>somewhat limited compared to what you could add with procedural
>macros. Sometimes a more powerful term-adding capability is
>incredibly useful and allows you to make programs that are more
>elegant and easier to maintain.
Perhaps, but my feeling is that the level of training you need
for that is greater than most of my clients - chemists and
biologists - want to go through. Note that since I've never
used a language (other than Tcl?) with these sorts of macros
I don't have specific knowledge of the pros and cons.
I can say that in Tcl I rarely saw researchers without a very
strong background in CS (degree level) defining their own
new language constructs. Also, the lack of a *standard* way
to do objects (this is back in the 7.x days) meant that no
one used them - no one rolled their own OO system.
I can also point out the almost complete nonexistence of a
major package in computational chemistry or biology written
in a language supporting hygenic/procedural macros as an
indicator that *something* prevents their wider use in my
field.
Andrew
da...@acm.org
Steve Holden
> "Alex Martelli" <ale...@yahoo.com> writes:
[ ... ]
> > As you seem totally unwilling or unable to understand that
> > Weltanschauung to any extent, I don't see how you could bring Python
> > any constructive enhancement (except perhaps by some random
> > mechanism akin to monkeys banging away on typewriters until 'Hamlet'
> > comes out, I guess).
>
> $#@# you too. You are very rude.
>
post in this vein in future.
this-newsgroup-has-a-happy-flavor-because-we-work-at-it-ly y'rs - steve
Tim Peters
> ...
> Of course, of the hygenic kind. I'm not a barbarian. But hygenic
> *and* procedural. Not the annoying kind that they added to Scheme.
Write a PEP! Spell out what it would look like, how it would work, and give
cool examples. This meta-discussion is going nowhere -- except, of course,
down the toilet.
In the very early days Guido tried to dream up "a Pythonic way" to allow
user-definable constructs, but reported he discovered he had more pressing
things to get done. So if you have a concrete idea in mind, I don't think
it's necessarily a non-starter. Well, it is a non-starter if the string
"macro" appears in what you *call* it <0.23 wink>.
Douglas Alan
> "Douglas Alan" <nes...@mit.edu> wrote in message
> > "Alex Martelli" <ale...@yahoo.com> writes:
> > > As you seem totally unwilling or unable to understand that
> > > Weltanschauung to any extent, I don't see how you could bring Python
> > > any constructive enhancement (except perhaps by some random
> > > mechanism akin to monkeys banging away on typewriters until 'Hamlet'
> > > comes out, I guess).
> > $#@# you too. You are very rude.
> Rude, perhaps, but not usually abusive. *Please* resist the temptation to
> post in this vein in future.
I find the quote from Alex above to be utterly abusive, and he was
abusive to me in a previous post. Calling him rude is what he
deserves, because it is what he is.
|>oug
Paul Prescod
>
> ...
>
> You all are going to have to explain things to me. My physics
> degree never told me what "procedural macros", "hygenic macros",
> etc. mean. ...
>
> If that's the case then I can see how they would be useful,
> because one nice thing about templates is to allow A = B + n * C
> to be implemented element-wise for matricies without producing
> intermediates.
>
> ...I'm finding it hard to conceive of significantly
> better ways to write code than what Python has already. (I
> don't see list comprehensions or string method as all that
> significant.)
I think you've captured the gist of it...hygenic macros are mostly
useful for very specific domains. You can imagine macros that allow
Python code to look like SQL or XPath or Prolog or ...
--
Take a recipe. Leave a recipe.
Python Cookbook! http://www.ActiveState.com/pythoncookbook
Tim Peters
> If Python is supposed to provide one obviously correct way of
> doing things why did they create the lambda notation?
[Alex Martelli]
> Historically, I believe, because some user way back
> when supplied patches for that and map/reduce/filter,
> and the normally very sensitive screens of our BDFL
> didn't trigger.
> ...
> Surely SOME old-timer who HAS been around throughout
> can give more solid info on this historical-interest-
> only item...?
Rest assured you've wrung all the blood there is to be squeezed out of this
particular rock. From Misc/HISTORY:
Lambda expressions are particularly useful in combination
with map(), filter() and reduce(), described below. Thanks
to Amrit Prem for submitting this code (as well as map(),
filter(), reduce() and xrange())!
under the notes for Release 1.0.0 (26 January 1994).
Python evolution was more, umm, surprising then. I distinctly recall being
greatly surprised by the addition of lambda & friends -- they hadn't been
mentioned on the Python mailing list (this was pre-c.l.py, of course), so the
1.0.0 release notes were the first most of us heard of them. In the years
since, Guido switched from calling them "minor conveniences" to "minor
annoyances". I still think he's half right about that <wink>.
Steve Lamb
On 17 Apr 2001 20:36:59 -0400, Douglas Alan <nes...@mit.edu> wrote:
>I can't make "judicious use of procedural macros" if I don't *have*
>procedural macros. Thus, without procedural macros, some avenues
>opened up to me for making my code more readable are lost.
As are LOTS of avenues for making your code unreadable.
>You seem to be claiming that "judicious use of procedural macros"
>could not *possibly* make my code more readable. If that is what you
>are claiming, I have much real world experience that says you are wrong.
No, I am claiming that the judicious use of anything programming related
seems to be inversely perportional to multitude of ways one can complete the
task.
Put another way, programmers, like drivers, like to think they are above
average. Experience, not to mention mathematics, show that programmers, just
like drivers, aren't all above average. Food for though, |>0L|G?
>> >Yes, a good argument against Perl. Not a good argument against
>> >procedural macros.
>> Incorrect, it is a good argument against both.
>You are wrong for two reasons: (1) My problems with Perl run far, far
>deeper than that it gives you too many ways to do the same thing.
And? This doesn't discount that macros are a large... well, several large
leaps in that direction.
>(2) Yes, procedural macros *can* be used by the novice to just give you
>yet another way to do something that you can do easily enough using a
>built-in, but that is not where their strengths lie. Their strength
>lie in allowing the user to make a wholesale extension to the language
>that greatly simplifies a complex task. Can this be misused? Most
>definitely. Have they proven themselves to also allow incredible
>gains? Absolutely.
I'll have to keep that in mind. "Make a wholesale extension to the
language."
>For instance, procedural macros allowed Lisp to turn itself from a
>procedural language to an OO language without changing the language at
>all. A very capable OO extention (one that supported multimethods and
>a meta-object protocol) could be added to the language using only
>macros. The language was able to *grow* without any centralized
>control.
Hmmm-mmmm, what was that I was mentioning about dialects?
>I don't want to be able to so the same thing multiple ways. I want to
>be able to add extensions to the language, and to be able to reduce
>redundant code by being able to parameterize such code using macros.
IE, make your own dialect.
>> Perl has that, hence you are aspiring to Perl, which you dispise.
>> Kinda like that whole homophobes are closet gays. You're a closet
>> Perl zealot.
>You get nowhere with such reasoning, except to make me think that you
>are ignorant about procedural macros and wish to remain that way.
And you're proving to me that you're the very zealot I mentioned who is
more interested in whining about not having his favorite constructs than
working with what is presented. I still think you're a closet Perl Zealot,
too.
>> > You speak using armchair logic and not from real-world experience.
>> I speak using real-world experience.
>You do? Have you ever programmed in Lisp using procedural macros?
I speak of having to maintain an extremely large codebase of TIMTOWTDI
code and shudder at the thought of having to deal with the "wholesale
extension to the language" to the extend of taking a procedural and turning it
into OO at the whimes of the dozens of programmers who have worked on this
code base. I have enough trouble as it /is/ without the language itself being
(more of) a moving target!
>This is a straw man. The "benefit" you mention is not the benefit I
>care about.
Whoop-di-do, it is a benefit mention in conjuction with what you are
advocating. It /IS/ something that is going to happen so you had best be
ready to defend it.
>I'm not speaking from theory -- I am speaking from direct experience.
>I have used Lisp extensively and I *know* what benefits and pitfals
>procedure macros entail.
Clearly not.
>> > You speak in non-sequitors. I don't want Python to be *anything*
>> > like Perl.
>> Yes, you do. You want to be able to provide multiple ways to do the
>> same thing.
>Straw man.
Deal with it.
>> > A language without procedural macros is clearly less expressive
>> > than one that has them.
>> A language without procedural macros is clearly easier to maintain. To
>> me, that is power.
>Untrue. As I said before, I speak from direct experience that
>procedural macros typically make programs easier to maintain, not more
>difficult.
Pardon me if I don't take your word on it.
>> Except for those who have to touch your code and then wonder why the
>> language doesn't work like they learned it.
>The language will still work exactly the way that they learned it. It
>will just be the case that there will be a new syntactic form. The
>new syntactic form will be no more difficult to understand than if I
>defined a new function and used it.
Whoops, let's think about this. "Wholesale extension to the language" and
turning a procedural language into something similar to OO. Those do not jive
with "The language will still work exactly the way they have learned it."
Sorry, I do not believe you when you are touting a pseudo-OO from a non-OO
language as "exactly the same". If it operated "exactly the same" then you
wouldn't have a NEED for the macros since, well, it isn't modifying anything
is it. If it were, then it wouldn't be EXACTLY the same!
>> They then need to learn your particular dialect of the language.
>By your definition, they need to learn a "new dialect" every time I
>define a new function.
No, they do not. Since the functions are written in the language and are
a part of the language they don't need to learn anything new to understand the
language. They only need to reed the narrative that is there. A new
dialect... Wait, let's pause for a minute. Clearly you are having trouble
with the big words and didn't take my advice. From m-w.com...
a regional variety of language distinguished by features of vocabulary,
grammar, and pronunciation from other regional varieties and constituting
together with them a single language
Distinguised by features of vocabulary, grammer and pronunciation. I
chose that word because with macros you are changing how the language reacts
and acts. Unlike with just defining a new function which is using existing
behaviors, IE, "vocabulary, grammer and pronunciation", to get the end result.
That is why in one dialect of English "Put that fag out!" means to
extinguish a cigarette and in another it might mean to remove a gay individual
from a building or to knock them out with physical violence. Just as in
natural languages where different DIALECTS alter the meaning and understanding
of the individual sentences macros would do the same for computer languages.
Functions do not because they use the existing langauge to create new things,
not alter the language to create new things. READ THAT SENTENCE AGAIN, USE
THE WEB SITE FOR THE BIG WORDS.
There is a difference there and if you're too dense to figure it out, your
own tough luck. You're the one trying to sell the notion that macros which
can effect a "wholesale extenstion to the language" and even alter the
behavior of the base language (Lisp procedural to pseudo-OO) is even on the
same remote scale as a common function definition!
>If you want to use Perl go ahead.
I'd much rather not to. However, it pays the bills.
>I just want *nothing* to do with Perl, okay? I don't talk down to people who
>ask me *Python* questions, or *Lisp* questions, or *C++* questions, or *Java*
>questions, if the questioner does so with even the slightest amount of
>respect in their tone.
But you talk down to people who ask Perl questions, clearly. I don't talk
down to anyone asking honest questions. Only to yahoos (that's a technical
term for |>00|> |>oUgsL3R, btw) who is saying one thing out of the left side
of his mouth (The language acts the same!!!) and something entirely different
out the other (The language has evolved, wholesale extensions, morphing from
one style of programming to another). Sorry, Doug, one or the other, can't
have both so stop trying.
>So? It still allows programmers to define new terms that you have to
>do some work to understand.
Written in the language we know, not redefining the language. There is a
difference.
Try this since you're so dense on the difference. Ever wonder why
Legalese, while nominally English (well, in this country) is so hard for the
layman to read now? 1/2 the reason is because they like to redefine a word
for the scope of the document.
Taking existing words and putting them together in new ways = same
language = functions.
Taking existing words, redefining them for only a short timeframe =
different DIALECT = macros.
>If procedural macros were added to the language, then they'd be part of the
>language too, would they not?
No, see above.
>Procedural macros don't allow you to "redefine the very semantics and
>syntax of the language".
Not according to "Wholesale extenstion to the language"
OO-outta-procedural Douglas Alan. Maybe you've heard of, oh wait, you're him.
Read the top of this message to see the appropriate quotes. I'd call making
OO out of non-OO redefining the very semantics and syntax of the language.
Call me crazy, but C and C++, by most people, are considered two different
languages with the mane difference being... Well, one is functional, the
other OO. Wacky that, eh?
>They only allow you to add new terms to the language, just as defining
>functions and objects allows you to add new terms.
If that is all they did then why do we need them if we have that now with
fuctions. Clearly that isn't all they do. Call me crazy but maybe that
Douglas Alan guy, er, you, nailed it with "wholesale extensions to the
language". Call me crazy but I don't consider programs written in the
language as wholesale extensions to the language. I call them, well, programs
written *IN* the language as opposed to *ALTERING* the language. And please,
no more BS about "it doesn't alter the language" ok? "Wholesale extension of
the language" and making OO out of non-OO is altering the language, period.
>The type of term you can add to Python with a function is somewhat limited
>compared to what you could add with procedural macros. Sometimes a more
>powerful term-adding capability is incredibly useful and allows you to make
>programs that are more elegant and easier to maintain.
More elegant and easier to maintain... ...to the original author since he
is the one who wrote the dialect in the first place. For everyone else, it is
a major pain in the rear since they now have to /LEARN/ the "wholesale
extension to the language". You, uh, forgot that part, didn't you. You are
aware other people are going to have to maintain your code. And remember, in
spite of what you may think, there is a 50/50 chance you're a below average
programmer.
>> If the big words are hard for you to understand visit
>> <http://www.m-w.com>.
>%#@% you too.
To me it is deserved. You know why? I'm a out-and-out prick. I don't
suffer liars lightly and anyone, I do mean ANYONE who is trying to sell the
tripe your selling of altering a language without ever altering the language
is either trolling, smoking crack, or lying. So %#@% (Hash, comment, array,
hasH?) me all you want. But when it comes to Alex I best suggest a few
things, in order.
Sit down.
Shut up.
Read.
Learn.
Alex has been uniformly polite and entirely too verbose in his/her (er,
sorry Alex) explinations of not only how certain things work but why they
work, why they were made to work that way and why alternatives have not been
implemented. I have found Alex to be the single largest help on my transition
into Python and Pythonic thinking and have YET to find fault with his/her (er,
sorry Alex) reasoning. So the next time you even think Alex is being rude,
read this reply to remind yourself of what rude (and correct) is. Then follow
the above 4 steps.
Sit down.
Shut up.
Read.
Learn.
Ken Peek
idiot will want to use it"...
I agree with Doug. Think outside of the box-- don't build a box around your
limited view of the universe...
"Douglas Alan" <nes...@mit.edu> wrote in message
news:lcd7ab6...@gaffa.mit.edu...
< snip >
> I don't want my language trying to force bad programmers to write good
> code. If this is some sort of official design goal of Python, then it
> is a misguided and impossible one.
< snip >
> "Everything should be as simple as possible, but no simpler."
< snip >
> A macro capability doesn't detract from this.
< snip >
> A bad programmer has many tools available to him in Python, as it is,
> to make hard to understand code. I don't think it would go over well
> to remove useful features from the language to prevent this.
< snip >
Douglas Alan
> IE, make your own dialect.
Make your own dialect, no. Make your own embedded language, yes.
But libraries can act as embeded languages too. Without the support
of macros, however, the syntax to use them is sometimes painful.
"Extending" a language does not imply changing the semantics of the
language that is already there -- it means just what the word
"extending" means: adding new features to a language that were not
there previously. The old features are still there unperturbed,
exactly as they were before. The only change to the language is that
new syntactic forms have been added. If you don't use the new
syntactic form, just as if you don't use new functions that someone
defined, you'd never know that they were there.
> To me it is deserved. You know why? I'm a out-and-out prick.
> Sit down.
> Shut up.
> Read.
> Learn.
I know one thing for sure: I know more about programming languages and
programming language design than you do or ever will with your
attitude. Regarding listening to Alex, I'd listen to him if he
weren't also a prick. I'll tell you who I've listened to quite
carefully: Guido, who has a lot of good ideas, and the designers of
Lisp (eg, Dave Moon, John McArthy, Guy Steele, all of whom I've met
personally), who are far smatter than you, me, or Alex will ever be.
If you want me to shut up, read, and learn, I recommend that you take
your own advice, and read and learn what they have to say. They
embody a lot of wisdom that you are willing to dismiss with a wave of
your tiny little wand.
I have nothing more to say to you. You are a prick and a
self-admitted one. Have a nice time with your Perl projects.
|>oug
Johann Hibschman
> Make your own dialect, no. Make your own embedded language, yes.
> But libraries can act as embeded languages too. Without the support
> of macros, however, the syntax to use them is sometimes painful.
Hi folks. I don't want to get involved in this pissing contest, but I
thought I'd make a quick observation. Most of the point of using a
Lisp is the macro facility, so people expect it. For Python, there's
no such culture of syntax extension, so any effort in that direction
is a lost cause.
I've yet to see an algol-y language that does macros well; I've heard
good things about Dylan but I haven't looked into it yet.
However, I've been playing with Ruby a bit, and have found that the
concept of "blocks", which I gather they've taken from Smalltalk,
makes most uses of macros unnecessary. Could Python grow something
like this? Basically, it extends off the idea that if you make
lambda's easy enough to use, you don't need macros.
As an example, in Ruby I can do something like
with_directory ("/Users/johann/Documents") do
`cvs update`
end
which would expand (in python) to the equivalent of
try:
old_dir = os.getcwd()
os.chdir("/Users/johann/Documents")
os.system("cvs update")
finally:
os.chdir(old_dir)
If Python would have something like this, most of my own personal
desires for macros would be handled.
Perhaps:
with_directory("/Users/johann/Documents"):
os.system("cvs update")
where I've defined (in pseudo-python)
def with_directory(dir, &yield):
old_dir = os.getcwd()
try:
os.chdir(dir)
yield() # calls the os.system block
finally:
os.chdir(old_dir)
where the &yield would wrap up the os.system call, etc. That's
probably not going to happen (although I've heard some promising
things from the python-dev people), but it's a nice ability to have.
Just food for thought,
--Johann
--
Johann Hibschman joh...@physics.berkeley.edu
Courageous
>But libraries can act as embeded languages too.
Of course. For example, it would be quite possible for me to create
code like this in Stackless Python, if I desired:
import JoesEvilPackage
label = JoesEvilPackage.CreateLabel()
print "looping infinitely..."
JoesEvilPackage.GotoLabel (label)
At a guess, I could do this without Stackless on Unix systems with
blatant abuses of setjmp() and longjmp(). Easy access to C-language
primitives (read: "extending and embedding") are one of Python's
fortes, veritably one of the prime reasons PER SE which lead to the
birth of the language.
>"Extending" a language does not imply changing the semantics of the
>language that is already there --
Quite correct.
>I know one thing for sure: I know more about programming languages and
>programming language design than you do or ever will ...
Well, perhaps you're a bit of a prima donna, but you may very well
be right; I've observed over the years that the more exposure to
various languages one has, the less dogmatic one tends to be.
I hope you're not mistaking you interaction with this one person as
some kind of indication of the character of the Python community,
by the way: Pythoners tend to be fairly open minded, in general,
even if we do value simplicity to the point of being rather rabid about it.
Mr. Peters was quite right: the correct thing to do is submit a PEP.
Major bonus points if you grab the Python source and create a
patch which allows hygienic procedural macros for those who
would like to add this patch to their installation.
C//
Douglas Alan
> >See Guy Steele, "Growing a Language":
> http://cm.bell-labs.com/cm/cs/who/wadler/gj/Documents/steele-oopsla98.pdf
> >"We need to put tools for language growth in the hands of the users"
> That tools is the C (or Java) implementation, no? Otherwise growth
> into forms like Stackless and Alice never would have taken place.
That's a good thing too, but Steele is specifically talking about
in-language extensibility.
> > There are numerous reasons. The fact that the others are not
> > widely used, are not tuned for scripting, do not have as elegant a
> > syntax, are not as easy to learn, are not available on every
> > platform known to man, do not start up in a fraction of a second,
> > do not come with a huge library of useful tools, etc., are all
> > salient reasons. And yet there remain others.
> How does this jibe with your statement that Lisp
> "even though it was invented in the '50's, ... remains
> today one of the most modern of languages."
It's a very modern language (more modern in some ways than Python,
multimethods and a sophisticated meta-object protocol being examples
of two very modern features that it supports), but the Lisp designers
went in two different directions, neither of which was the right thing
to do to achieve world domination. This is one of the tragedies of
the ages, if you ask me. Half of the Lisp folk went and did Common
Lisp. The market for this was people who want to spend lots of money
on big bloated developments systems that rub your back and massage
your feet while you are programming. The other half went off and did
Scheme, laboring hard on making a language so small and simple and
pure and clean that no one would ever use it for anything real. Both
halfs thus relegated their lovely works to ghettos -- the Common Lisp
folk the A.I. ghetto and the Scheme folk to the academic/functional
programming ghetto. Lisp also has a funny syntax that give some
people indigestion. It looks like this:
(defmethod (fifo :DEQUEUE) ()
(if (null (cddr fifo-list))
(error 'fifo-empty)
(prog1 (cadr fifo-list)
(setf (cdr fifo-list)
(cddr fifo-list))
(if (null (cddr fifo-list))
(setq end fifo-list)))))
The chance of reviving Lisp into a mainstream language at this point
seems remote, but that doesn't mean that it can't be raided for some
of the incredible ideas that it embodies.
> Does this mean with 40+ years of development, Lisp does not have
> features of some modern language, in that it isn't widely
> used, not tuned, etc.?
No one ever did a version of Lisp that was highly tuned for scripting.
Unless you were running on a Lisp Machine, that is, but they were
rather expensive and they didn't sell many. That doesn't mean Lisp
isn't a modern language. It means that Lisp stuck to its core
audience of A.I. researchers.
There is something called "The Scheme Shell", which was a version of
Scheme that was supposed to be good for scripting, but the last time I
looked at it it took too long to start up to really be good for
scripting. This is not an inherent problem with Scheme -- it just
wasn't an ideal implementation.
> > For instance, if I had procedural macros, I wouldn't need to bug
> > the language implementers to add variable declarations -- I could
> > do it myself.
> In my limited understanding of hygenic macros, wouldn't you only
> be able to apply macros to a sufficiently Python-like language,
> in order to transform it internally to a Python representation?
> That is, you couldn't use hygenic macros to convert Pascal
> code into Python. (Is that what the 'hygenic' part means?)
Well, yes, you could use a procedural macro (hygienic, or otherwise)
to convert Pascal code to Python, but it would be one really big hairy
macro, and I don't think that be a good idea. More modestly, you
might define two macros, "let" and "set" so that
let x = 3
gets translated into
try:
x
raise VariableAlreadyBound("x")
except NameError:
x = 3
and
set x = 3
gets tranlated into
try:
x
x = 3
except NameError:
raise VariableNotBound("x")
More later.
|>oug
Aahz Maruch
Erik Max Francis <m...@alcyone.com> wrote:
>Aahz Maruch wrote:
>> In article <slrn9dooe...@teleute.dmiyu.org>,
>> Steve Lamb <morp...@here.not.there> wrote:
>>>
>>> Yess, that was an attempt at Godwin. No offense, Alex. :)
>>
>> One of the corollaries to Godwin is that deliberately invoking Godwin
>> doesn't count.
>
>Except that Godwin's law is just a statistical observation. It's the
>_convention_ that people often use that talks about threads ending;
>Godwin's law proper says nothing at all about that.
I don't understand why you're using "except"; that's the whole point of
the corollary.
--
--- Aahz <*> (Copyright 2001 by aa...@pobox.com)
Androgynous poly kinky vanilla queer het Pythonista http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6
"If we had some ham, we could have ham & eggs, if we had some eggs." --RH
Douglas Alan
> Well, perhaps you're a bit of a prima donna, but you may very well
> be right; I've observed over the years that the more exposure to
> various languages one has, the less dogmatic one tends to be.
I've devoted a lot of my time to evangelizing Python. I've talked in
public, giving free Python tutorials. Python appears prominently on
my web site (and no other language does). I've rallied endlessly at
work against significant resistance for people to use Python and set
an example by using it heavily myself against significant resistance.
*Every* time I meet someone who is interested in programming
languages, I tell them about Python. And if they use Perl or TCL, I
patiently explain to them the benefits that they would see by
switching to Python. Consequently, I have *earned* my right to
criticize Python. I do it out of love.
I have no qualms with someone who disagrees with my assessments and
thinks the coin should land on the other side of a trade-off (all of
life is about trade-offs), but it rankles my sensibilities when
someone claims that I am an ignoramus who hasn't thought about the
issues enough and isn't familiar with the Python aesthetic. All of
these things are quite untrue.
> I hope you're not mistaking you interaction with this one person as
> some kind of indication of the character of the Python community, by
> the way: Pythoners tend to be fairly open minded, in general, even
> if we do value simplicity to the point of being rather rabid about
> it.
My experience prior to Alex Martelli and Steve Lamb was always good,
so I'll try not to let them get to me. I agree that simplicity is a
virtue. I don't want Python to end up like Common Lisp, the kitchen
sink of programming languages. Dylan, however, avoided that mistake
and has macros, multimethods, etc., so it sets an example of what is
possible in a non-obese language.
> Mr. Peters was quite right: the correct thing to do is submit a PEP.
> Major bonus points if you grab the Python source and create a
> patch which allows hygienic procedural macros for those who
> would like to add this patch to their installation.
I'll put it on my schedule to think about how to do it right. But
first I have to design a whole new language for this course I'm in the
middle of taking....
|>oug
Fredrik Lundh
> I'll tell you who I've listened to quite carefully: Guido, who has a lot
> of good ideas, and the designers of Lisp (eg, Dave Moon, John McArthy,
> Guy Steele, all of whom I've met personally)
so when did any of these guys last tell you that they know more
about programming languages and programming language design
than you do or ever will?
Cheers /F
Ken Peek
patriots"...
"Steve Lamb" <gr...@despair.rpglink.com> wrote in message
news:slrn9dq3l...@teleute.dmiyu.org...
< snip >
Douglas Alan
> Douglas Alan wrote:
They didn't -- I figured that out by myself.
On the other hand, I think Dave Moon, at least, would have had qualms
no telling me this if I had had the gall to tell him to "sit down.
shut up. read. learn."
|>oug
Steve Lamb
>Tyrant! "The tree of liberty is watered from the blood of tyrants and
>patriots"...
Who knows, I could be a patriot. :P
Alex Martelli
[snip]
> > Does this mean with 40+ years of development, Lisp does not have
> > features of some modern language, in that it isn't widely
> > used, not tuned, etc.?
>
> No one ever did a version of Lisp that was highly tuned for scripting.
http://www.gnu.org/software/guile/guile.html doesn't count...?
[It's Scheme, but we've already established that you do consider
that a version of LISP].
> set x = 3
>
> gets tranlated into
>
> try:
> x
> x = 3
> except NameError:
> raise VariableNotBound("x")
How wonderful. And
set x = y + z
will no doubt get translated into Something Totally Different
to avoid erroneously raising a VariableNotBound for 'x' when
the problem is actually that y and/or z give NameError's or
such an error bubbles up from y's __add__ or ...
Us humble mortals would of course use a try/except/else instead,
totally nullyfying this problem (indeed, that IS just the kind
of thing the else clause on the try statement is there for), but
I guess this minute attention to such trifling details as doing
things right is exactly what makes us unworthy of grokking the
Tao of Python Macros (I mean, just imagine taking the trouble to
learn a language thoroughly and using it accurately before one
starts to advocate changing and complexifying it -- how TACKY!).
Alex
Alex Martelli
[snip]
> I know one thing for sure: I know more about programming languages and
> programming language design than you do or ever will with your
> attitude. Regarding listening to Alex, I'd listen to him if he
> weren't also a prick.
Possibly. On the other hand, I seem to be slightly more refined
than you at Usenet flamewars, judging for example from the styles
used to insult -- rude, direct name-calling on one side, subtler
indirect venom on the other.
> I'll tell you who I've listened to quite
> carefully: Guido, who has a lot of good ideas, and the designers of
> Lisp (eg, Dave Moon, John McArthy, Guy Steele, all of whom I've met
You may have been so busy _listening_ that you never cared
enough to *read* anything by or about the second one of these
guys -- pretty hard, otherwise, to understand how such an
outstandingly brilliant individual as you could possibly
have so laughingly failed in such a simple spelling task.
Spelling flames are tacky, but, of course, here I'm engaging
in nothing of the kind: just trying, helpful as ever, to ease
the task of readers who might otherwise spend unfruitful time
looking for works by the McArthy guy. John McCarthy's home
page is at http://www-formal.stanford.edu/jmc/ and links to
many of his most important papers.
In particular, I wonder if you have read his 1980 paper he still
holds up (as of Jan 2001) as representing his current thinking
on LISP. His comments there on POP2 succintly express his belief
that 'algol-ish' syntax (Python's is similar) is inappropriate
for a language where as in LISP "anyone can make his own fancy
macro recognizer and expander". Also the note that even in LISP
"certain macro expansion systems" lead to "over complicated
systems when generalized" (although they "always work very nicely
on simple examples") is interestingly topical. Fancy seeing you
quote the guy (albeit in a mis-spelled way) and asserting you
have "listened carefully" while apparently ignoring his words.
One might wonder if the LISTENING has resulted in any amount at
all of UNDERSTANDING.
Of course, the designers of _Dylan_ (who can hardly be accused
of being LISP-ignorant:-) disagree with this stance -- they
built a powerful language with algol-ish syntax and macros (as
we as truly powerful underlying semantics, multi-methods first
and foremost) and with it they've been trying to take over the
world for quite a bit longer than Python has. Reflecting on
the similarities and differences, and the different amount of
success that has so far (the first 12 years or so...) smiled
on both endeavours, might perhaps (to a person of refined
perception) prove more fruitful than _just_ reading about
theories. It appears to me that the crucial design-goal that
Python and Dylan did not share was *SIMPLICITY*. Exactly what
such additions as a macro-system would destroy in Python. Oh,
yea -- others of your pet theories, too, like optional use of
declarations, are prominent in Dylan (indeed, they are very
prominent there, though they focus on type-hierarchies and
the RAD-vs-optimization tradeoff rather than on trivialities
such as typos -- but anyway, there IS extra cruft^H^H^H^H
design effort to enable compile-time checking which Python
is definitely not oriented to).
> personally), who are far smatter than you, me, or Alex will ever be.
There is (fortunately, I think) no single axis along which
"smartness" is measured (cfr. Gould, "The Mismeasure of Man",
IMHO still his masterpiece, for a very well written and deep
examination of pseudo-scientific attempts to establish such
an axis, all the way up to that fraud named "the IQ"). I may
exhibit satisfactory mental performance in several activities,
such as program design, writing in natural languages other than
my native one (Italian), or declarer play in contract bridge,
and not in others such as _defensive_ play in contract bridge,
musical composition, or remembering where the heck I parked
my car. Some other individual may easily exhibit a completely
different mix of attitudes. Although the querelle is unending
and moot, I'm personally sure that both innate and environmental
factors play a role -- in no other way could I explain to my
own satisfaction the large individual variations between people
raised very similarly AND at the same time such correlations
as are observed between performance at certain tasks and time
and place of birth and education (high population density of
excellent musicians and bridge-players in Italy, low _average_
performance at foreign languages of US natives wrt Northern
European ones, etc).
An interesting, if idle, pastime, is to wonder whether the
variety of human endeavours can possibly be so vast that
at some of them even _YOU_ might be called 'smart'... sure,
the mind boggles, and yet...
Alex
Alex Martelli
> "Steve Holden" <sho...@holdenweb.com> writes:
>
> > "Douglas Alan" <nes...@mit.edu> wrote in message
>
> > > "Alex Martelli" <ale...@yahoo.com> writes:
>
> > > > As you seem totally unwilling or unable to understand that
> > > > Weltanschauung to any extent, I don't see how you could bring Python
> > > > any constructive enhancement (except perhaps by some random
> > > > mechanism akin to monkeys banging away on typewriters until 'Hamlet'
> > > > comes out, I guess).
>
> > > $#@# you too. You are very rude.
>
> > Rude, perhaps, but not usually abusive. *Please* resist the temptation
to
> > post in this vein in future.
>
> I find the quote from Alex above to be utterly abusive, and he was
How so? I assert that you give the appearance of not _getting_
the Python world-view of _simplicity_ (be it for lack of trying
or lack of ability to do so, that's a secondary issue). The unstated
middle axiom (pretty obvious, I think) being that somebody who
does not understand the bases on which a system of any richness
rests, is not going to enhance that system; I then go on to
state the syllogism's conclusion (note the "I don't _see_ how",
since I very clearly stated I'm talking about the _appearance_
["seem"] you provide with these posts -- not interested in any
speculation about "how you really ARE" or even in the existence
of 'real reality below the appearances' in this context:-). Hey,
I even admitted the outside possibility that random processes
might surprise me -- what more could one ask?-)
> abusive to me in a previous post. Calling him rude is what he
> deserves, because it is what he is.
You appear to be hopelessly in love with "the IS of identity".
Korzybski is often credited with that expression, but this may
be a denial of due credit to his predecessors, see for example
http://www.kcmetro.cc.mo.us/pennvalley/biology/lewis/historyis.htm
(all of Steven Lewis' site on General Semantics can be highly
recommended; one can then go on to something like
http://www.general-semantics.org/ -- it's the order I'd suggest).
Cognitive-behavior therapies, some of whose underpinnings can
be found in General Semantics, have often proven surprisingly
effective. I may get dissent on this point, but I believe NO
case, no matter how desperate it may look, is really incurable.
Alex
Paul Prescod
>
> ...
>
> Possibly. On the other hand, I seem to be slightly more refined
> than you at Usenet flamewars, judging for example from the styles
> used to insult -- rude, direct name-calling on one side, subtler
> indirect venom on the other.
I'll leave the meta-flamewar debate to you two. But try to remember that
this is comp.lang.python. The joy of the flame probably does not yield
long-term rewards for either participant nor for the audience.
> ... It appears to me that the crucial design-goal that
> Python and Dylan did not share was *SIMPLICITY*. Exactly what
> such additions as a macro-system would destroy in Python.
I find it hard to believe that the mere existence of the system would
destroy Python's simplicity. My impression, after years of use, is that
Python's simplicity is skin deep and that's a good thing. In other
words: Python makes all easy stuff easy AND syntactically simple (unlike
some other languages which claim to make easy stuff easy) but there are
depths of complexity in the semantics that few ever plumb.
It seems, on the other hand, like syntax is something of a sacred cow. I
really don't see how the mere ability for some yahoo to mess up his
program with some stupid syntax extension impacts the rest of us at all.
Neel K made an important point in passing: that same yahoo can mess us
up by writing totally unmaintainable, unreasonable functions. I don't
see the big difference.
And if some smart people can use hygenic macros to make Python code that
is more maintainable or readable, why should they be disallowed? Python
doesn't take away the rope -- it tends to hide it so that only people
who know what they are doing will find it. A perfect example is
func.func_code. Imagine the havoc idiots could wreak if it was widely
known that the func_code attribute is writable and func_code objects can
be constructed at runtime from raw binary data.
Steve Purcell
-Steve
--
Steve Purcell, Pythangelist
Get testing at http://pyunit.sourceforge.net/
Any opinions expressed herein are my own and not necessarily those of Yahoo
Alex Martelli
news:9bir7a$5vo$1...@slb3.atl.mindspring.net...
> Alex Martelli wrote:
> >> "There should be ONE 'obviously correct' way to do it" is one of the
> >> Python mantras
>
> Douglas Alan responded:
> >This is a BAD mantra. Not as bad as the Perl mantra, "There should be
> >3294369 ways to do it", but extremes are rarely ideal. "The truth lies
> >somewhere in the middle."
>
> Huh? His mantra isn't an extreme.
Not mine -- I think Tim Peters authored it (emphasis/quoting/potential
paraphrasing mine, as I was quoting from memory).
> "There must be only one way
> to do it" is an extreme. That is, pure orthogonality is an extreme.
Yep. I do not believe any programming language even _aims_ towards
that. How would one forbid, say,
x = y + y
as the alternative to
x = y * 2
or
x = 2 * y
without a LOT of complex rules that force a programmer to put
everything into some kind of 'normal form'?
Whence the "should" rather than "must", etc.
> Saying there "should be one 'obviously correct' way" means there
> could be other obviously correct ways as well as non-obvious ways,
> but those designs aren't Pythonic.
In practice, even with 'should' etc, it remains a _design ideal_,
as I went on to say.
> >Besides, there are many uses for procedural macros other than for
> >providing trivial syntactic sugars that are best done by using the
> >sugar already provided.
>
> You all are going to have to explain things to me. My physics
> degree never told me what "procedural macros", "hygenic macros",
The "hygienic" part has to do with namespace separation (and
might in fact be redundant in a powerful-enough base language,
or so a Common Lisp expert tells me in private correspondence).
It's sometimes informally used to distinguish them from the
text-transformation kinds of macros that the C preprocessor has.
> etc. mean. My best guess is they are transformations which act
> on parse trees before finalizing the parsing, vaguely like what
> templates do for C++ (which my physics degree did tell me about).
Sort of, but more. A C++ template only lets you define a
family of functions, classes, methods -- NOT a new syntax
form of a general kind. For example, there is no way in
C++ that a template could be used to make a new 'unless'
macro that acts "like 'if', but logically negating the
condition". The semantics of any (e.g.) function that is
defined via a C++ template is still that of a function as
is typical of C++: all arguments are evaluated before the
function code starts, etc. You COULD define 'unless' in
the C preprocessor, a la
# define unless(condition) if(!(condition))
which is a big part of why today's language designers
such as Stroustrup and Koenig detest the C preprocessor
and dream about making it obsolete someday.
Python's existing functions, classes &c are not all that
dissimilar from C++'s templates, despite acting at
runtime rather than compile-time -- certain traits,
such as signature-based polymorphism, are common, and
in practice some people with high experience of C++
template authoring appear to find the translation to
Python very smooth and painless because of that
commonality.
> If that's the case then I can see how they would be useful,
> because one nice thing about templates is to allow A = B + n * C
> to be implemented element-wise for matricies without producing
> intermediates.
That's more about the compile-time vs run-time distinction
than it is about templates.
> But every time I look to see how templates work I sigh in
> relief that someone else has done the hard work. C++ aside,
> could you present an example of how these might be used in
> Python?
Very hypothetically and superficially, for example:
macrodef unless(condition):
expand_to:
if not condition:
and then you could use
unless x > y:
print x
as a synonym of
if not x > y:
print x
It would have to be deeper, richer and more complex to allow
full power, of course, i.e., the definition of all kinds of
statements with multiple clauses including optional ones, &c.
> I'm finding it hard to conceive of significantly
> better ways to write code than what Python has already. (I
My POV is very different -- I see many languages presenting
constructs that are preferable to Python's current ones in
certain cases. If all the constructs were Pythonized, though,
the simplicity of the language would be utterly destroyed.
So, it seems to me to be a case (once again) of St. Exupery's
beautiful quote about perfection being reached, not when
there is nothing more left to add, but when there is nothing
more left to take away.
> don't see list comprehensions or string method as all that
> significant.)
I disagree with you on this -- i.e., I see both list
comprehensions and string methods as great things.
> By example I mean how it might look written in Python, not
> how it is done in Lisp, Scheme, Dylan or other language not
> used by computational physicists/chemists/biologists.
I thought Lisp did have a significant user base in biology?
http://www.franz.com/products/allegrocl/acl-bioinformatics/
and all that?
> Mind you also that justifications based on performance (as
> with my element-wise addition) don't have much weight with
The main reason for doing something at compile-time is
indeed performance, but there may be others -- you might
get somewhat-earlier diagnostics of errors (although the
templates experience tells us that the errors that DO
come may be utterly confusing, at least in the first few
years as implementers hone their skills on them), and,
with macros in particular, you might be able to alter the
syntax sugar a lot. Suppose for example that in your
application area you have a lot of need for loops that
run exactly three times. Instead of writing:
for i in range(3):
whatever(i)
over and over again, with a suitable macro you might
have the ability to write:
thrice:
whatever(index)
with a variable 'index' appearing inside the loop body
as if by black magic, etc. Perhaps instead of waiting
until runtime for an error message if you misspelled
range as ragne, you might be able to get a compile-time
message if you misspelled thrice as trice. Performance
might not be a very significant factor here, maybe.
I consider the advantages scarce in a Python context,
and the complexity increase far too high a price to
pay, again in the context of a language whose simplicity
is an important point.
> me. For that I rewrite in C. My main, number one concern
> is to have a programming language where both software
> developers and life scientists (medicinal chemists,
> biophysicists, structual biologists, etc.) can use it and
> enjoy using it. I would need to be convinced that someone
> whose programming training is a semester of FORTRAN and
> a couple of years of shell scripting can learn how 90% of
> the features in a language works without having to get any
> special training beyond help from coworkers and books.
I doubt many languages would meet this specification.
Python surely does. Maybe Sather, Tcl, Rexx. C surely
would -- it's not a features-rich language, its problems
lie elsewhere (very low-level: makes for fast code, *BUT*
hampers programmer productivity, maintainability, ...).
> >See Guy Steele, "Growing a Language":
> >
> >
> http://cm.bell-labs.com/cm/cs/who/wadler/gj/Documents/steele-oopsla98.pdf
> >
> >"We need to put tools for language growth in the hands of the users"
>
> That tools is the C (or Java) implementation, no? Otherwise growth
> into forms like Stackless and Alice never would have taken place.
I think the point is that not _every_ Python user is developing
his or her own version of Stackless, Alice, etc - there is, in
Python as in most languages, a separation between the system
programmer and the application programmer, though you might
choose to frame it otherwise. One of Lisp's traditional strengths
is in erasing this distinction, first of all by targeting the
syntax to ease of processing by machine as opposed to ease of
reading or writing by humans; suitable macros clearly _play to
this strength_. Python's slant, of course, is different.
> I use Python because I don't think one language provides everything.
> So really I don't use Python, I use Python and C/C++ .. and
I think that such a multi-language mentality is atypical in
most programming communities, although I see it a lot in
Python (and share it).
Alex
Steve Holden
news:9bj9fp$f64$1...@panix2.panix.com...
> In article <3ADCF9D4...@alcyone.com>,
> Erik Max Francis <m...@alcyone.com> wrote:
> >Aahz Maruch wrote:
> >> In article <slrn9dooe...@teleute.dmiyu.org>,
> >> Steve Lamb <morp...@here.not.there> wrote:
> >>>
> >>> Yess, that was an attempt at Godwin. No offense, Alex. :)
> >>
> >> One of the corollaries to Godwin is that deliberately invoking Godwin
> >> doesn't count.
> >
> >Except that Godwin's law is just a statistical observation. It's the
> >_convention_ that people often use that talks about threads ending;
> >Godwin's law proper says nothing at all about that.
>
> I don't understand why you're using "except"; that's the whole point of
> the corollary.
Nazi!
regards
Steve
Steve Holden
> "Steve Holden" <sho...@holdenweb.com> writes:
>
> > "Douglas Alan" <nes...@mit.edu> wrote in message
>
Woops!
> > > You are very rude.
No problems here.
>
> > Rude, perhaps, but not usually abusive. *Please* resist the temptation
to
> > post in this vein in future.
>
> I find the quote from Alex above to be utterly abusive, and he was
> abusive to me in a previous post. Calling him rude is what he
> deserves, because it is what he is.
>
> |>oug
As you might now guess, I wasn't complaining about you calling him rude ...
regards
Steve
Alex Martelli
news:slrn9dpnnd...@alum.mit.edu...
> On Tue, 17 Apr 2001 00:03:38 +0200, Alex Martelli <ale...@yahoo.com>
wrote:
> >
> > Yes, 'hygienic macros' WOULD help cut these discussions short. Pity
> > this benefit (basically restricted to c.l.p) would be balanced by
> > the productivity loss engendered by the actual existence of such
> > macros in the language -- a language which may have ANY 'syntactic
> > feature' ensures any given program is impossible to understand
> > unless you first study the exact set of macros used by its
> > author:-).
>
> I note that precisely the same argument can be made about adding
> functions to a language.
Reality easily proves that your "note" is a falsehood: despite the
existence of functions in Python, Usenet STILL buzzes with long
discussions by people who whine about Python not having their
favourite doodad. Their existence doesn't cut these discussions
short. So, how can you make this statement?
If the difference in power between functions and macros is not
clear to you, maybe a refresher in first-order versus higher-
order logic might help. This power applies to both discussion-
cutting abilities and confusion-generation potential.
Alex
Rainer Deyke
news:9bk56...@news1.newsguy.com...
> My POV is very different -- I see many languages presenting
> constructs that are preferable to Python's current ones in
> certain cases. If all the constructs were Pythonized, though,
> the simplicity of the language would be utterly destroyed.
> So, it seems to me to be a case (once again) of St. Exupery's
> beautiful quote about perfection being reached, not when
> there is nothing more left to add, but when there is nothing
> more left to take away.
It is often necessary to add something before something can be taken away.
If one new feature makes two old features redundant, adding it would work
toward the goal of increased simplicity even while adding temporary
complexity. I suspect this may apply to procedural macros.
--
Rainer Deyke (ro...@rainerdeyke.com)
Shareware computer games - http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor
Erik Max Francis
> I don't understand why you're using "except"; that's the whole point
> of
> the corollary.
The corollary is that the thread is done. The _convention_ to the
corollary is that self-invocations don't count.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ Education is a state-controlled manufactory of echoes.
\__/ Norman Douglas
Crank Dot Net / http://www.crank.net/
Cranks, crackpots, kooks, & loons on the Net.
Alex Martelli
news:UVhD6.44136$J%5.149...@news2.rdc2.tx.home.com...
[snip]
> It is often necessary to add something before something can be taken away.
> If one new feature makes two old features redundant, adding it would work
> toward the goal of increased simplicity even while adding temporary
> complexity. I suspect this may apply to procedural macros.
I suspect it would not. We'll see when Doug makes the
patches to go with his forthcoming PEP what current
Python "features" become redundant and can be removed,
of course -- discussing it in a vacuum is not very
productive. But as I recall, for example, nothing
went away from Scheme when hygienic macros were added;
some of the old stuff might be "defined in terms of
HMs" for a language lawyer, but from the POV of 99.44%
of the language users this is unproductive sophistry.
Alex
Andrew Kuchling
>
> How so? I assert that you give the appearance of not _getting_
> the Python world-view of _simplicity_ (be it for lack of trying
> or lack of ability to do so, that's a secondary issue). The unstated
For what it's worth, and at the risk of prolonging this uninteresting
sub-branch of an otherwise interesting thread, I thought Alex's
posting was an erudite and well-written flame. I didn't find it
abusive, but was certainly startled at Alex's vehemence (especially
with the 'monkeys typing' quote, which is now in the quotation file).
The idea of hygenic macros may or may not be a good one, but
Mr. Alan's case is certainly better presented than the average
new-feature posting, and I'd give him some leeway just for that alone.
(Plus we Kate Bush fans stick together.)
I agree with Tim that an explicit proposal is worth reams of list
messages, and look forward to a PEP.
--amk
Michael T. Richter
Hash: SHA1
"Steve Lamb" <gr...@despair.rpglink.com> wrote in message
news:slrn9dq3l...@teleute.dmiyu.org...
> Call me crazy, but C and C++, by most people, are considered two
> different languages with the mane difference being... Well, one is
> functional, the other OO. Wacky that, eh?
I'll call you crazy for a different reason. C is by no stretch of the
imagination a functional programming language. (C++ can be considered an
OO one -- it's just sad that so few people use it that way.:-)
- --
Michael T. Richter
"Be seeing you."
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3
iQA/AwUBOt3OB7TM3QkE7U/oEQJCiACeJn7KlyvO9Dj75S16TkRCjx4m5A8AnifE
15vvAMbBFufNbhAnftfXhU1y
=LWee
-----END PGP SIGNATURE-----
Fredrik Lundh
> I'll call you crazy for a different reason. C is by no stretch of the
> imagination a functional programming language.
think "functional clothing"
Cheers /F
Michael T. Richter
Hash: SHA1
"Fredrik Lundh" <fre...@pythonware.com> wrote in message
news:KdkD6.8016$4N4.1...@newsc.telia.net...
>> I'll call you crazy for a different reason. C is by no stretch of the
>> imagination a functional programming language.
> think "functional clothing"
In either sense of the term it isn't. :-)
- --
Michael T. Richter
"Be seeing you."
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3
iQA/AwUBOt3QorTM3QkE7U/oEQL5iACghIedU078YswnwBXzW6r32/EPheoAoPuV
spRf5jKyDxfGv62NmwZ/ympZ
=smd0
-----END PGP SIGNATURE-----
Douglas Alan
> But as I recall, for example, nothing went away from Scheme when
> hygienic macros were added; some of the old stuff might be "defined
> in terms of HMs" for a language lawyer, but from the POV of 99.44%
> of the language users this is unproductive sophistry.
I beg to differ. A language is easier to define and to maintain when
much of the language can be defined and implemented in itself.
|>oug
Douglas Alan
>>>> [|>oug:] $#@# you too.
> Woops!
>>>> [|>oug:] You are very rude.
> No problems here.
> As you might now guess, I wasn't complaining about you calling him rude ...
You mean you are upset that I said to Alex,
Love you too.
And then blotted out the "love", lest anyone be offended by
homoeroticism?
|>oug
Andrew Kuchling
> And if some smart people can use hygenic macros to make Python code that
> is more maintainable or readable, why should they be disallowed? Python
I'm increasingly opposed to new Python features, but I'm still not
ruling out the idea of hygenic macros. Their presence might remove
the pressure to add new features, which would mean the language core
would be that more stable. I expect it's very difficult to provide a
simple interface for them in Python, though, because the syntax, and
the resulting parse trees, are more complicated and less regular than
in Lisp; maybe I'm just pessimistic, though.
--amk