[perl #131511] [Feature Request] Take a step closer to Signatures as constraints on variables.
# New Ticket Created by Benjamin Goldberg
# Please include the string: [perl #131511]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=131511 >
With the current version of rakudo, if I were to run the code “my ();”,
I would get the error “Signatures as constraints on variables not yet
implemented.”
To bring us a little closer to being able to implement this, I propose the
following:
First, provide a subtype (subrole?) of the Callable role, which has a
signature. These subrole would probably be created by writing
Callable[:(...)].
Second this paramaterized version of Callable would need to be somewhere in
the ancestry of every existing Block, Routine, Sub, Method, Submethod and
Macro objects, or at least, for those which have a signature.
Third, make "my (blah) ;" become nearly the same as "my
Callable[:(blah)] $varname;" except of course for the sigil.
Fourth, ensure that paramaterization of Callable *doesn't* produce a
separate, distinct role for every signature passed in, but caches based on a
canonicalized version of the signature. For now, canonicalization of a
signature simply means removing the names of positional parameters, so :(Int
$foo) is transformed into :(Int $)
These four changes together mean that a user can write:
constant two_ints_sub_t = Callable[:(Int $asdf, Int $qwerty -->Int)];
my two_ints_sub_t $foo = sub add (Int $lhs, Int $rhs --> Int) { $lhs+$rhs };
my (Int $x, Int $y --> Int)
say $foo.VAR.WHAT; # "(Callable[:(Int $, Int $-->Int)])"
say # "(Callable[:(Int $, Int $-->Int)])"
say $foo.VAR.WHAT === # "True"
A fifth step, adding a method named sub_signature to the paramaterized role,
which returns the captured signature, would make it NativeCall friendly.
The drawback of this proposal is that it only works with signatures which
don't differ other than parameter names. But at least it's a start.
[perl #126855] [BUG] .WHAT does not allow spaces around the dot (42 . WHAT)
On Wed, 09 Dec 2015 08:12:00 -0800, alex.jakime...@gmail.com wrote: > Code: > say 42 .WHAT > > Result: > ===SORRY!=== > Method call must either supply a name or have a child node that evaluates > to the name > > > Well, I think that it should work. One practical use is ｢^42 .WHAT｣. > > Some explanation: > > well, .WHAT anywhere in a space-y method call chain didn't work with > the original commit either > so it's at least not a regression > okay, interesting > probably 'cause .WHAT doesn't go the normal > QAST::Op(:op,...) route > right, it's macro-Y > which fits the error message, 'cause we apparently build such an Op > but > don't populate the children correctly, because .WHAT isn't a > method > that can be called with callmethod > > > Well, if it is not supposed to work, then at least the error message should > be awesome. Right now it doesn't even mention the line number. +1 on fixing this or improving error message. In my production code I encountered this bug while trying to test the term's type object and I added the space after the method to align stuff: is make-temp-path.WHAT === IO::Path, *.not, 'made path is not === IO::Path'; is make-temp-dir .WHAT === IO::Path, *.not, 'made dir is not === IO::Path'; The second line crashed. The current error doesn't even include a location, so it has the potential for a tedious bug hunt.
[perl #126855] [BUG] .WHAT does not allow spaces around the dot (42 . WHAT)
On Wed, 09 Dec 2015 08:12:00 -0800, alex.jakime...@gmail.com wrote: > Code: > say 42 .WHAT > > Result: > ===SORRY!=== > Method call must either supply a name or have a child node that evaluates > to the name > > > Well, I think that it should work. One practical use is ｢^42 .WHAT｣. > > Some explanation: > > well, .WHAT anywhere in a space-y method call chain didn't work with > the original commit either > so it's at least not a regression > okay, interesting > probably 'cause .WHAT doesn't go the normal > QAST::Op(:op,...) route > right, it's macro-Y > which fits the error message, 'cause we apparently build such an Op > but > don't populate the children correctly, because .WHAT isn't a > method > that can be called with callmethod > > > Well, if it is not supposed to work, then at least the error message should > be awesome. Right now it doesn't even mention the line number. +1 on fixing this or improving error message. In my production code I encountered this bug while trying to test the term's type object and I added the space after the method to align stuff: is make-temp-path.WHAT === IO::Path, *.not, 'made path is not === IO::Path'; is make-temp-dir .WHAT === IO::Path, *.not, 'made dir is not === IO::Path'; The second line crashed. The current error doesn't even include a location, so it has the potential for a tedious bug hunt.
[perl #131510] [SEGV] Segfault when `-Ilib` while running a file that does `use lib ` and loads some modules
# New Ticket Created by Zoffix Znet # Please include the string: [perl #131510] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=131510 > To get code that segfaults: cd $(mktemp -d); git clone https://github.com/zoffixznet/perl6-Temp-Path . ; git checkout ca5ab2816705cf36911b91e4029224b4d4644a2d; Now run this several times and it'll segfault ~50% of the time: perl6 -Ilib t/03-DESTROY.t The test file already does `use lib ` and if you remove `-Ilib` switch, the segfault seems to disappear: perl6 t/03-DESTROY.t I tried making a small test case that just had a dummy module and was doing `use lib ` but that didn't segfault. Perhaps it's got to do with loading some installed modules?
[perl #131509] Dynamic vars aren't visible inside Promise.then
On Sun, 04 Jun 2017 09:00:46 -0700, c...@zoffix.com wrote:
> I expected the .then'ed code to be in my dynamic scope so it'd see the
> variable I'm using, same as it's seen in a start block:
>
> m: my $*FOO = 42; sub bar () { code }; bar { say
> $*FOO; await start { say $*FOO }.then: { say $*FOO // 'aint there' } }
> rakudo-moar 3755c0: OUTPUT: «4242aint there»
Thank you for the report. This is now fixed.
Fix: https://github.com/rakudo/rakudo/commit/36bc4102225a324
Test: https://github.com/perl6/roast/commit/e5d144ee09b8bcd36
[perl #131509] Dynamic vars aren't visible inside Promise.then
# New Ticket Created by Zoffix Znet
# Please include the string: [perl #131509]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=131509 >
I expected the .then'ed code to be in my dynamic scope so it'd see the variable
I'm using, same as it's seen in a start block:
m: my $*FOO = 42; sub bar () { code }; bar { say $*FOO; await
start { say $*FOO }.then: { say $*FOO // 'aint there' } }
rakudo-moar 3755c0: OUTPUT: «4242aint there»
[perl #131508] [BUG] `state` with % is Sethash in whenever block ends up with a type object on second iteration
# New Ticket Created by Zoffix Znet
# Please include the string: [perl #131508]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=131508 >
%goods here works as expected:
m: my %goods is SetHash; react whenever Supply.interval(.3) { $++ >
3 and done; dd %goods; %goods++; }
rakudo-moar 3755c0: OUTPUT:
«SetHash.new()SetHash.new("foo")SetHash.new("foo")SetHash.new("foo")»
On second iteration ends up being a type object:
m: react whenever Supply.interval(.3) { state %goods is SetHash; $++
> 3 and done; dd %goods; %goods++; }
rakudo-moar 3755c0: OUTPUT: «SetHash.new()SetHashTried to get the
result of a broken Promise in block at line 1Original
exception:Cannot modify an immutable SetHash ((SetHash)) in block
at line 1»
[perl #122346] [@LARRY] "nom regression" behavior of lexicals/invoking sub before they are defined changed
On Sun, 20 Jul 2014 10:33:13 -0700, coke wrote:
> S02-names-vars/variables-and-packages.t has several TODO'd tests of
> this sort:
>
> {
> nok foo().defined, "get variable not yet declared using a sub (1)";
> is foo(), 1, "get variable not yet declared using a sub (2)";
> is foo(), 2, "get variable not yet declared using a sub (3)";
>
> my $a;
> sub foo { $a++ }
> }
>
> Where the expectation is that the first call to the foo will return an
> undefined value; in nom, it returns 0.
I reworded the fudges[^1] to test for current behaviour, which IMO is
massively more desirable that to issue warnings any time you numericly
compare a post-incremented anon state var.
[1] https://github.com/perl6/roast/commit/65a0dc5db3
[perl #122346] [@LARRY] "nom regression" behavior of lexicals/invoking sub before they are defined changed
On Sun, 20 Jul 2014 10:33:13 -0700, coke wrote:
> S02-names-vars/variables-and-packages.t has several TODO'd tests of
> this sort:
>
> {
> nok foo().defined, "get variable not yet declared using a sub (1)";
> is foo(), 1, "get variable not yet declared using a sub (2)";
> is foo(), 2, "get variable not yet declared using a sub (3)";
>
> my $a;
> sub foo { $a++ }
> }
>
> Where the expectation is that the first call to the foo will return an
> undefined value; in nom, it returns 0.
I reworded the fudges[^1] to test for current behaviour, which IMO is
massively more desirable that to issue warnings any time you numericly
compare a post-incremented anon state var.
[1] https://github.com/perl6/roast/commit/65a0dc5db3
[perl #131507] [LTA] “Weird node in analyze” when hyper calling an array of blocks ( @foo»() )
# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
# Please include the string: [perl #131507]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=131507 >
Code:
my @foo = { say ‘hello’ };
@foo»()
Result:
Weird node in analyze: NQPMu
===SORRY!===
Unknown QAST node type NQPMu
One can make it work by writing “@foo».()” and this way you get the expected
“hello”.
I don't know if it should work or not, but at least it shouldn't get confused
like this.
