Hacker News Reader

Comment by magicalhippo | Hacker News Reader

Ah, like Python objects then. Which is unfortunate, because that's one of my main dislikes with languages like Python.

I was imagining more along the lines of (on-the-spot pseudo-code)

    using [x := foo(...)]
    {
      bar();
      output();
    }

    func bar()
    {
      x = x + 1
    }

where bar() and output(), or something they call in turn, can reference x and it would be a compile-time error to use bar() or output() in cases where they couldn't resolve x. Or something more along those lines.

Anyway, cheers, always fun to ponder these things.

View on HN

Sorry, the Wikipedia article isn't very helpful. Your example is the correct one.

The killer feature is that you can shadow a dynamic variable, changing its value for the duration of a dynamic scope, in the same way that an inner `catch` handler overrides an outer one.

For example, you could have a dynamic variable which tells the `print` function where to send its text output. The variable's value would probably default to stdout. By temporarily assigning a string-stream to that variable, you could collect an arbitrary function's text output into a string instead. Regardless of where the text is going, any function which produces text could still use the convenient global `print` function.

Right. The closest thing I'm familiar with is the dynamic context used in Serilog[1], where you add log properties to the current scope, which gets added to each log line generated in that scope, and removed once the scope exits.

Of course, no compile-time checking there, so the combination sounds indeed quite useful.

https://github.com/serilog/serilog/wiki/Enrichment#the-logco...

Reply on news.ycombinator.com