Is there a way to change the closure of a python function?

[Chris Angelico]

On Wed, Sep 28, 2016 at 6:52 PM, Gregory Ewing
<greg.ewing at canterbury.ac.nz> wrote:
> Chris Angelico wrote:
>>
>>
>> <greg.ewing at canterbury.ac.nz> wrote:
>>
>>> * No side effects (new variable bindings may be created, but
>>>  existing ones cannot be changed; no mutable data structures).
>>
>>
>> If that's adhered to 100%, the language is useless for any operation
>> that cannot be handled as a "result at end of calculation" function.
>
>
> Surprisingly, that turns out not to be true. Modern
> functional programming has developed some very elegant
> techniques for expressing state-changing operations in
> a functional way, using things they call monads.
>
> Essentially you write the whole program in continuation-
> passing style, with a state object being passed down an
> infinite chain of function calls.
>
> None of the functions ever return, so there's no
> danger of an "old" state being seen again after the state
> has changed. This allows in-place mutations to be
> performed as optimisations; it also allows I/O to be
> handled in a functional way.

If monads allow mutations or side effects, they are by definition not
pure functions, and violate your bullet point. Languages like Haskell
have them not because they are an intrinsic part of functional
programming languages, but because they are an intrinsic part of
practical/useful programming languages.

>> You can't produce intermediate output. You can't even produce
>> debugging output (at least, not from within the program - you'd need
>> an external debugger). You certainly can't have a long-running program
>> that handles multiple requests (eg a web server).
>
>
> Well, people seem to be writing web servers in functional
> languages anyway, judging by the results of googling for
> "haskell web server". :-)

Again, Haskell has such features in order to make it useful, not
because they're part of the definition of "functional programming".

>> Unless you're deliberately defining
>> "functional language" as "clone of Haskell" or something, there's no
>> particular reason for this to be a requirement.
>
>
> It's not *my* definition, I'm just pointing out what
> the term "functional language" means to the people
> who design and use such languages. It means a lot more
> than just "a language that has functions". If that's
> your definition, then almost any language designed
> in the last few decades is a functional language, and
> the term is next to meaningless.

Of course it's more than "a language that has functions"; but I'd say
that a more useful comparison would be "languages that require
functional idioms exclusively" vs "languages that support functional
idioms" vs "languages with no functional programming support". Python
is squarely in the second camp, with features like list
comprehensions, map/reduce, etc, but never forcing you to use them. (C
would be one I'd put into the third camp - I don't think it'd be at
all practical to try to use any sort of functional programming idiom
in C. But I might be wrong.)

>> Python is predominantly a *practical* language. Since purely
>> functional programming is fundamentally impractical, Python doesn't
>> force us into it.
>
>
> The point is that a true functional language (as
> opposed to just "a language that has functions") *does*
> force you into it. Lack of side effects is considered
> an important part of that paradigm, because it allows
> programs to be reasoned about in a mathematical way.
> If that's not enforced, the point of the whole thing
> is lost.
>
> The fact that Python *doesn't* force you into it means
> that Python is not a functional language in that sense.

Right. But my point is that *no* truly useful general-purpose language
actually enforces all of this. A language with absolutely no side
effects etc is a great way to represent algebra (algebra is all about
a search for truth that existed from the beginning - if you discover
half way through that x is 7, then x must have actually been 7 when
the program started, only you didn't know it yet), but it's a terrible
way to do any sort of I/O, and it's rather impractical for really
long-running calculations, being that much harder to debug. The
languages most commonly referred to as "functional languages" are
merely *closer to* a pure no-side-effect language - they encourage
functional styles more strongly than Python does.

I strongly support the use of pure functions in places where that
makes sense. They're much easier to reason about, write unit tests
for, etc, etc, than are functions with side effects. But most
practical programming work is made easier, not harder, by permitting
side effects.

ChrisA