Re: Re: names for init block keywords?

Mukhsein Johari wrote:

>...
> I think init: is confusing. How about initial: ?
> I'd prefer something like onFirstCall: but that might
> be too long for a keyword. This keyword should be on
> that reinforces the idea that the following block is
> run on the first call only. (for original as well as
> inheritor code maintainers, not to mention newbies)

As per your example below, the code is NOT called "on first call". It is 
called immediately after the function is defined.

> On a related note, from the wiki:
> -------------------------------------
> def f(x,y,z):
>     """f is a long boring function"""
>     outer:
>         f = resCache(logger(f), cacheSize = 500)
>     blah blah blah
> <pre>
> 
> This would be functionally identical to ...
> 
> <pre>
> def f(x,y,z):
>     """f is a long boring function"""
>     blah blah blah
> f = resCache(logger(f), cacheSize = 500)
> ---------------------------------------
> 
> If the two are equivalent, why add the uneeded sugar?

All sugar is unneeded so the word unneeded is redundant.

But sugar helps people to make programs that are easier to read and 
write. This particular sugar is designed to solve the same problems as 
Python's (proposed) decorators.

http://www.python.org/peps/pep-0318.html

"The current method of applying a transformation to a function or method 
places the actual translation after the function body. For large 
functions this separates a key component of the function's behavior from 
the definition of the rest of the function's external interface."

> What's wrong with just doing the latter? Isn't it
> clearer that you're actually executing code as opposed
> to defining in the latter as opposed to the former? 

Actually, in Python, a key goal is to make the feature look declarative 
rather than procedural. Mark has taken a different route in Prothon. I 
think I mildly prefer the declarative Python style but the Prothon model 
is more explicit about what it is really doing.

  Paul Prescod