Hacker News Reader

Comment by kenjackson | Hacker News Reader

1. Special variables seems really like a take it or leave it idea. I'm really not convinced that keeping these as explicit arguments of a function are a bad idea. I really like the ability to reason about a function by simply knowing its arguments (including the mplicit self/this).

2. Condition handling seems generally useful. There are definitely cases I could have used this. It's probably pretty straightforward to add to languages that have exceptions. Although I'd be surprisd to see it appear (pleasantly surprised).

3. I'm a little confused about this one... He's talking about just modifying the bound variables? C# and VB do this. And presumably Ruby and Python can too -- although he seems to allude to the fact that Python can't, which doesn't make sense (otherwise it seems odd to call them closures) -- or did I miss what he is really talking about (which I suspect I am)?

View on HN

"1. Special variables seems really like a take it or leave it idea. I'm really not convinced that keeping these as explicit arguments of a function are a bad idea. I really like the ability to reason about a function by simply knowing its arguments (including the mplicit self/this)."

Sometimes it is nice to influence the entire call stack. The canonical example of this is probably re-directing "system out." Special variables provide a nice solution to the problem of making all the printlns in a call stack go to a file instead of the console or REPL, for example. That would be really awkward if you had to chain the System Out variable through all the calls.

> Condition handling seems generally useful. There are definitely cases I could have used this. It's probably pretty straightforward to add to languages that have exceptions.

Actually, it's not. In "normal" exceptions by the time an exception gets to you the computation that threw it is gone. The exception mechanism has to travel up the call stack to find the handler, and can't get back to where it was.

You can fake it in many languages, but you can't retroactively make the language support the behavior. You end up with a nasty mess that, although it may be powerful, is so far removed from the normal idioms of the language everyone you work with will want to kill you for doing it.

Actually, it's not. In "normal" exceptions by the time an exception gets to you the computation that threw it is gone.

This depends on how you model control flow. What's become more common now is to have very explicit control flow modeling so you have pseudo-edges from every place an exception can occur to the catch block (of course fewer with synchronous exceptions).

So when the exception is thrown you keep the frame on the stack, shove your IP, and go to the new handler -- like a function call. From the handler you have five potential exit points:

1) Pop stack, jmp... continue control flow from where the exception took place,if recovery succeeds.

2) Fall out the bottom if it was handled, but not "recovered".

3) Go to next recovery handler in list, if there is one.

4) Unwind.

5) New exception.

With that said, there are as many ways to implement exception handling as there EH mechanisms. Every one of mine I've done pretty differently, but in everyone of them I think could implement condition handling pretty easily.

The point I was making was more about the prospect of adding condition handling as a language user to an existing language. Basically that most language implementations make it impossible to add something like this using the tools provided by the language. I suppose at points go it was a bit of a silly one.

The difficulty in adding it to the language when modifying the language implementation is an open option is much lower.

OK, gotcha. I misunderstood. With that I agree.

>Special variables seems really like a take it or leave it idea. I'm really not convinced that keeping these as explicit arguments of a function are a bad idea. I really like the ability to reason about a function by simply knowing its arguments (including the mplicit self/this).

Haskell has an equally (arguably better) way of dealing with this but a lot of people find it a bit heavy weight.

When you compare it to OO languages, it becomes and obvious win. Any private data member of an object is an implicit/global variable to all methods of that class. If you have a stack trace in Java where one of those members seems to have an impossible value you have no way of knowing how it got there.

In Lisp this problem doesn't have to exist (ironically, I don't think class members in CLOS can be special, but I'm not certain). If you make your implicit variables special then any time that impossible value comes up and breaks the program you need only look in the stack trace. The culprit must be there because if it wasn't the bad value wouldn't be in effect.

Now, if you've ever programmed with the standard OO languages think about how much time that would have saved you.

Reply on news.ycombinator.com