[Python-Dev] defmacro (was: Anonymous blocks)

[flaig at sanctacaris.net]

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 <mcherm at mcherm.com>
> Subject: RE: [Python-Dev] defmacro (was: Anonymous blocks)
> To: python-dev at python.org
> Cc: jimjjewett at gmail.com
> Message-ID: <20050425094254.wf6wbmkg0pwkocwo at mcherm.com>
> 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
> ===
Chevalier Dr. Dr. Ruediger Marcus Flaig
   Institute for Immunology
   University of Heidelberg
   Im Neuenheimer Feld 305, D-69120 Heidelberg, FRG
   <flaig at sanctacaris.net>



--
Diese E-Mail wurde mit http://www.mail-inspector.de verschickt
Mail Inspector ist ein kostenloser Service von http://www.is-fun.net
Der Absender dieser E-Mail hatte die IP: 129.206.124.135