@Johan: sorry for the duplicate
* we can't implement this reliably,
If I understand correctly the current System.Environment.getProgName can make this distinction somehow. But from a quick peek at the code, I can't really tell how it's done.
* the distinction into these three groups doesn't necessarily work for all compilers, and
If a compiler does not support script/interactive, it could always return Binary, right?
* the distinction (I assume) isn't useful in most use cases
At this point I would find it useful to define use cases. When I was looking for that functionality, I wanted to find files relative to a script. For binaries I use Cabal's support for data files, but this only works for `cabal install`ed packages.
I think people who want to use this heuristic are better served by the existing executable-path package. What do you think?
I still think that a well-tested, reliable way to do that would be awesome. I'm not sure how hard it is to get it right, though. If we do not support interactive/script, then I think we should at least use a Maybe instead of `error`. Cheers, Simon