On Wed, Dec 16, 2020 at 5:10 AM Konrad Bucheli ... wrote: > there is surely a way to make sure that my Nil > explodes in my code. Is there a `use FailingNil`?
I'd +1 a `use fatal :Nil;`. ---- In the meantime, this appears to work: ``` engine.?Raptor::start ``` Might be a bug because an *unqualified* call failure is silent: ``` engine.?start ``` Perhaps it's deliberate that if you qualify you make it fail fast? But it might also be considered a bug. I haven't investigated. ---- Perhaps also a fail fast version that doesn't require a `use fatal` or qualified method but just a different method call op. And perhaps it is better than just making `foo.?bar` fail if there is no `bar` method on `Nil`. Perhaps it always fails if the invocant is `Nil` or `Failure` no matter what the method name is? So even `Nil.Str` or `Nil.FALLBACK` fail? ---- Bikeshedding syntax: ``` engine.?!start. ``` > Note that it has nothing to do with the "pyramid of doom". When you say "it", what is "it"? I get that your surprise, and your perspective that `.` doesn't do what it says it does, and the feeling of a trap, are nothing to do with the pyramid of doom. But the reason why Raku's `.` is the way it is is in large part due to the issue referred to on Wikipedia as "the pyramid of doom", and the desire to have the default method call operator avoid it, because that's in keeping with Raku's philosophy of soft failure as the general default approach, with `Nil` as a benign `Failure`. If calling a method on `Nil` immediately threw, the whole notion of `Nil` as a benign `Failure` would, well, fail. > it does not do what it tells it does. `foo.bar` does what it tells me it does: * Try to call method `bar` on `foo`. * If it fails to resolve on a non-failure, fail fast. * If it fails to resolve on a benign failure, keep it benign. If you *don't* accept that what `.` does is explicitly avoid the pyramid of doom, then that begs two questions: * What do you think the pyramid of doom is? * What about Raku's `.` fails to avoid the pyramid of doom? > Now to be "safe" (as in fail fast) I have to always... If you define "safe" as "fail fast" and reject "safe navigation" as being "safe", then fair enough. Perhaps you prefer a default in a PL of strong static typing? (I like strong static typing, and fail fast, and things like that, and hope to see folk one day create pragmas that do things like turning coercions off en masse in a lexical scope or `use fatal :Nil;`. But I also like weak dynamic typing, benign failure modes, and safe navigation by default too.) > Concerning documentation: I do not know where there is an > appropriate place to warn about this behavior. Me neither. Part of the issue with PLs is that many programmers getting to know a new PL not only tend to have expectations based on PLs they have already had experience with, but also tend to classify surprises that bite them, when that surprising thing would not occur in PLs they're used to, as something that, at least from their perspective, is a trap. And I do wonder if that's part of what's going on in this case. And, even if it is, they're still right from their perspective. In which case, in some senses, perhaps such things ought to be loudly flagged somewhere in Raku's doc in a manner that will be likely to be seen by others who share their experience. Perhaps in a section dedicated to going from some other specific PL(s) to Raku, presumably the nutshell pages. Or maybe it's reasonable to also have PL specific trap pages, distinct from the nutshell pages (even if linked from them), and perhaps precursors to them. If so, a natural person to start those would presumably be someone like yourself who experiences the trap. Or maybe things like this belong on the already existing single *general* Traps page? > There where we teach how methods are called? Surely it > would not have found me. Right. Things like that just makes this thornier. Have you read the general Traps page? If so, perhaps there. > I look up a lot in documentation, but not such trivial stuff. Right. And in a sense, it *is* trivial. The `.` operator just invokes method call semantics. And, per the sub-title of its doc page, `Nil` plays the role of being a "benign failure" which by definition means *not* failing fast, so it both eats a failed method call to sustain its benign failure nature, and also incidentally but quite usefully for those who like it, avoids the pyramid of doom by implementing so-called "Safe Navigation" by *not* failing fast. To many folk who have never used an OO PL before, but are attracted to try Raku, its safe navigation by default behaviour is presumably experienced as both a boon and a trivial thing, barely worth mentioning. Perhaps this was Larry's perspective. But what if someone makes assumptions and they turn out to be wrong? What if the assumption is about something as basic as the meaning of `.`? Where do you incorporate the potentially hundreds/thousands of things folk can assume about such supposedly tiny things, given that each person will have their own set of experiences, and their own sense of the degree to which the doc ought to have given them forewarning of some aspect that surprises them, and that it ought be not only unmissable but unmissable *on the pages that they read*? It's a tough problem, and I deeply appreciate JJ's tenacity and generally humble and workmanlike effort to address these very hard problems. And whether you decide to create a doc issue proposing to add this facet we've been discussing to the general Traps page, or to an OtherPL-to-Raku specific Traps page, or do something else, I will continue to admire @Larry's PL design skills, and especially Larry's focus on bears with very little brain, blessing us with the many nicely designed variations on things like plain old method calls already elegantly built in to Raku in such multifarious but strangely consistent ways. love, raiph
