🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). This channel is logged for the purpose of keeping a history about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs can be inspected at colabti.org/irclogger/irclogger_log/raku
Set by lizmat on 1 May 2021.
kybr m: my $f = { $^a + $^b }; $f.signature.params 00:28
camelia ( no output )
kybr m: my $f = { $^a + $^b }; $f.signature.params.raku.say
camelia (Mu $a, Mu $b)
kybr is there a syntax (other than pointy block) to give $a and $b default values? 00:29
moon-child m: my $x = sub ($a = 5, $b = 7) { $a + $b }; say $x(); say $x(14) 01:13
camelia 12
21
moon-child kinda
codesections also kinda: 01:17
m: my $f = { (.<a> // 1) + (.<b> // 2) }; say $f(); say $f({:a(5):b(9)})
camelia 3
14
kybr yeah, i'm going to call that a no. thank you though. i am doing a thing where i have to analyse the signature of a given block (names, order, default values) in order to create the things that are passed to that block. 01:34
pointy block works well for that. maybe there's another way. 01:35
kybr m: my $f = { $^a(2) + $^b(2) }; $f.signature.params.say ; say $f({$_;}, {$_;}) 01:37
camelia (Mu $a Mu $b)
4
raydiak kybr: I think the only "normal" way besides pointy blocks to define a Callable with an explicit Signature is subs/methods. Anything else is going to be something more rare, like maybe deep mop or nqp magic, or a user-defined Callable (or thing acting as a Callable), possibly from a slang providing special syntax for the aforementioned...that kind of stuff 02:57
bisectable6: say Sub.^methods(:all).first: *.name eq "CALL-ME" 03:04
bisectable6 raydiak, Will bisect the whole range automagically because no endpoints were provided, hang tight
raydiak, ¦6c (53 commits): «Nil␤»
raydiak, Nothing to bisect!
raydiak ^ wrt that, regardless of what the docs say, looks like CALL-ME was always just a user-facing override, not something used by the default internal implementation 03:07
kybr raydiak: thank you. i managed to make something work for my situation. i control the things i pass in, so i can give them a way to accept defaults. 03:08
m: my class Arg { has $.value; method CALL-ME($v) { $!value = $v } } ; {$^a(2) + $^b(3)}(Arg.new, Arg.new)
camelia ( no output )
kybr m: my class Arg { has $.value; method CALL-ME($v) { $!value = $v } } ; {$^a(2) + $^b(3)}(Arg.new, Arg.new).say 03:09
camelia 5
kybr that'll work for me
raydiak I look forward to finding out what in the world you're working on :) 03:16
if you want those to just be defaults but not override any specified value, you probably want $!value //= $v instead of = 03:24
also not sure if it's any relevance at all, but fwiw in case you didn't already know, Signatures and Parameters can be defined, accessed, and passed around as first-class objects on their own without being attached to a callable
canbenshanlo is there another way to get a range from a string? 14:58
m: say "1..10".&EVAL.WHAT
camelia (Range)
Altreus Manually? i.e. extract the ints and construct a range from them 15:04
[Coke] In general, EVAL is how to get a thing from a String, unless there's a direction conversion, like .Int 15:08
m: say '1..10'.Range.^name
camelia No such method 'Range' for invocant of type 'Str'. Did you mean
'rand'?
in block <unit> at <tmp> line 1
[Coke] so, given no .Range, your EVAL is probably the most direct.
canbenshanlo Range.new(|"1..10".split('..').map: *.Int) isn't pretty 15:09
[Coke] True, but in general, neither is getting code from strings. 15:17
codesections Here's one that might be slightly prettier (though maybe more fragile): 15:23
m: say Range.new: |("1..10" ~~ m:g/\d+/)».Int
camelia 1..10
canbenshanlo Thanks for that! But I'm sticking to EVAL for now, so I can keep the one-liner 15:37
codesections I have a trait that works in the module it's defined in, but throws this error when I try to use it from a different file: 18:03
P6opaque: no such attribute '@!dispatchees' on type Routine in a Scalar when trying to get a value
codesections Have any of you run into that before/have any idea how I could resolve it? (It seems related to compile-time/order, but adding a BEGIN block didn't solve anything) 18:04
codesections er, nevermind ... the trait does work, but only when certain other modules aren't used. That gives me somewhere to start at least 18:14
lizmat that feels like there's a decont missing somewhere 18:33
I assume the trait is adapting @!dispatchees ??
codesections ^^ 18:34
codesections no, which struck me as odd too. It is messing with related things, though
lizmat ah, you're messing with where the Routine object is stored somehow ? 18:35
that would need to be deconted
codesections hmm, well, I just got it working by moving some things around. Not sure I fully understand what the issue was, but *shrug* 18:39
thanks
kybr what's the state of the art for binary grammars or pack/unpack? 20:36
canbenshanlo just curious, but is there something like this in raku? `sub foo(--> $x) { ... modify $x and it gets returned automatically upon exit ...}` 20:37
codesections canbenshanlo: I don't believe so, though the last expression of the sub is returned automatically, which helps avoid the need for something like that. Out of curiosity, what language has syntax like that? It's new to me 20:44
canbenshanlo nim, called result variables
nim-by-example.github.io/variables/result/ 20:45
lizmat kybr: if you're familiar with Perl's pack/unpack, then maybe modules.raku.org/dist/P5pack is for you 20:46
tonyo codesections: pascal has that too 20:49
some form of vb had it back in the old days too 20:50
kybr lizmat: thank you. i never learned it well. 20:53
lizmat yeah, pack/unpack is one of those things I also continuously needed to look up
codesections canbenshanlo: looking at the nim example, it'd be pretty easy to implement in Raku with a wrapper function and a dynamic variable. Like so: 20:56
m: sub res(&fn, |c) { my $*result; fn(|c); $*result}; say res { for 'a'..'z' { $*result.push: $_}}
camelia [a b c d e f g h i j k l m n o p q r s t u v w x y z]
tonyo codesections: www.tutorialspoint.com/pascal/pasc...ctions.htm 20:59
codesections tonyo: interesting. So, in Pascal it's either 'result' or name the user defines in the fn signature (unlike Nim, where it's always result) (I mean, judging from the respective docs) 21:03
canbenshanlo codesections: another slight difference between pascal and nim, if i'm not mistaken: nim default-initializes these variables. if your function returns an int according to the signature, but you are never writing to the result var, then you are still getting 0. 21:07
codesections canbenshanlo: I would have *thought* that the same would be true for my Raku version, but it's not. 21:12
m: sub f(--> Int:D) {}; dd f();
camelia Nil
codesections ^^^ that doesn't seem right
moritz wasn't there some kind of weird exception when it comes to Nil and type checks? 21:39
m: say Nil ~~ Int:D
camelia False
lizmat you can always return Nil 21:53
m: sub a(--> Int:D) { Nil }; dd a 21:54
camelia Nil