[viraptor]

This seems like a solution in search of a problem. There is a nice 'forever' construct. It's called 'while':

    while True:
      action()

I know what you mean about generalising this to other control structures, but it looks like the whole concept starts from "I want to write 'forever' that resembles something from other languages", rather than "I want to write a loop". There are existing ways to write things like that, so is do we really need to force something from other languages into Python? What about some examples which cannot be easily handled - maybe the solution for them is something completely different than porting codeblocks.

[stcredzero]

You are missing the point. The forever structure is just a code example. What's missing is the ability to write your own control structures generally. (Some of which won't already exist.)

[viraptor]

That is exactly what I meant - this is a synthetic example. The article has synthetic examples. People want code blocks, but no one is really showing why. Own control structures are cool, ok, but what are you trying to solve with them? Where are the real, convincing before and after examples that are not easily solvable otherwise?

[Peaker]

Here's some Haskell code I really like, and I think it would be far less nice in Python:

  replicateM 10 . forkIO . forever $ do
    ..

Which is basically the same as:

  replicateM 10 (forkIO (forever (do ..)))

replicateM 10 executes its code block argument 10 times. forkIO executes its code block argument in a new thread. forever loops forever.

So this line basically creates a thread pool with 10 threads, all infinitely executing the given code block.

How would you solve this in Python?

[Goladus]

> How would you solve this in Python?

The question is how does codeblocks solve this problem in Python, not how does Haskell solve this problem in Haskell.

[Peaker]

Hypothetical Python:

  times(10, forkIO(forever(block:
     ...
     )))

[Goladus]

That's not what codeblocks does, though. You use a with statement and a new operator (<<). Then use indentation for the blocks. It doesn't look like you're passing a block to a function. The result is quirky code that will be hard to trace and sort out if you don't already know what's happening.

[sirclueless]

I can honestly say that the ability to write your own control structures is one of the quickest ways to make me hate developing in a particular language. Any time you use them, your code becomes significantly less readable, and significantly less portable.

It all just becomes a giant clusterfuck way too quickly. Small set of well-defined semantics, please.

[stcredzero]

Any time you use them, your code becomes significantly less readable, and significantly less portable.

Specific examples?

I've actually often found the opposite to be true, given a good (meta) syntax for handling this.

I've often seen patterns in Smalltalk like:

    myTransaction 
        commit: [
            "Stuff happens here"
        ]
        onRollback: [   
            "handles rollback"
        ].

Semaphores are used for critical sections like so:

    (mySemaphore)
        critical: [
            "critical section code goes here"
        ].

I think these examples show how such a thing can increase readability.

As far as the portability thing goes, I've never heard of that being a terrible problem in Smalltalk. If code from one environment has some custom method like "isNilOrFalse:" or something like "ifNotNilDo:" then it's a simple matter to port that code over another environment, or have it syntactically rewritten by the browser to make a portable library. The sorts of patterns I list above are generally for DSLs that are only used internally in a given library or for code that uses the particular library, so portability isn't a problem. The structures are carried where needed by the library.

It all just becomes a giant clusterfuck way too quickly. Small set of well-defined semantics, please.

Smalltalk does have a small set of well-defined semantics, just not at the level you're used to. I have never heard of modifications that break the control flow standard library. My experience is that good programmers don't change how the "standard" behaviors work, because those changes tend to break the rest of the code base.