On 1/3/19 1:52 AM, JJ Merelo wrote:
El mié., 2 ene. 2019 a las 21:04, ToddAndMargo via perl6-users
(<perl6-us...@perl.org <mailto:perl6-us...@perl.org>>) escribió:
Dear Perl 6 Developers,
Fedora 29, x64
Xfce 4.13
$ perl6 -v
This is Rakudo version 2018.11 built on MoarVM version
2018.11 implementing Perl 6.d.
I am constantly improving (changing things) in my subs,
etc.. As such, the things I return often change.
Because of this, I have a found something I just do not like
in the checker (Perl6 -c xxx) and the run time compiler.
Here is a simplified sample code with the error in it:
<code RtnBooBoo.pl6>
#!/usr/bin/env perl6
sub AddThree( Int $a, Int $b, Int $c ) {
my Int $d = $a + $b + $c;
return $d;
}
my Int $X = 0;
my Int $Y = 0;
( $X, $Y ) = AddThree( 1, 2, 3 );
say "X = <$X>\tY = <$Y>";
</code RtnBooBoo.pl6>
The error is that the subroutine is only returning one
value and two are trying to be read.
And the checker passes it!
$ perl6 -c RtnBooBoo.pl6
Syntax OK
No, it is not okay. The sub and the caller do not match up!
If you run the flawed code, you get:
$ RtnBooBoo.pl6
Use of uninitialized value of type Int in string context.
Methods .^name, .perl, .gist, or .say can be used to stringify
it to something meaningful. in block <unit> at ./RtnBooBoo.pl6
line 12
X = <6> Y = <>
This is a runtime error, not a compile time error. And it's got nothing,
or very little, to do with the routine itself. When you are doing the
assignment of x and y, you are giving Y a null value. There's no way the
static type checker (run by -c) knows this. You know, Turing halting
problem and all that.
Which is a bizarre warning (it does not stop on this error). And
A warning, by definition, does not stop. It's simply saying: hey, you
are trying to convert into a string something that cannot be converted
(a null value). Let's say it's nothing (empty string), and let's leave
it at that.
it is also not the error. The error was that the return line's
returned variables and the caller do not match up. Not an
uninitialized value.
There's no type checking _at return time_ it happens _at assignment
time_. And that time is runtime, not compile time.
If you send too few variables to a sub, you get the finger shaken
at you. The return should also have the same checking capability.
You can assign a null value to any typed variable. That's not a problem.
The problem is trying to print it.
Would you guys please consider improving the checker and the compiler?
I would say that would need solving the Turing halting problem (or
variation thereof) https://en.wikipedia.org/wiki/Halting_problem So
that's not within reach of a bunch of Perl programmers, even if hubris
is one of our qualities.
Cheers
JJ
Hi JJ,
Indeed. That does not mean I like the way it is done.
You know, if you guys ever decide to allow more than one
return type without having to create a new type, that would
make me happy:
sub AddThree( Int $a, Int $b, Int $c --> Str, Int ) {
my Int $d = $a + $b + $c;
return ( "a+b+c=", $d );
}
I would post it as an RFE at the bug reporter, but I don't feel
like the ...
-T
