Going the PL/1 way

[Robin Becker]

Miklós wrote:
> Ok, seems like we have @decorators. It's a nice tribute to Intercal.  But
> I'd prefer #decorators.
> 
> We have metaclasses for pleasure brain-melting. We have generators,
> new-style classes and old-style classes. Lambdas are wonderful.
> We do need real interfaces, not abused classes.  Python still needs to have
> inlined functions, macros and templates. Operator overloading is not enough,
> one should be able to introduce new ones freely. There's a heavy demand for
> terciary comparisons. Why don't we have a 'case' statement and 'do... repeat
> ()'?
> We cannot do without general closures, of course.  Hm, automatic garbage
> collection is sometimes fine but explicite memory allocation/deallocation is
> really unavoidable for efficient programs.
> Wait, pointers are a must! Static typing should have been introduced a long
> time ago. You just cannot do without absolute address variables.
> 
> Yes, I'm thorougly annoyed with creeping featurism.
> 
> Miklós
> 
.....

I'm not exactly against 'decorators' although it seems to me thay should 
be called 'transformers' as it seems they act to transform the following 
  function definition.

On the other hand the proposed syntax is abominable.

Additionally there now seems to be at least two 'one and only obvious' 
ways to handle these transformations.

     @classmethod
     def meth(...):
         ...

or
     def meth(...):
         ...
     meth = classmethod(meth)


As a final silliness (or perhaps miracle) this can apparently all be 
done in python using code from PJ Eby so a standard decorate mechanism 
could have gone into the library while the Gods argue.

Decision by exhaustion is surely not a good recipe.
-- 
Robin Becker