Actually I was thinking of something related the other day: Wouldn't it be nice
to be able to define/overload not only operators but also control structures?
That way Python's core language could be kept simple and free of "featuritis"
while at the same time everyone who desires a match/case or repeat/until
statement, or anything more sophisticated, could implement it for himself.
If you suspect that good old Lisp is on my mind, you are probably right :) .
Actually, the idea of a programming language whose structures can be adapted to
everyone's personal style is still very appealing to me.
I have no very distinct ideas about how such a thing might be designed (and
still less whether it could be made to work efficiently), but perhaps somewhat
like this (just to clarify along which paths my thoughts are currently moving):
structure whaddayacallit: # name only as a comment
def opening_clause:
statements
def alternative_clause_1:
statements
def *alternative_clause_2: # the asterisk to indicate that this may occur
several times
statements
def closing-clause:
statements
e.g.:
structure multiple_switch:
condition = None
def switch(self, c): # condition must be passed as a lambdoid function
self.condition, self.finished = c, False
def *case(self, x, statements): # so must the statements subordinate to the
new "case" expression
if self.condition( x ):
statements()
self.finished = True
break structure
def otherwise(self, statements);
if not self.finished:
statements()
and the application:
switch my_favourite_language:
case Python:
print "Hi Guido"
case Perl:
print "Hi Larry"
otherwise:
print "Hi pleb"
At least to me, this has a definitively macroish flavour... and not in the
#dumbdown style of C. Or rather say, macros might be a generalized way to
achieve this, if they are intelligently designed. (<= That at least shouldn't
be the problem, since this is the Python community and not M$'s development
department :-) .)
Do you think any of this might make sense?
-- Rüdiger Marcus
PS. Aahz: When describing Ruby as the "antithesis" of Python recently I was
thinking in Laskerian rather than Hegelian terms... the differences are not
really big, but Ruby has always been positioned as a deliberate challenge to
Python.
Date: Mon, 25 Apr 2005 09:42:54 -0700
> From: Michael Chermside <[EMAIL PROTECTED]>
> Subject: RE: [Python-Dev] defmacro (was: Anonymous blocks)
> To: python-dev@python.org
> Cc: [EMAIL PROTECTED]
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Jim Jewett writes:
> > As best I can tell, the anonymous blocks are used to take
> > care of boilerplate code without changing the scope -- exactly
> > what macros are used for.
>
> Folks, I think that Jim is onto something here.
>
> I've been following this conversation, and it sounds to me as if we
> are stumbling about in the dark, trying to feel our way toward something
> very useful and powerful. I think Jim is right, what we're feeling our
> way toward is macros.
>
> The problem, of course, is that Guido (and others!) are on record as
> being opposed to adding macros to Python. (Even "good" macros... think
> lisp, not cpp.) I am not quite sure that I am convinced by the argument,
> but let me see if I can present it:
>
> Allowing macros in Python would enable individual programmers or
> groups to easily invent their own "syntax". Eventually, there would
> develop a large number of different Python "dialects" (as some
> claim has happened in the Lisp community) each dependent on macros
> the others lack. The most important casualty would be Python's
> great *readability*.
>
> (If this is a strawman argument, i.e. if you know of a better reason
> for keeping macros OUT of Python please speak up. Like I said, I've
> never been completely convinced of it myself.)
>
> I think it would be useful if we approached it like this: either what
> we want is the full power of macros (in which case the syntax we choose
> should be guided by that choice), or we want LESS than the full power
> of macros. If we want less, then HOW less?
>
> In other words, rather than hearing what we'd like to be able to DO
> with blocks, I'd like to hear what we want to PROHIBIT DOING with
> blocks. I think this might be a fruitful way of thinking about the
> problem which might make it easier to evaluate syntax suggestions. And
> if the answer is that we want to prohibit nothing, then the right
> solution is macros.
>
> -- Michael Chermside
> ===
Cheva
