Hacker News Reader

Comment by mehrdadn | Hacker News Reader

I know about this technique and I can pretty much never bring myself to actually do this in practice. For one thing there's pretty much always something more useful to return, and suddenly it becomes incredibly unergonomic to return an extra token and then force the user to pass it elsewhere. For another, it doesn't even automatically prevent passing the token to the wrong instance of the object either, or passing it twice, or other kinds of undesired usage. Adding dynamic checking for any of this also adds runtime overhead, and all this seems quite confusing and difficult to justify, especially for those unfamiliar. (On top of additional issues I'm probably forgetting.) Do you actually find a way to put this technique into good use in practice?

View on HN

I suppose it's less useful as a standalone technique - I've used it before but not that heavily (e.g. in a library built around sequencing effects in a certain way, where I've wanted to guarantee that one effect can't be called before another). Really we'd want a considerably more powerful type system - Idris 2's quantitative types and/or Rust's ownership, for example - before that particular technique really starts to shine.

However, the general mindset is one I use all the time. For example, if I've written a state machine that is represented explicitly in the types, I might be able to encode some of the state transitions in the type system directly, so the compiler prevents me writing certain invalid transitions. For example, if state B can only be reached after state A, I might write the in-memory representation of B to contain an in-memory representation of A; this guarantees I must have passed something through state A to get anything in state B. Doesn't save you from everything - in particular it doesn't solve your "passing the token to the wrong instance of the object" problem - but any constraint on the state space is useful in my book. When the state machine gets sufficiently large, in my experience, the benefits of the restricted state space start outweighing the negatives of manual token shuffling.

(I have a blog post brewing about this general class of techniques, but I don't know when it'll be ready.)

Couldn't you return a tuple with the object and the useful return value though?

Sure - that's not the difficult part, in my book. (I use F#, where there's tuple destructuring syntax, so it's easy.) The hard parts are about making sure you can't reuse the token in the wrong context.

Oooh. Yeah, that makes sense.

I sadly don't know enough F# to even begin to think of something to make the tokens context safe.

For what it's worth, I don't think it's possible in F# (perhaps modulo absurd tricks that will never go into prod code, like type-level naturals).

With explicit enforced lifetimes it's harder to misuse. The first method returns the tuple of (Something, Token) and the second method consumes/takes ownership of the Token plus whatever its arguments. This way each call to function2 has to be preceded by a call to function1 and it's checked by the compiler.

It's reasonably easier when a method can transparently change the type, for example in Common Lisp - where the object system provides a clear controlled way to change the class of an object (using apropriately called method change-class)

Reply on news.ycombinator.com