On Sun, 01 Jan 2017 10:48:07 -0800, comdog wrote: > > That's because there's not a single mention of it in the 6.c Perl 6 > > Language Specification[^1] and we don't document unspecced things. > > That's contrary to my experience. For instance, > https://rt.perl.org/Ticket/Display.html?id=130419 , along with many > other things I've found.
That's because many things were documented prior to our installment of that policy and have been simply missed. I strongly recommend you join our IRC channel[1] and ask questions if you're unsure if something is supposed to be documented/specced/implemented. > Since the spec is basically a test in roast, that's an easy technical > fix. Well, it's true, it's very easy to lock us into supporting the current API and behaviour by writing a simple test. I see support from users for having the `indir` routine, so I doubt any change would involve removing it from current codebase. However, its API and behaviour are quite non-ideal, which is why I commented on your article saying that just documenting and testing the current API isn't what we want. > Is there a roadmap or other notes that pull together the direction for > future work, what's in or out, what's off limits, and such. Nothing I have in writing yet, as I set off on this quest to improve IO when I went to fix your `chdir` ticket and saw the horrors of the current code. You're asking because you want to include it in your book, yes? Because in that case I can narrow down potential changes: 1) We'll still have `indir` (so adding spectests today just for basic functionality, like we have for `chdir` is OK, I think) 2) It'll likely `fail` instead of `throw`ing as it does now 3) There's currently a race condition in it that makes it perform things in the wrong directory; unsure how/whether fixing it would affect the API 4) The topic of this ticket: its default set of tests for the directory will change (just test if it's a directory?) 5) It most definitely won't be taking the `:$test` parameter as some predefined string as it's bug prone and isn't consistent with the way we pass arguments around elsewhere. Most likely it'd be just adverbs, like we have on, say, .match. So instead of passing :test<r d x> (ensuring you get them in right order!), you'd pass the tests you want as :r, :w, :x adverbs. As for roadmap, first I plan to make a "map" of all of our core routines to find out what calling convention is most common and what's the typical way to indicate failure. That will guide the decision for the calling form and failure mode for the `indir` and related IO routines. In the past year, any time something awful about IO was brought up, the `newio` branch was mentioned as being one where the awfulness was fixed. It's a branch that was made prior to first Christmas release, but never got merged. So the next step on the roadmap would be to examine the changes[^2] that branch would've made were it merged before Christmas release and see what we can/want to have in current code, to improve our IO. Not every change will be possible, because we can't break existing spectests, and that's precisely the reason why spectests for current API of indir should not be added. [1] https://webchat.freenode.net/?channels=#perl6 [2] https://github.com/rakudo/rakudo/compare/6bbb56f4c598ba0fef49ba9b11671df675019366...newio Cheers, ZZ
