Re: .contains code?
On 12/18/20 9:16 PM, ToddAndMargo via perl6-users wrote:
Hi All,
Can anyone point me to the class declaration for contains:
https://docs.raku.org/routine/contains
I am looking for something like:
class {
method contains...
Many thanks,
-T
Kevin answered me off list. The code is
https://github.com/rakudo/rakudo/blob/master/src/core.c/Str.pm6
Line 320
:-)
Thank you Kevin!
-T
.contains code?
Hi All,
Can anyone point me to the class declaration for contains:
https://docs.raku.org/routine/contains
I am looking for something like:
class {
method contains...
Many thanks,
-T
Re: How do I address individual elements inside an object
On 12/18/20 9:42 AM, William Michels via perl6-users wrote: Hi Laurent, I get: Fruitstand in Fruit<140431957910656>.location has Fruit<140431957910656>.apples apples. [Rakudo v2020.10] Best, Bill. Hi Bill, From my notes in progress: -T *** addressing values inside and object *** Reading: say $FruitStand.apples 400 $FruitStand.apples.say 400 print $FruitStand.location ~ " has " ~ $FruitStand.apples ~" apples in stock\n"; Cucamonga has 400 apples in stock Note: an "oops!". Separate the variables from the string, or else: say "$FruitStand.location has $FruitStand.apples apples in stock"; Fruit<79300336>.location has Fruit<79300336>.apples apples in stock Writing (must be declared as "rw"):
The SF Perl Raku Study Group, 12/20 at 1pm PDT
"The mysterious insights that people have when speaking, listening, creating, and even when they are programming, are still beyond the reach of science; nearly everything we do is still an art." -- Donald Knuth, "Computer programming as an art", CACM, December 1974 The Raku Study Group December 20th, 2020 1pm in California, 9pm in the UK Zoom meeting link: https://us02web.zoom.us/j/85948371786?pwd=b3NvTXdnMnR2aW9pZ0lhdEQzZFg5QT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/San-Francisco-Perl/events/275255269/
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
:
> 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
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: How do I address individual elements inside an object
Hi Laurent, I get:
Fruitstand in Fruit<140431957910656>.location has
Fruit<140431957910656>.apples apples.
[Rakudo v2020.10]
Best, Bill.
On Fri, Dec 18, 2020 at 5:29 AM Laurent Rosenfeld via perl6-users <
perl6-users@perl.org> wrote:
> Hi Todd,
>
> 1. Yes, a class is a blueprint for manufacturing objects, you can
> construct as many object as you want.
>
> 2. As an example, you can try:
>
> say " Fruitstand in $FruitStand.location has $FruitStand.apples apples.";
>
> 2. As you declared your class the object attributes will not be mutable.
> But if you had declared the apple attribute like so in the class:
>
> has UInt $.apples is rw;
>
> then you could write:
>
> $FruitStand.apples += 42;
>
> Cheers,
> Laurent.
>
> Le ven. 18 déc. 2020 à 08:12, ToddAndMargo via perl6-users <
> perl6-users@perl.org> a écrit :
>
>> Hi All,
>>
>> class Fruit {
>> has Str $.location;
>> has UInt $.apples;
>> has UInt $.oranges;
>> has UInt $.bananas;
>> }
>>
>> my $FruitStand = Fruit.new( location => "Cucamonga",
>> apples => 400,
>> oranges => 200,
>> bananas => 50 );
>>
>> 1) am I correct that I can make as many objects as I
>> want out of a particular class?
>>
>> 2 ) what is the syntax to read an element inside an
>> object?
>>
>> 3) what is the syntax to write to an element inside an
>> object?
>>
>> I am confused, again.
>>
>> -T
>>
>
Re: How do I address individual elements inside an object
Although it's a standard term, "class" has a misleading connotation of "set".
Using the "fruit" example, the class Fruit should indicate a set of
relevant properties for a fruit, such as name, colour, taste, size,
possibly cost/kilo. Individual variables can be defined as Fruit-type
objects. Then $apple might be declared with Fruit.new as "apple",
"red", "sweet", 100g, 3.00. The class has methods to do things with
the values, such as return the colour. say $apple.colour would then
output "red", while $banana (another Fruit) in $banana.colour would
output "green". ($banana.ripen would be a method defined in the class
to change "green" to "yellow" and "yellow" to "brown".
On 12/18/20, Laurent Rosenfeld via perl6-users wrote:
> Hi Todd,
>
> 1. Yes, a class is a blueprint for manufacturing objects, you can construct
> as many object as you want.
>
> 2. As an example, you can try:
>
> say " Fruitstand in $FruitStand.location has $FruitStand.apples apples.";
>
> 2. As you declared your class the object attributes will not be mutable.
> But if you had declared the apple attribute like so in the class:
>
> has UInt $.apples is rw;
>
> then you could write:
>
> $FruitStand.apples += 42;
>
> Cheers,
> Laurent.
>
> Le ven. 18 déc. 2020 à 08:12, ToddAndMargo via perl6-users <
> perl6-users@perl.org> a écrit :
>
>> Hi All,
>>
>> class Fruit {
>> has Str $.location;
>> has UInt $.apples;
>> has UInt $.oranges;
>> has UInt $.bananas;
>> }
>>
>> my $FruitStand = Fruit.new( location => "Cucamonga",
>> apples => 400,
>> oranges => 200,
>> bananas => 50 );
>>
>> 1) am I correct that I can make as many objects as I
>> want out of a particular class?
>>
>> 2 ) what is the syntax to read an element inside an
>> object?
>>
>> 3) what is the syntax to write to an element inside an
>> object?
>>
>> I am confused, again.
>>
>> -T
>>
>
Re: How do I address individual elements inside an object
Hi Todd,
1. Yes, a class is a blueprint for manufacturing objects, you can construct
as many object as you want.
2. As an example, you can try:
say " Fruitstand in $FruitStand.location has $FruitStand.apples apples.";
2. As you declared your class the object attributes will not be mutable.
But if you had declared the apple attribute like so in the class:
has UInt $.apples is rw;
then you could write:
$FruitStand.apples += 42;
Cheers,
Laurent.
Le ven. 18 déc. 2020 à 08:12, ToddAndMargo via perl6-users <
perl6-users@perl.org> a écrit :
> Hi All,
>
> class Fruit {
> has Str $.location;
> has UInt $.apples;
> has UInt $.oranges;
> has UInt $.bananas;
> }
>
> my $FruitStand = Fruit.new( location => "Cucamonga",
> apples => 400,
> oranges => 200,
> bananas => 50 );
>
> 1) am I correct that I can make as many objects as I
> want out of a particular class?
>
> 2 ) what is the syntax to read an element inside an
> object?
>
> 3) what is the syntax to write to an element inside an
> object?
>
> I am confused, again.
>
> -T
>
