4 ms·

It's not mutation if it occurs before anyone can ever reference it. Then it's called construction. Even languages with labeled effects allow for this sort of c

It's not mutation if it occurs before anyone can ever reference it. Then it's called construction. Even languages with labeled effects allow for this sort of construction effect. If they can properly sequence and isolate it, they allow mutation as well!

lmm 9y ago
a = f(b) is fine - it's clear to the reader that a might or might not end up having anything to do with b. @f a = b is not at all clear as a syntax for the same thing - a reader would very much expect a to = b after execution of a line like that.
- KirinDave 9y ago
  I'm a bit confused. Is @f a = b valid Python syntax? What's it implying? Why would it be a mutation? Is it because of a call-by-name convention you're implying, or because function metaprogramming in Python has write as well as read for properties? If you dislike call-by-name, why is Python's practice of insisting all non-trivial functions be called by name is not distasteful to you?
  - lmm 9y ago
    > Is @f a = b valid Python syntax? No, I was trying to isolate the important part. "@f def a: return b" would be the Python syntax, and I think it's misleading as sugar for, hmm, you'd have to write it as "a = f(lambda: b)" (hmm, I'd forgotten how different defining a function "natively" or as a lambda value are in Python). You seem to be using a different definition of call-by-name to the one I'm used to. What bothers me is that a decorator can make a function behave completely differently (e.g. its body might never even be executed) but the syntax doesn't look like it can make that big a change to the function.
    - KirinDave 9y ago
      I think that's a fair concern, although the semantics of the decorator probably make that what you want in some points. I guess in Python land, blueprint's entire purpose is to selectively fire your handlers.

4 ms·

It's not mutation if it occurs before anyone can ever reference it. Then it's called construction. Even languages with labeled effects allow for this sort of c

by KirinDave 9y ago

lmm 9y ago
a = f(b) is fine - it's clear to the reader that a might or might not end up having anything to do with b. @f a = b is not at all clear as a syntax for the same thing - a reader would very much expect a to = b after execution of a line like that.
- KirinDave 9y ago
  I'm a bit confused. Is @f a = b valid Python syntax? What's it implying? Why would it be a mutation? Is it because of a call-by-name convention you're implying, or because function metaprogramming in Python has write as well as read for properties? If you dislike call-by-name, why is Python's practice of insisting all non-trivial functions be called by name is not distasteful to you?
  - lmm 9y ago
    > Is @f a = b valid Python syntax? No, I was trying to isolate the important part. "@f def a: return b" would be the Python syntax, and I think it's misleading as sugar for, hmm, you'd have to write it as "a = f(lambda: b)" (hmm, I'd forgotten how different defining a function "natively" or as a lambda value are in Python). You seem to be using a different definition of call-by-name to the one I'm used to. What bothers me is that a decorator can make a function behave completely differently (e.g. its body might never even be executed) but the syntax doesn't look like it can make that big a change to the function.
    - KirinDave 9y ago
      I think that's a fair concern, although the semantics of the decorator probably make that what you want in some points. I guess in Python land, blueprint's entire purpose is to selectively fire your handlers.