> "Greg" == Greg Ewing <[EMAIL PROTECTED]> writes:
Greg> I didn't claim that people would feel compelled to eliminate
Greg> all uses of lambda; only that, in those cases where they
Greg> *do* feel so compelled, they might not if lambda weren't
Greg> such a long word.
Sure, I u
> "Andrew" == Andrew Koenig <[EMAIL PROTECTED]> writes:
Andrew> Wel Shouldn't you have written
Andrew> (mapcar car list-of-lists)
Andrew> or am I missing something painfully obvious?
Greg should have written
(with-file "foo/blarg" 'do-something-with)
too. I g
[EMAIL PROTECTED] wrote:
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 triggered off something in my mind that's somewhat
different from what you went on to talk about.
So far we
Jim Jewett wrote:
I had been thinking that the typical use would be during function (or
class) definition. The overhead would be similar to that of decorators,
and confined mostly to module loading.
But that's too late, unless you want to resort to bytecode
hacking. By the time the module is loade
Shane Holloway (IEEE) wrote:
So, the question comes back to what are blocks in the language
extensibility case? To me, they would be something very like a code
object returned from the compile method. To this we would need to
attach the globals and locals where the block was from. Then we cou
>> >> (3) Add macros. We still have to figure out how to limit their
obfuscation.
>> > nobody has given even a *remotely*
>> > plausible mechanism for how exactly you would get code executed at
>> > compile time.
>> macros can (and *possibly* should) be evaluated at run-time.
> We must still
Stephen J. Turnbull wrote:
This doesn't feel right to me. By that argument, people would want
to "improve"
(mapcar (lambda (x) (car x)) list-of-lists)
to
(mapcar list-of-lists (x) (car x))
I didn't claim that people would feel compelled to eliminate
all uses of lambda; only that, in those case
> This doesn't feel right to me. By that argument, people would want
> to "improve"
>
> (mapcar (lambda (x) (car x)) list-of-lists)
>
> to
>
> (mapcar list-of-lists (x) (car x))
>
> Have you ever heard someone complain about that lambda, though?
Wel Shouldn't you have written
On 4/26/05, Rodrigo Dias Arruda Senra <[EMAIL PROTECTED]> wrote:
> IMVHO, macros are readability assassins. The power (for any developer)
> to introduce new syntax is *not* a desirable feature, but something
> to be avoided. And that alone should be a stronger argument than
> a hundred use case
[ Michael Walter ]:
> A couple of examples out of my tired head (solely from a user perspective) :-)
>
> Embedding domain specific language (ex.: state machine):
> ...
>
> Embedding domain specific language (ex.: markup language):
> ...
>
> Embedding domain-specific language (ex.: badly-designed
ences 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
> "Greg" == Greg Ewing <[EMAIL PROTECTED]> writes:
Greg> This raises the question of why people feel the need for
Greg> macros in Lisp or Scheme, which have an even more minimal
Greg> and flexible syntax. I think part of the reason is that the
Greg> syntax for passing an uneval
Michael Chermside wrote:
if the answer is that we want to prohibit nothing, then the right
solution is macros.
I'm not sure about that. Smalltalk manages to provide very
reasonable-looking user-defined control structures without
using compile-time macros, just normal runtime evaluation
together wit
Michael Chermside wrote:
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.
I considered saying something like that
Jim Jewett wrote:
defmacro myresource(filename):
with myresource("thefile"):
def reader():
...
def writer():
...
def fn():
-1. This is ugly.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,
A couple of examples out of my tired head (solely from a user perspective) :-)
Embedding domain specific language (ex.: state machine):
stateful Person:
state Calm(initial=True):
def react(event):
self.chill_pill.take()
ignore(event)
state Furious:
def react(event):
Robert Brewer wrote:
Shane Hathaway wrote:
Robert Brewer wrote:
So currently, all subclasses just override __set__, which leads to a
*lot* of duplication of code. If I could write the base
class' __set__
to call "macros" like this:
def __set__(self, unit, value):
self.begin()
if s
Robert Brewer wrote:
> I still prefer more methods, because my actual use-cases are more
> complicated. Your solution would work for the specific case I gave, but
> try factoring in:
>
> * A subclass which needs to share locals between begin and post, instead
> of pre and post.
>
> or
>
> * A se
It seems that what you call macros is really an unlimited
preprocessor. I'm even less interested in that topic than in macros,
and I haven't seen anything here to change my mind.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Pytho
On 4/25/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > It could also be done (though not as cleanly) by making macros act as
> > import hooks.
> Brrr. What about imports that aren't at the top level (e.g. inside a
> function)?
Bad style already. :D
If you want to use the macro, you have to
Shane Hathaway wrote:
> Robert Brewer wrote:
> > So currently, all subclasses just override __set__, which leads to a
> > *lot* of duplication of code. If I could write the base
> class' __set__
> > to call "macros" like this:
> >
> > def __set__(self, unit, value):
> > self.begin()
>
Robert Brewer wrote:
> So currently, all subclasses just override __set__, which leads to a
> *lot* of duplication of code. If I could write the base class' __set__
> to call "macros" like this:
>
> def __set__(self, unit, value):
> self.begin()
> if self.coerce:
>
Michael Chermside:
> There are lots of things one might want to replace within macros, from
> identifiers to punctuation, but I'd be willing to live with just two of
> them: expressions, and "series-of-statements" (that's almost the same as
> a block). There are only two places I'd want to be able
Guido van Rossum wrote:
> > Why not just introduce macros?
>
> Because I've been using Python for 15 years without needing them?
> Sorry, but "why not add feature X" is exactly what we're trying to
> AVOID here. You've got to come up with some really good use cases
> before we add new features. "I
Michael Chermside wrote:
> Jim:
> > Why not just introduce macros? If the answer is "We
> > should, it is just hard to code", then use a good
> > syntax for macros. If the answer is "We don't want
> > xx sss (S\ > to ever be meaningful", then we need to figure out exactly what to
> > prohi
> It could also be done (though not as cleanly) by making macros act as
> import hooks.
>
> import defmacro# Stop processing until defmacro is loaded.
> # All future lines will be
> preprocessed by the
>
Guido writes:
> My problem with macros is actually more practical: Python's compiler
> is too dumb. I am assuming that we want to be able to import macros
> from other modules, and I am assuming that macros are expanded by the
> compiler, not at run time; but the compiler doesn't follow imports
> (
Guido:
> My problem with macros is actually more practical: Python's compiler
> is too dumb. I am assuming that we want to be able to import macros
> from other modules, and I am assuming that macros are expanded by the
> compiler, not at run time; but the compiler doesn't follow imports ...
Expa
Aahz wrote:
On Mon, Apr 25, 2005, Shane Holloway (IEEE) wrote:
Interfaces::
def interface(interfaceName, *bases, ***aBlockSuite):
blockGlobals = aBlockSuite.globals().copy()
blockGlobals.update(aBlockSuite.locals())
blockLocals = {}
exec aBlock in blockGlobals, block
Michael Chermside wrote:
> 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
Paul Moore wrote:
> I think the key difference with macros is that they act at compile
> time, not at run time. There is no intention here to provide any form
> of compile-time processing, and that makes all the difference.
>
> What I feel is the key concept here is that of "injecting" code into a
On Mon, Apr 25, 2005, Shane Holloway (IEEE) wrote:
>
> Interfaces::
>
> def interface(interfaceName, *bases, ***aBlockSuite):
> blockGlobals = aBlockSuite.globals().copy()
> blockGlobals.update(aBlockSuite.locals())
> blockLocals = {}
>
> exec aBlock in blockGl
Michael Chermside wrote:
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
On 4/25/05, Michael Chermside <[EMAIL PROTECTED]> wrote:
> 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.
Michael Chermside wrote:
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
> 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!)
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 stumb
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. The only difference I see is that in
this case, the macros are limited to entire (possibly compound)
statements.
To make this more concrete,
Gu
38 matches
Mail list logo
