If you want X, you know where to find it (was Re: do...until wisdom needed...)

[Andrew Dalke]

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.  "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
                    dalke at acm.org