[DanWaterworth]

Python's "with" construct is analogous to the bracket pattern in Haskell that the article is talking about. It also works in the nested case in the presence of exceptions. Furthermore, the issue that Michael has with the bracket pattern in Haskell can also happen in Python.

[anentropic]

True, but in Python the coding mistake would stand out much more because the with block is syntax sugar - it does not look like regular function application, whereas in the Haskell example there is nothing to tell you that withMyResource is using the 'bracket pattern' (except by reading the src)

Also I guess in Haskell there is more expectation that the type system should prevent you from expressing runtime errors

[DanWaterworth]

I can see why you might think that, being built into the language, using 'with' in Python in a broken way would be easier to spot. However, having used both languages extensively, I can tell you that, at least for me, there's no discernible difference.

I think the reason for this is might be that, in Haskell, a function starting with 'with' is, by convention, using the bracket pattern and the way that you might use such a function would be very similar in structure to the Python way.

Something that is often said about C++ is that, you're only ever using 10% of the language, but that everyone uses a different 10% and it's true, but it's true of every language to differing degrees. Everyone has their own way of forming programs, just like everyone has their own slightly different style of playing chess, cooking or forming sentences.

When you have a well developed style, you will quickly spot any deviations from it. At that point, it doesn't matter if your style was forced on you by the language or whether it's just a convention that you use.

It's certainly true that Haskellers expect a lot from the type system, even compared to other static languages, let alone Python.

[anentropic]

I only mean it's visibly more obvious, you have an indented block... what is the purpose of the indented block unless to say "do all your stuff with the resource _inside_ this block". Using the with block is very 'intentional' feeling.

I'm not very familiar with Haskell but it seems like you'd get used to the type system telling you everything you need to know. But in this case it doesn't. In Python world we talk about 'pythonic/unpythonic'... it seems like it's maybe quite unhaskellish to have to rely on a naming convention and remembering not to use the return value of the function?

I would guess that's why the article and many of the other comments here focused on how you could express this behaviour in Haskell's type system, where you'd expect it.

In short: type system > syntax sugar > naming convention

[DanWaterworth]

> I only mean it's visibly more obvious, you have an indented block...

Haskell is more similar than you realise, it's the difference between this:

    withSomeResource $ \resource -> do
      someFunctionOn resource

and this:

    with some_resource() as resource:
        some_function_on(resource)

> I'm not very familiar with Haskell but it seems like you'd get used to the type system telling you everything you need to know

As an outsider, you might expect a type-error to mean that you made a logic error, in practice it usually means you made a typo.

What happens is that the type system forces you to write things in a certain way. You internalize its rules and it moulds your style. You don't try random things until they stick, you write code expecting it to work and knowing why it should, just like you would in Python. It's just that more of your reasoning is being verified. "Verified" is the operative word here - the type system doesn't tell how to do anything.

> it seems like it's maybe quite unhaskellish to have to rely on a naming convention and remembering not to use the return value of the function?

The Python equivalent of the problem here would be:

    current_resource = a_resource

    with some_resource() as resource:
        current_resource = resource

    current_resource.some_method()

So it's not that using the return value of the withSomeResource function is a problem, it's the resource escaping from the scope where it is valid.

I think the crux of our discussion is about checked vs unchecked constraints.

When you work on (successful) large codebases, whether in a static or dynamically typed language, there are always rules about style (and I mean this in a broader way than how your code is laid out). For example, in large Python projects, there might be rules about when it is acceptable to monkey-patch. These rules make reasoning about the behaviour of these programs possible without having to read through everything.

Large Haskell projects also have these rules, but Haskellers like to enforce at least some of them using the type system. It takes effort to encode these rules in the type system and it is more difficult to write code that demonstrably follows the rules than implicitly follows them, but the reward for this effort is that it gives you some assurance that the rules are actually being followed everywhere.

For some rules this extra effort makes sense and other times it doesn't. The type system is just another way to communicate intent. Writing the best Haskell doesn't necessarily mean writing the most straight-jacketly typed Haskell, but it does give you that option. Beginners often fall into the trap of wanting to try out the new-and-shiny and making everything more strict than is helpful.

For one-man projects, there's really no advantage to Haskell over Python (with the caveat that you may not remember all of the intricacies of your code in six months and using Haskell you may have encoded more of your assumptions in the type system).

[dllthomas]

Right. I mean, consider your simple python:

    with some_resource() as resource:
        some_function_on(resource)

Is that broken? If some_function_on saves the resource, yes. If it just temporarily uses it, no.

I don't think the claim that it's syntactically obvious in Python is correct. In both cases the typical syntax helps a little but it's easy to get wrong.

It is the case that "the typical syntax" is a little more enforced by Python-the-language.