On Fri, 29 Sep 2017 14:43:22 -0700, allber...@gmail.com wrote:
> So, the first problem is that you have to be aware of the special behavior
> of Failure and how it interacts with a method which is documented as
> producing Bool.
That documentation also lists the conditions when the method `fail`s.
There's no interaction with any methods involved. The method simply returns
a Failure object on failure and failures are pretty ubiquitous in the
language and especially so in IO part of it.
> The .e method behaves differently, and how I expected .f to behave!
>
> Again, there is a rational explanation: it is, logically, a different
> operation.
>From my POV, it's that here it can reliably answer a True or a False to
whether a file exists, whereas .f has three answers to give:
True the path is a file, False the path is not a file, or Failure because
the path points to nothing. The behaviour is consistent, it's just .e never
`fail`s.
> Is this a situation where we might actually want a harder kind of Failure that
> doesn't get disarmed on coercion to Bool, but does if tested with .defined?
I rather we don't invent any special cases for a small part of the language.
If harder errors need to be expressed, we should just throw an exception.
> if you decide that .f should behave like .e, do
> you do this explicitly (and for each operation), or do you arrange for it
> to be part of the signature, or do you perhaps handle any Failure return
> through a declared Bool return type by coercing it to Bool? All of these
> answers are unappealing, some moreso than others (unconditional coercion
> might actually be right in the general case, but it scares me --- and
> interacts strongly with the preceding question).
I'm not fully following all the coercion talk here. The file test methods
return a Failure object. The .Bool and .defined methods on Failures disarm
them and return False. There are no coercers involved. Also, the user has
more than one option to disarm Failures, by smartmatching against Pair
objects and having the smartmatch disarm Failures:
say "z".IO ~~ :f
False
Or just using the .so method:
"x".IO.f.so.say
False
".bashrc".IO.f.so.say
True
> I have no idea what the syntax would be [...]
> So there's actually a fair amount to think about here.
I'm probably biased since I raked through this stuff during IO Grant, but
TBH I'm failing to see any problems so far. Certainly don't see anything
that'd involve inventing new syntax or special Failure types. If a person
picked up the language an hour ago, Failures might be a new concept to them
to learn, but they're as common as regexes, so inventing something extra to
learn
just compounds the original problem instead of solving it.
