decorators as generalized pre-binding hooks

[Ron Adam]

Bengt Richter wrote:
> On Sun, 10 Jul 2005 05:35:01 GMT, Ron Adam <rrr at ronadam.com> wrote:

>>So far they are fairly equivalent.  So there's not really any advantage 
>>over the equivalent inline function.  But I think I see what you are 
>>going towards.  Decorators currently must be used when a function is 
>>defined.  This option attempts to makes them more dynamic so that they 
>>can be used where and when they are needed.
> 
> IMO part of the decorator benefit is clearer code, and also IMO the
> @range_check and @default_value decorators succeed in that. The code
> generated would presumably be the same, unless the exception capture
> discussed further down were implemented.

If you take the decorator at face value, it's clear. (In a sort of 
because I said so way.) But if you look in the decorator, it may be 
quite unclear.  Ie.. it sort of sweeps the dirt under the rug. (IMO) 
The thing is, defining a decorator can be fairly complex compared to a 
regular function depending on what one is trying to do.


>>How about if you make it optional too?

>>@@keeplog log_of_interesting_values     # if keeplog decorate.
>>b = get_value(c,d)
>>
>>Just a thought.
> 
> Yes, but that is too easy to do another way. Plus I want to reserve
> '@@' for an AST-time decoration idea I have ;-)

The @@ could be whatever, but a single @ could probably be used just as 
well.

How about any line that begins with an @ is preparsed as sugar.  And 
then create a simple sugar language to go along with it?

But that would be compile time macros wouldn't it. ;-)


>>When it comes to decorators, and now the with statements, I can't help 
>>but feel that there's some sort of underlying concept that would work 
>>better.  It has to do with generalizing flow control in a dynamic way 
>>relative to an associated block.
>>
>>One thought is to be able to use a place holder in an expression list to 
>>tell a statement when to do the following block of code.
> 
> it depends on scope and control aspects of what you mean by "block".

By block I meant the indented following suite.  No special scope rules 
that don't already currently exist in any 'if', 'while', or 'for' suite.


> But I doubt if we have much chance of introducing something is one
> more bf in the storm of "with" ideas that have already been
> discussed.

I'd like to think until 2.5 is released that there's still a chance that 
something better could come along.  But it would have to be pretty darn 
good I expect.


> They strike me as a kind of macro idea where the only substitution argument
> is the block suite that follows, which IMO is a severe limitation on both
> the macro idea and the use of blocks ;-)

I'm not sure it's macro or not.  Maybe it's a flow control parser 
statement?

      Does that sound any better than macro?  ;-)


>>I like the place holders because I think they make the code much more 
>>explicit and they are more flexible because you can put them where you 
>>need them.
> 
> Yes, but if you want to go that way, I'd want to have named place holders
> and be able to refer to arbitrary things that make sense in the context.

 From what I've seen so far, there's a lot of resistance to real run 
time macro's.  So I don't expect them any time soon.

The mechanism I suggested doesn't store code or name it. So it's not a 
macro, it's closer to a while that conditionally runs the body, but in 
this case the condition is when instead of if.  It's a different concept 
that I think can compliment the language without being too complex.


Named macros make it even more useful.

Here I used 'this' as the keyword to indicate when the suite is to be 
done.  So it's a do-this-suite statement.


	do f = opening(filename); try this; finally f.close():
     		suite


Now using "Sugar" language!    ;-)

         # Create sugar
	@with_opened = "opening(%s); try this; finally f.close()"


	do f = $with_opened%('filename'):    # $ indicates sugar
    		suite



I used Pythons % operator as it already exists and works fine in this 
situation.  Easy to implement as well.

Hmm.. not sure how to apply this to a decorator. Lets see... Working it 
out...

     # function to use
     def check_range(x):
        if x in range(10,25):
	   return
        raise RangeError    # or what ever is suitable

     # Make the decorator with sugar
     @checkrange = "%s %s check_range(%s)"

Parses on spaces as default?

     $checkrange%           # Use the following line here
     x = 24                 # since nothing given after the %


Which will results in...

     x = check_range(24)


There should be a way to specify an additional argument I think.

The exact rules would need to be worked out.  It also might be a good 
way to test sugar ideas before they become part of the language.


>>>orthogonal-musing-ly ;-)
>>
>>"Orthogonal is an unusual computer language in which your program flow 
>>can go sideways. In actuality in can go in just about any direction you 
>>could want."
>>
>>   http://www.muppetlabs.com/~breadbox/orth/
> 
> Interesting. And an implementation from our own Jeff Epler?

I didn't see that.  LOL

Cheers,
Ron


> Regards,
> Bengt Richter