On Tue, Jun 19, 2012 at 9:30 AM, Simon Hengel <sol@typeful.net> wrote:
> * 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`.