01:04 colemanx left, colemanx joined, getimiskon left 02:31 hexology joined 02:49 parv joined 08:52 dakkar joined 10:11 discord-raku-bot left 10:12 discord-raku-bot joined 10:21 pelai joined 10:37 pelai left 12:08 A26F64 joined 12:40 getimiskon joined
A26F64 I'm wondering about a somewhat obscure error. docs.raku.org/type/Set states: "you can create Set masquerading as a hash"; "this syntax also allows you to specify the type of values you would like to allow". 12:41
m: class Foo1 { has %.f is Set; }; my $foo = Foo1.new(f => <a b>); say $foo.raku;
camelia Foo1.new(f => Set.new("b","a"))
A26F64 m: class Foo2 { has %.f is Set[Str]; }; my $foo = Foo2.new(f => <a b>); say $foo.raku; 12:42
camelia ===SORRY!===
Object of type Set[Str] in QAST::WVal, but not in SC
A26F64 That type specification does not work for attributes within class definitions? 12:43
lizmat m: my %s is Set[Str] = <a b>; dd $s 12:50
camelia 5===SORRY!5=== Error while compiling <tmp>
Variable '$s' is not declared. Did you mean '%s'?
at <tmp>:1
------> 3my %s is Set[Str] = <a b>; dd 7⏏5$s
lizmat m: my %s is Set[Str] = <a b>; dd %s
camelia Set[Str].new("a","b")
lizmat A26F64: that'd be a bug :-)
m: class A { has %!f is Set[Str] }; A.new # golf 12:52
camelia ===SORRY!===
Object of type Set[Str] in QAST::WVal, but not in SC
lizmat m: class A { has %!f is Set[Str] }; A.CREATE # better golf
camelia ===SORRY!===
Object of type Set[Str] in QAST::WVal, but not in SC
lizmat A26F64: could you make a rakudo issue for that ? 12:53
A26F64 Would that be in one of the GitHub repositories? (Sorry; I haven't done so before and am not sure.) 12:56
(I also don't have a personal GitHub account, actually.)
Morfent m:``` 13:01
class A { has %!f is Set of Str }; A.CREATE
```
`&trait_mod:<is>` for attributes is kinda screwy. `&trait_mod:<of>` is the only way i'm aware of to give `Set` its type parameter with it 13:03
m:``` 13:05
class A { has Str $!f is Set }; A.CREATE
```
er
m:```
class A { has Str %!f is Set }; A.CREATE
```
while that works in this context, iirc precomp takes issue with it? 13:06
``` 13:07
bastille% cat lib/Foo.rakumod
use v6;
unit class Foo;
has Str %!foo is Set;
bastille% raku -Ilib -MFoo -e ''
===SORRY!=== Error while compiling -e
===SORRY!===
Missing serialize REPR function for REPR MVMContext (BOOTContext)
at -e:1
```
gfldex m:``` 13:20
class A { has %.f is Set[Str]; }
say A.new.f.WHAT;
```
That looks like a Rakudobug to me.
Morfent yeah 13:26
A26F64 I do have another question about types. (I'm accumulating a number of such questions.) I'm mostly assuming that this one isn't a bug. . . . 13:43
docs.raku.org/language/typesystem#subset states: "A subset declares a new type that will re-dispatch to its base type."
m: subset S of Int where * >= 0; my S $s = 616; $s.WHAT;
camelia ( no output )
A26F64 I didn't expect that, actually; my local instance returns `(Int)`. 13:44
m: subset S of Int where * >= 0; my S $s = 616; say $s.WHAT;
camelia (Int)
A26F64 There we are.
Does that result reflect the intention of the above statement from the documentation? 13:45
Because one might expect a result of "(S)".
getimiskon Hello. Is there anyone who understands how the MPD client module works like? 13:46
lizmat A26F64: the subset is only to constrain 13:50
in that context, not to coerce
A26F64 It seems that signatures do not accept subsets as type constraints for nonscalars, though? 13:52
sub foo1(Int @f) { say @f; }; my Int @s = <2 3>; foo1(@s); # This works
m: sub foo1(Int @f) { say @f; }; my Int @s = <2 3>; foo1(@s); # This works
camelia [2 3]
A26F64 m: subset S of Int where * >= 0; sub foo2(S @f) { say @f; }; my S @s = <2 3>; foo2(@s); 13:53
camelia Constraint type check failed in binding to parameter '@f'; expected S but got Array[S] (Array[S].new(IntStr....)
in sub foo2 at <tmp> line 1
in block <unit> at <tmp> line 1
lizmat m: subset S of Int where * >= 0; my S @a = 1,2,3,-4 13:54
camelia Type check failed in assignment to @a; expected S but got Int (-4)
in block <unit> at <tmp> line 1
lizmat looks to me that works ?
A26F64 My example was for constraints in a signature. 13:55
Nemokosch It works, I remember this 13:56
One has to give up on the sigil in these cases 13:57
I don't completely remember the syntax but it looked weird tbh
> <Altreus> m: my subset PosInt of Int where * >= 0; sub f(Array[PosInt()]() $array) { .say for @$array }; f([0,1,2,3,4,5]);
14 October
m: my subset PosInt of Int where * >= 0; sub f(Array[PosInt()]() $array) { .say for @$array }; f([0,1,2,3,4,5]); 13:58
if you are fine with immutable values passed, you can use \array for passing the value and then access it as array, without a sigil 14:08
but that means that you are really using the content directly, not a variable 14:09
lizmat m: subset S of Int where * >= 0; sub a(S @a) { }; a (1,2,-4) # A26F64 works in a signature ?
camelia Type check failed in binding to parameter '@a'; expected S but got List ((1, 2, -4))
in sub a at <tmp> line 1
in block <unit> at <tmp> line 1
A26F64 That composite form ("Array[PosInt()]()") does work but it seems like there should be a natural syntax for that.
lizmat should read the error message :-) 14:10
Nemokosch this was the best the guys could come up with back a month ago 14:12
maybe there is a better way, who knows
gfldex A26F64: Type constrains on @-sigiled containers are not well supported because they are often a bad idea. By nailing the types down you hinder composibility. 14:38
In fact, if you got a single @-sigiled argument you should alway consider a slurpy. 14:40
A26F64 I was thinking that by nailing the types down we would avoid functional inconsistencies and errors. 14:42
gfldex Raku is a dynamic language. Type constrains produce runtime errors. That can be desired and very helpful. But it can also lead to programs that don't try hard enough to DWIM. 14:43
Nemokosch > There are limits to what the REPL can do. Raku is not as dynamic as it looks at first. 14:45
gfldex, 2021. 11. 04.
:DD
gfldex A26F64: When you have a list of values, those values have to come from somewhere. Putting the type check on those values before they are composed into a list, is often a good place for it. 15:07
A26F64 gfldex Using the positional sigil for a variable in signatures might allow specification of types contained therein. But it almost seems simpler---and you seem to be implying that it's superior---in some cases to instead use a scalar sigil. 15:23
gfldex Actually not. You can't have a slurpy $-sigil. The idea is to place type checks - if possible - on the caller site. Lists migth get big and the compiler is not clever enough to remove expensive type checks while crossing from caller to callee. 15:27
A26F64 While I did employ (and even appreciate) the "slurpy" nature of function arguments in Perl I do also appreciate Raku's use (if I understand it correctly) of discrete elements in a signature, which is closer to arguments in other languages. 15:35
It seems that returning values is still a slurpy business, though. 15:36
m: sub f { return [4, 5], <a b>; }; my (@x, @y) = f; say @x; say @y; 15:37
camelia [[4 5] (a b)]
[]
A26F64 Whereas: m: sub f { return [4, 5], <a b>; }; my ($x, $y) = f; say $x; say $y;
m: sub f { return [4, 5], <a b>; }; my ($x, $y) = f; say $x; say $y;
camelia [4 5]
(a b)
Nemokosch doesn't this disprove your point? 15:38
A26F64 In what way? I'm suggesting that one might expect each array of function f to map discretely to each element receiving the return values. 15:39
. . . Regardless of the type/sigil of variable. 15:40
Nemokosch m: [4, 5], <a b> andthen .raku
why does it not run 😠
anyways, the function returns _one list_
so when you are assigning it to a list, well, it will just take it big time 15:41
the point is exactly that this isn't "regardless of sigil" 15:42
A26F64 Thinking about it that way (the return value returns a single list) does allow that to make sense. But one might then expect that $x above would just consume the entire list as well. But I guess that `my ($x, $y)` as a convention allows that to be a list? 15:44
Nemokosch there is some asymmetry indeed btw 15:49
A26F64 (I was going to ask about specifying type constraints on complex return values like that. For example, we might want to indicate that f returns a List of an Array[Int] and an Array[Str]. But I feel like the response might be to dissuade me from bothering with such specificity in the first place.) 15:50
Nemokosch Ngl I wonder what keeps someone digging these type signatures at all 15:53
btw I really have no idea how my (@a, @b) = ... could work with _anything_ 15:55
A26F64 Regarding the intention: it seems like one would want to maintain an unbroken chain of type constraints throughout a program. From the initialization of a variable to a function signature to that function's return value to the receiving variable. I guess that you could check the type within a function but it seems to make sense to check it on the 15:56
call. (Disclaimer: maybe I'm not making a tremendous amount of sense with respect to Raku or program design in general.)
The feeling is that you wouldn't want the data to get polluted with unexpected types somewhere in there. 15:57
15:58 parv left 16:04 A26F64 left 16:21 getimiskon left 16:29 A26F64 joined 17:33 dakkar left 18:48 mybutterfliable joined 18:50 mybutterfliable left 19:09 A26F64 left 19:20 melezhik24 joined 19:29 melezhik24 left 21:01 p6steve joined 21:08 getimiskon joined 21:11 p6steve left 21:24 p6steve joined 21:29 p6steve left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!