Re: Missing NullPointerException
no propeller > > spinning. So I checked start() in and out, because that is where the > > problem is obviously. > > But it was not, it was in engine(). > > And I want my programming language/runtime to tell me if I am doing > > obviously stupid things. > > Note that it has nothing to do with the "pyramid of doom". It would > > make sense in a pure functional environment, but Raku is > > multi-paradigm, no? > > > > Now to be "safe" (as in fail fast) I have to always > > > > say "launching drone"; > > # this intermediate variable is important defensive programming, > > else it will not explode on Nil if there are stupid errors in > engine() > > my $engine = $drone.engine; > > $engine.start; > > say "engine started"; > > > > which is the opposite of concise. > > > > But Raku is Raku, there is surely a way to make sure that my Nil > > explodes in my code. Is there a `use FailingNil`? > > > > Concerning documentation: I do not know where there is an > > appropriate place to warn about this behavior. There where we teach > > how methods are called? Surely it would not have found me. I look up > > a lot in documentation, but not such trivial stuff. > > > > Cheers > > > > Konrad > > > > From: Ralph Mellor > <mailto:ralphdjmel...@gmail.com>> > > Sent: Saturday, 5 December 2020 15:58 > > To: Konrad Bucheli > <mailto:kbuch...@open-systems.com>> > > Cc: perl6-users mailto:perl6-users@perl.org>> > > Subject: Re: Missing NullPointerException > > > > On Thu, Dec 3, 2020 at 10:20 PM Konrad Bucheli via perl6-users > > mailto:perl6-users@perl.org>> wrote: > > > > > > What is actually the rationale for such a behaviour? > > > > Ergonomically sound null safety. > > > > First, consider what other languages have. Quoting > > https://en.wikipedia.org/wiki/Safe_navigation_operator > > <https://en.wikipedia.org/wiki/Safe_navigation_operator>: > > > > > In object-oriented programming, the safe navigation operator > > > ... is used to avoid sequential explicit null checks ... > > ... > > > In programming languages where the navigation operator > > > (e.g. ".") leads to an error if applied to a null object, the safe > > > navigation operator stops the evaluation of a method/field > > > chain and returns null as the value of the chain expression. > > ... > > > It is currently supported in languages such as Apex, Groovy, > > > Swift, Ruby, C#, Kotlin, CoffeeScript, Scala, Dart and others. > > ... > > > The main advantage of using this operator is that it avoids the > > > pyramid of doom. ... > > > > Many aspects of Raku's design are better solutions than are found > > in older PLs like those listed above. This is an example. Instead of > > devs having unsafe operations by default, and having to write `?.` > > to get safety, in Raku one just writes `.` and always gets safety. > > > > > For me it was an unexpected trap > > > > This statement couples deep wisdom (the "for me" qualification,, > > deferring it till after you'd first asked about what the rationale > was, > > and sharing your experience) with a Canby.[1] > > > > It's clear that you were missing some knowledge, and that it > > bit you, and are now exploring how best to learn from that. > > > > I accept without reservation the claim it was "unexpected". (That > > is the sort of thing that is typically experienced and reported by > > request of our right hemispheres, and it is generally reliable.) > > > > I also recognize what I imagine as a negative effect associated > > with classifying this experience / situation as a "trap", and the > > negative affect associated with applying that classification, which > > is to say your right hemisphere's experience of that classification. > > > > With that said, I now wish to engage our respective unreliable > > left hemispheres, the ones that drive classification, and wish to > > suggest another way to view this situation. > > > > I would argue that you are classifying safe navigation as a trap, > > and thus likely experiencing it ne
Re: Missing NullPointerException
On 16.12.20 12:39, Brad Gilbert wrote:
with $drone.engine {
.start;
say "engine started";
}
Now we get the inverse pyramid of doom. Above code does not the same as
mine, it only improves the debugging output, but does not fail:
with $drone.engine {
.start;
say "engine started";
}
orelse {
die "looks like we lost the engine";
}
My point is that I never expected the engine to be lost, because it is
an integral part of the drone. And that is correct because it was only a
bug in `engine` which was revealed during testing and when fixed I do
not need all this any more.
So to understand all the implications of
$drone.engine.start;
I need in depth Raku understanding. Is that already tribal knowledge?.
Or you have already been hurt by it as I was. It is definitively not
beginner friendly and not even intermediate friendly.
I feel uncomfortable with that. Whenever I see something like this I
have to be aware that the normally obvious assumptions are incorrect.
These bugs are more difficult to find because the program continues and
only later on you will see that some data or state is incorrect. And the
problem with incorrect data is that you might not even spot it.
On Tue, Dec 15, 2020, 11:10 PM Konrad Bucheli via perl6-users
mailto:perl6-users@perl.org>> wrote:
Hi Ralph
Thanks a lot for the extensive answer.
I still consider it a trap because it does not do what it tells it does.
If I have:
say "launching drone";
$drone.engine.start;
say "engine started";
After I run the above I got both messages, but no propeller
spinning. So I checked start() in and out, because that is where the
problem is obviously.
But it was not, it was in engine().
And I want my programming language/runtime to tell me if I am doing
obviously stupid things.
Note that it has nothing to do with the "pyramid of doom". It would
make sense in a pure functional environment, but Raku is
multi-paradigm, no?
Now to be "safe" (as in fail fast) I have to always
say "launching drone";
# this intermediate variable is important defensive programming,
else it will not explode on Nil if there are stupid errors in engine()
my $engine = $drone.engine;
$engine.start;
say "engine started";
which is the opposite of concise.
But Raku is Raku, there is surely a way to make sure that my Nil
explodes in my code. Is there a `use FailingNil`?
Concerning documentation: I do not know where there is an
appropriate place to warn about this behavior. There where we teach
how methods are called? Surely it would not have found me. I look up
a lot in documentation, but not such trivial stuff.
Cheers
Konrad
From: Ralph Mellor mailto:ralphdjmel...@gmail.com>>
Sent: Saturday, 5 December 2020 15:58
To: Konrad Bucheli mailto:kbuch...@open-systems.com>>
Cc: perl6-users mailto:perl6-users@perl.org>>
Subject: Re: Missing NullPointerException
On Thu, Dec 3, 2020 at 10:20 PM Konrad Bucheli via perl6-users
mailto:perl6-users@perl.org>> wrote:
>
> What is actually the rationale for such a behaviour?
Ergonomically sound null safety.
First, consider what other languages have. Quoting
https://en.wikipedia.org/wiki/Safe_navigation_operator
<https://en.wikipedia.org/wiki/Safe_navigation_operator>:
> In object-oriented programming, the safe navigation operator
> ... is used to avoid sequential explicit null checks ...
...
> In programming languages where the navigation operator
> (e.g. ".") leads to an error if applied to a null object, the safe
> navigation operator stops the evaluation of a method/field
> chain and returns null as the value of the chain expression.
...
> It is currently supported in languages such as Apex, Groovy,
> Swift, Ruby, C#, Kotlin, CoffeeScript, Scala, Dart and others.
...
> The main advantage of using this operator is that it avoids the
> pyramid of doom. ...
Many aspects of Raku's design are better solutions than are found
in older PLs like those listed above. This is an example. Instead of
devs having unsafe operations by default, and having to write `?.`
to get safety, in Raku one just writes `.` and always gets safety.
> For me it was an unexpected trap
This statement couples deep wisdom (the "for me" qualification,,
deferring it till after you'd first asked about what the rationale was,
and sharing your experience) with a Canby.[1]
It's clear that you were missing some knowledge, and that it
bit you, and are now exploring how best to learn from that.
I accept
Re: Missing NullPointerException
Hi Ralph I understand that this is about avoiding the pyramid of doom. And it is enjoyable that it can be avoided. Opt in. No programming language I worked so far has this semantics of method call. So we might name it differently as it is doing something different... -> that is the trap. (I am aware that it is not different, it is only the Nil class which makes it look different) But now I cannot even opt out without creating an "inverse pyramid of doom". It is "optimized" for one common use case (navigation) but makes another common use case (creating side effects) unexpectedly and surprisingly harder. IMHO this medicine is worse than the illness. I consider a safe navigation operator would be a more balanced. In my case it would would probably have helped if return; would return a Failure, not Nil. Maybe we need a warning on top of the Nil documentation: you might be better off with a Failure... Cheers Konrad On 17.12.20 23:07, Ralph Mellor wrote: 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
Re: Missing NullPointerException
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
Re: Missing NullPointerException
with $drone.engine {
.start;
say "engine started";
}
On Tue, Dec 15, 2020, 11:10 PM Konrad Bucheli via perl6-users <
perl6-users@perl.org> wrote:
>
> Hi Ralph
>
> Thanks a lot for the extensive answer.
>
> I still consider it a trap because it does not do what it tells it does.
>
> If I have:
>
> say "launching drone";
> $drone.engine.start;
> say "engine started";
>
> After I run the above I got both messages, but no propeller spinning. So I
> checked start() in and out, because that is where the problem is obviously.
> But it was not, it was in engine().
> And I want my programming language/runtime to tell me if I am doing
> obviously stupid things.
> Note that it has nothing to do with the "pyramid of doom". It would make
> sense in a pure functional environment, but Raku is multi-paradigm, no?
>
> Now to be "safe" (as in fail fast) I have to always
>
> say "launching drone";
> # this intermediate variable is important defensive programming, else it
> will not explode on Nil if there are stupid errors in engine()
> my $engine = $drone.engine;
> $engine.start;
> say "engine started";
>
> which is the opposite of concise.
>
> But Raku is Raku, there is surely a way to make sure that my Nil explodes
> in my code. Is there a `use FailingNil`?
>
> Concerning documentation: I do not know where there is an appropriate
> place to warn about this behavior. There where we teach how methods are
> called? Surely it would not have found me. I look up a lot in
> documentation, but not such trivial stuff.
>
> Cheers
>
> Konrad
>
> From: Ralph Mellor
> Sent: Saturday, 5 December 2020 15:58
> To: Konrad Bucheli
> Cc: perl6-users
> Subject: Re: Missing NullPointerException
>
> On Thu, Dec 3, 2020 at 10:20 PM Konrad Bucheli via perl6-users
> wrote:
> >
> > What is actually the rationale for such a behaviour?
>
> Ergonomically sound null safety.
>
> First, consider what other languages have. Quoting
> https://en.wikipedia.org/wiki/Safe_navigation_operator:
>
> > In object-oriented programming, the safe navigation operator
> > ... is used to avoid sequential explicit null checks ...
> ...
> > In programming languages where the navigation operator
> > (e.g. ".") leads to an error if applied to a null object, the safe
> > navigation operator stops the evaluation of a method/field
> > chain and returns null as the value of the chain expression.
> ...
> > It is currently supported in languages such as Apex, Groovy,
> > Swift, Ruby, C#, Kotlin, CoffeeScript, Scala, Dart and others.
> ...
> > The main advantage of using this operator is that it avoids the
> > pyramid of doom. ...
>
> Many aspects of Raku's design are better solutions than are found
> in older PLs like those listed above. This is an example. Instead of
> devs having unsafe operations by default, and having to write `?.`
> to get safety, in Raku one just writes `.` and always gets safety.
>
> > For me it was an unexpected trap
>
> This statement couples deep wisdom (the "for me" qualification,,
> deferring it till after you'd first asked about what the rationale was,
> and sharing your experience) with a Canby.[1]
>
> It's clear that you were missing some knowledge, and that it
> bit you, and are now exploring how best to learn from that.
>
> I accept without reservation the claim it was "unexpected". (That
> is the sort of thing that is typically experienced and reported by
> request of our right hemispheres, and it is generally reliable.)
>
> I also recognize what I imagine as a negative effect associated
> with classifying this experience / situation as a "trap", and the
> negative affect associated with applying that classification, which
> is to say your right hemisphere's experience of that classification.
>
> With that said, I now wish to engage our respective unreliable
> left hemispheres, the ones that drive classification, and wish to
> suggest another way to view this situation.
>
> I would argue that you are classifying safe navigation as a trap,
> and thus likely experiencing it negatively. Perhaps for you this
> can/will instead become a gift (perhaps also unexpected)?
>
> A fundamental part of human experience is interpreting one's
> reactions to things in the light of further knowledge and/or
> experience. Larry has made it clear to me that this is one of
> the keys to his approach to life, and to PL design, in both the
> sense of how he approaches a PL's design and how the PL's
> designed features reward those who think the same way. (I
&g
Re: Missing NullPointerException
Hi Ralph Thanks a lot for the extensive answer. I still consider it a trap because it does not do what it tells it does. If I have: say "launching drone"; $drone.engine.start; say "engine started"; After I run the above I got both messages, but no propeller spinning. So I checked start() in and out, because that is where the problem is obviously. But it was not, it was in engine(). And I want my programming language/runtime to tell me if I am doing obviously stupid things. Note that it has nothing to do with the "pyramid of doom". It would make sense in a pure functional environment, but Raku is multi-paradigm, no? Now to be "safe" (as in fail fast) I have to always say "launching drone"; # this intermediate variable is important defensive programming, else it will not explode on Nil if there are stupid errors in engine() my $engine = $drone.engine; $engine.start; say "engine started"; which is the opposite of concise. But Raku is Raku, there is surely a way to make sure that my Nil explodes in my code. Is there a `use FailingNil`? Concerning documentation: I do not know where there is an appropriate place to warn about this behavior. There where we teach how methods are called? Surely it would not have found me. I look up a lot in documentation, but not such trivial stuff. Cheers Konrad From: Ralph Mellor Sent: Saturday, 5 December 2020 15:58 To: Konrad Bucheli Cc: perl6-users Subject: Re: Missing NullPointerException On Thu, Dec 3, 2020 at 10:20 PM Konrad Bucheli via perl6-users wrote: > > What is actually the rationale for such a behaviour? Ergonomically sound null safety. First, consider what other languages have. Quoting https://en.wikipedia.org/wiki/Safe_navigation_operator: > In object-oriented programming, the safe navigation operator > ... is used to avoid sequential explicit null checks ... ... > In programming languages where the navigation operator > (e.g. ".") leads to an error if applied to a null object, the safe > navigation operator stops the evaluation of a method/field > chain and returns null as the value of the chain expression. ... > It is currently supported in languages such as Apex, Groovy, > Swift, Ruby, C#, Kotlin, CoffeeScript, Scala, Dart and others. ... > The main advantage of using this operator is that it avoids the > pyramid of doom. ... Many aspects of Raku's design are better solutions than are found in older PLs like those listed above. This is an example. Instead of devs having unsafe operations by default, and having to write `?.` to get safety, in Raku one just writes `.` and always gets safety. > For me it was an unexpected trap This statement couples deep wisdom (the "for me" qualification,, deferring it till after you'd first asked about what the rationale was, and sharing your experience) with a Canby.[1] It's clear that you were missing some knowledge, and that it bit you, and are now exploring how best to learn from that. I accept without reservation the claim it was "unexpected". (That is the sort of thing that is typically experienced and reported by request of our right hemispheres, and it is generally reliable.) I also recognize what I imagine as a negative effect associated with classifying this experience / situation as a "trap", and the negative affect associated with applying that classification, which is to say your right hemisphere's experience of that classification. With that said, I now wish to engage our respective unreliable left hemispheres, the ones that drive classification, and wish to suggest another way to view this situation. I would argue that you are classifying safe navigation as a trap, and thus likely experiencing it negatively. Perhaps for you this can/will instead become a gift (perhaps also unexpected)? A fundamental part of human experience is interpreting one's reactions to things in the light of further knowledge and/or experience. Larry has made it clear to me that this is one of the keys to his approach to life, and to PL design, in both the sense of how he approaches a PL's design and how the PL's designed features reward those who think the same way. (I have found this endlessly inspiring.) Applying that to your experience, you could alternately view what happened as a surprise that arises from Raku's default of safety, which is about freedom (avoiding both the extensive boilerplate of the pyramid of doom, and the modern shorter but still boilerplate additional ?), and not, it could reasonably be argued, about a trap. cf my discussion of what Vadim Belman had classified as a WAT in https://www.nntp.perl.org/group/perl.perl6.users/2018/09/msg5418.html > It all went fine only the side effect was not there. I then figured > out after some time that one of methods returned Nil and > somehow silently it did not do what I expected. T
Re: Missing NullPointerException
The returned Nil aka bug was from my side. But when debugging it took me a while to find the culprit because when the statement with the chained methods was executed I expected all of them being executed... So that was a bit of a surprise. Thanks for the insights! On 03.12.20 23:25, Elizabeth Mattijsen wrote: Nil is really a Failure that doesn't throw. It indicates the absence of a value where there is one expected. That is why Nil doesn't throw. If you want to indicate a soft failure, you should use fail(). If the chain of methods you mention are core methods, and one of them is returning Nil, then perhaps we have a bug. Could you elaborate on the situation where you encountered this? On 3 Dec 2020, at 15:22, Konrad Bucheli via perl6-users wrote: On 02.12.20 15:55, Ralph Mellor wrote: On Wed, Dec 2, 2020 at 7:08 AM Patrick R. Michaud wrote: Nil.any_non_existent method always seems to return Nil. I'm not sure where this is documented It's near the top of the `Nil` doc page you linked: Any method call on `Nil` of a method that does not exist ... will succeed and return `Nil`. OK, that is intentional and documented then. What is actually the rationale for such a behaviour? For me it was an unexpected trap as I had a chain of methods which should do some side effect. It all went fine only the side effect was not there. I then figured out after some time that one of methods returned Nil and somehow silently it did not do what I expected. Thanks Konrad -- Konrad Bucheli Systems Engineering Fellow O. +41 58 100 10 10 W. open-systems.com Open Systems smime.p7s Description: S/MIME Cryptographic Signature
Re: Missing NullPointerException
On Thu, Dec 3, 2020 at 10:20 PM Konrad Bucheli via perl6-users wrote: > > What is actually the rationale for such a behaviour? Ergonomically sound null safety. First, consider what other languages have. Quoting https://en.wikipedia.org/wiki/Safe_navigation_operator: > In object-oriented programming, the safe navigation operator > ... is used to avoid sequential explicit null checks ... ... > In programming languages where the navigation operator > (e.g. ".") leads to an error if applied to a null object, the safe > navigation operator stops the evaluation of a method/field > chain and returns null as the value of the chain expression. ... > It is currently supported in languages such as Apex, Groovy, > Swift, Ruby, C#, Kotlin, CoffeeScript, Scala, Dart and others. ... > The main advantage of using this operator is that it avoids the > pyramid of doom. ... Many aspects of Raku's design are better solutions than are found in older PLs like those listed above. This is an example. Instead of devs having unsafe operations by default, and having to write `?.` to get safety, in Raku one just writes `.` and always gets safety. > For me it was an unexpected trap This statement couples deep wisdom (the "for me" qualification,, deferring it till after you'd first asked about what the rationale was, and sharing your experience) with a Canby.[1] It's clear that you were missing some knowledge, and that it bit you, and are now exploring how best to learn from that. I accept without reservation the claim it was "unexpected". (That is the sort of thing that is typically experienced and reported by request of our right hemispheres, and it is generally reliable.) I also recognize what I imagine as a negative effect associated with classifying this experience / situation as a "trap", and the negative affect associated with applying that classification, which is to say your right hemisphere's experience of that classification. With that said, I now wish to engage our respective unreliable left hemispheres, the ones that drive classification, and wish to suggest another way to view this situation. I would argue that you are classifying safe navigation as a trap, and thus likely experiencing it negatively. Perhaps for you this can/will instead become a gift (perhaps also unexpected)? A fundamental part of human experience is interpreting one's reactions to things in the light of further knowledge and/or experience. Larry has made it clear to me that this is one of the keys to his approach to life, and to PL design, in both the sense of how he approaches a PL's design and how the PL's designed features reward those who think the same way. (I have found this endlessly inspiring.) Applying that to your experience, you could alternately view what happened as a surprise that arises from Raku's default of safety, which is about freedom (avoiding both the extensive boilerplate of the pyramid of doom, and the modern shorter but still boilerplate additional ?), and not, it could reasonably be argued, about a trap. cf my discussion of what Vadim Belman had classified as a WAT in https://www.nntp.perl.org/group/perl.perl6.users/2018/09/msg5418.html > It all went fine only the side effect was not there. I then figured > out after some time that one of methods returned Nil and > somehow silently it did not do what I expected. The "somehow" was automatic safe navigation, By definition, this is silent as far as it goes. But if you think about it, it wasn't *entirely* silent. You knew *something* wasn't working right, because somewhere you expected a value and didn't get one. So you then had to go chase that down. This is another pervasive principle in Larry's design approach. If a PL tries too hard to avoid programming errors, it becomes a police state. If it ignores the potential for programming errors it forgets to introduce things like safe navigation by default. The sweetspot is a balance between trade offs that overall lets devs reasonably easily "get" working code (in both the sense of arriving at it when writing, and comprehending it when reading), and keep making progress in the event of things not working out as expected. I see signs that Raku gets that right a lot of the time for me, and for others I see using and discussing it, and that the culture is generally agreeably open to figuring out whether any given negative experiences are best left as something for individual involved devs to adapt to, or as necessitating improvements in the doc, or Raku, or Rakudo, or modules etc And at the foundation of it all, is our open minded but also mindful right hemispheres, which it's clear we all share. Which leads me to a concluding question. Given your own reflections on the rationale I have described, and perhaps the wisdom that comes when we "sleep on it", is your conclusion that it would be best if there were some change in the doc, or Raku, or Rakudo, etc., or does it make enough sense now that it was, in the
Re: Missing NullPointerException
Nil is really a Failure that doesn't throw. It indicates the absence of a value where there is one expected. That is why Nil doesn't throw. If you want to indicate a soft failure, you should use fail(). If the chain of methods you mention are core methods, and one of them is returning Nil, then perhaps we have a bug. Could you elaborate on the situation where you encountered this? > On 3 Dec 2020, at 15:22, Konrad Bucheli via perl6-users > wrote: > > > > On 02.12.20 15:55, Ralph Mellor wrote: >> On Wed, Dec 2, 2020 at 7:08 AM Patrick R. Michaud wrote: >>> Nil.any_non_existent method always seems to return Nil. I'm not sure where >>> this is documented >> It's near the top of the `Nil` doc page you linked: >>> Any method call on `Nil` of a method that does not exist ... will succeed >>> and return `Nil`. > > > OK, that is intentional and documented then. What is actually the rationale > for such a behaviour? > > For me it was an unexpected trap as I had a chain of methods which should do > some side effect. It all went fine only the side effect was not there. I then > figured out after some time that one of methods returned Nil and somehow > silently it did not do what I expected. > > Thanks > > Konrad >
Re: Missing NullPointerException
On 02/12/2020 17:18, William Michels via perl6-users wrote: Does this explain why calling "dd" in the REPL returns Nil on the final line, but Nil doesn't seem to be returned on the final line when using "dd" from the Bash shell? user@mbook:~$ raku -e 'dd "0123456789";' "0123456789" user@mbook:~$ raku Welcome to 퐑퐚퐤퐮퐝퐨™ v2020.10. Implementing the 퐑퐚퐤퐮™ programming language v6.d. Built on MoarVM version 2020.10. You may want to `zef install Readline` or `zef install Linenoise` or use rlwrap for a line editor To exit type 'exit' or '^D' > dd "0123456789" "0123456789" Nil > This difference is just from the REPL printing out the return value of each line, which doesn't happen in script files or with the -e flag
Re: Missing NullPointerException
On Wed, Dec 2, 2020 at 6:56 AM Ralph Mellor wrote: > On Wed, Dec 2, 2020 at 7:08 AM Patrick R. Michaud > wrote: > > Nil.any_non_existent method always seems to return Nil. I'm not sure > where this is documented > > It's near the top of the `Nil` doc page you linked: > > > Any method call on `Nil` of a method that does not exist ... will > succeed and return `Nil`. > Does this explain why calling "dd" in the REPL returns Nil on the final line, but Nil doesn't seem to be returned on the final line when using "dd" from the Bash shell? user@mbook:~$ raku -e 'dd "0123456789";' "0123456789" user@mbook:~$ raku Welcome to 퐑퐚퐤퐮퐝퐨™ v2020.10. Implementing the 퐑퐚퐤퐮™ programming language v6.d. Built on MoarVM version 2020.10. You may want to `zef install Readline` or `zef install Linenoise` or use rlwrap for a line editor To exit type 'exit' or '^D' > dd "0123456789" "0123456789" Nil >
Re: Missing NullPointerException
On Wed, Dec 2, 2020 at 7:08 AM Patrick R. Michaud wrote: > Nil.any_non_existent method always seems to return Nil. I'm not sure where > this is documented It's near the top of the `Nil` doc page you linked: > Any method call on `Nil` of a method that does not exist ... will succeed and > return `Nil`.
