On 03/01/2010 01:29 AM, Michel Fortin wrote:
On 2010-02-28 18:42:50 -0500, Pelle Månsson <[email protected]> said:
Sorry if I go on and miss the point some more, but I dislike this a
lot. That's imposing restrictions on future @attributes. Like, for
example, @memoized. Or something like that. @traced, maybe.
If I'm not mistaken about your intention, making a function @memoized
wouldn't change its semantics. It'd change how it is optimized, but both
from the caller perspective and for the one who write the function's
implementation, it's totally transparent. Well, not exactly: it puts
some restrictions for the function's body, same as purity I believe.
So someone who just want to understand how a program works can ignore
@memoized when looking at it (at least until he wants to look at the
optimizations).
The difference with @property is that it changes how you call it, it's
not a transparent change at all.
This is me envisioning user-defined @attributes, really. They can
reduce boilerplate and increase flexibility in cases like @traced.
Not sure what you mean about @traced. If you mean that any call to a
function is logged somewhere, then I don't see that as a change in
semantics neither for the caller nor for the one who write the function,
so it'd have no problem having that as an attribute.
I seem to have misunderstood your intentions. I think I am clearer on
what you mean now.
What about @curried? It (potentially) changes the way the function is
called, yet looks quite good as an @attribute.
