New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
file tests and Failure do not interact as expected #6559
Comments
From @geekosaurThis turns out to be fairly complex, and has implications that may go well The original problem is that a fairly obvious (from shells or perl 5 or pyanfar Z$ 6 '".profileX".IO.f.say' Failed to find '/home/allbery/.profileX' while trying to do '.f' Naïvely, I expect this to output False, not throw. The reason for this is fairly obvious: if I use it in a Bool context then pyanfar Z$ 6 'say ?".profileX".IO.f' So, the first problem is that you have to be aware of the special behavior If it stopped there, this might not even be worth a bug report except pyanfar Z$ 6 '".profileX".IO.e.say' The .e method behaves differently, and how I expected .f to behave! Again, there is a rational explanation: it is, logically, a different Perl 5 had a variant of this, and "leaked" a hint of it with its magic Things get deeper yet, though. Which kinds of failures of stat() result in If you go back and look at the difference between .e and .f, you also get Making the return type of the file tests a coercion type to express the So there's actually a fair amount to think about here. And, depending on -- |
From @zoffixznetOn Fri, 29 Sep 2017 14:43:22 -0700, allbery.b@gmail.com wrote:
That documentation also lists the conditions when the method `fail`s.
From my POV, it's that here it can reliably answer a True or a False to
I rather we don't invent any special cases for a small part of the language.
I'm not fully following all the coercion talk here. The file test methods say "z".IO ~~ :f Or just using the .so method: "x".IO.f.so.say
I'm probably biased since I raked through this stuff during IO Grant, but |
The RT System itself - Status changed from 'new' to 'open' |
From @smlsI agree with Zoffix that this seems to be fine as is. Generally speaking, IO operations that logically require an existing path will return a Failure if the path does not in fact exist: Slurp its content? Failure. Whereas `.e`, i.e. checking if a path exists, is by necessity *not* an operation that assumes an existing path. The only thing that might be debatable, is whether `.f` should mean: a) Check if it is of type "file". b) Check if it exists, and if so, if is of type "file". The current behavior (a) seems more natural and useful to me though. Perl 5 does (a) as well, in the sense that it too distinguishes "failure" from "no" in the return value: - "yes, it is of type 'file'": a defined truthy value Perl 6 merely improves on that by promoting the failure condition from `undef` to `Failure`, which both carries more information and provides more safety by default. To the extent that you're basing your expectations on the fact that a Perl 5 `undef` can be used in ways that a Perl 6 `Failure` cannot (without blowing up), well, that's just a matter of having to unlearn Perl 5 (or other programming languages) while learning Perl 6... :) |
From @geekosaurOn Sat, Sep 30, 2017 at 4:35 PM, Sam S. via RT <perl6-bugs-followup@perl.org
So I included at least one discussion in the ticket that was utterly -- |
From @smlsOn Sat, 30 Sep 2017 13:47:22 -0700, allbery.b@gmail.com wrote:
You mean the part about exposing different stat() error conditions? A `Failure` wraps a typed exception, which you can get at by calling the `.exception` method on it: my $is-file = do given $path.f -> $result { (...or by letting it throw and then using a CATCH block.) Exceptions also have type-specific attributes which can hold further details to differentiate similar but different error conditions. If file tests should be made to expose more fine-grained error states (probably a good idea), they can use those two mechanisms without the need to change anything about Failure or add new syntax. PS: At the end of the day, "only half-exposing the underlying mechanism" of low-level operating-system APIs is to be expected though, for a high-level language that wants to be cross-platform and user-friendly. Getting full access to specific operating-system APIs is what third-party modules such as [1] are for. Thankfully, Perl 6's NativeCall interface makes them relatively easy to write. |
Migrated from rt.perl.org#132185 (status was 'open')
Searchable as RT132185$
The text was updated successfully, but these errors were encountered: