🦋 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.
oddp calling foo('12') for this recurses endlessly: multi sub foo($x) { foo($x) }; multi sub foo(Int $x) { $x }; 00:00
back to 'where /\d+/' it is i guess
moon-child I wonder if multi sub foo(Int() $x) would work 00:04
m: multi sub foo($x) { say 1 }; multi sub foo(Int() $x) { say 2 }; say foo '5'; 00:05
camelia Ambiguous call to 'foo(Str)'; these signatures all match:
($x)
(Int(Any) $x)
in block <unit> at <tmp> line 1
moon-child nope
ugexe multi sub foo($x) { foo($x) }; 00:16
where could this dispatch to with foo("12")?
you could use `multi sub foo($x) { nextwith($x) };` but again... what would it dispatch to when the only other candidate requires Int (12) not Str ("12")? 00:18
oddp man, just realized that your example from above works with <1 0> because that produces a IntStr list where as i am using regular str lists 00:50
oddp well, well, sorry for wasting everyone's time, but i guess i better stick to ruby for now. my brain simply hasn't enough folds for raku 00:52
moon-child eh ruby doesn't even have multiple dispatch, does it? :P 00:55
could just avoid multis
Geth doc: 4cb25dbd56 | (Suman Khanal)++ (committed using GitHub Web editor) | doc/Language/py-nutshell.pod6
Example in raku not working as expected

The last example
  ```
   my $list1 = (1, "two", 3, "hat");
   my $list2 = (5, 6, "seven");
... (22 more lines)		 11:31
linkable6 Link: docs.raku.org/language/py-nutshell
Altreus Was there any further discussion on my ancient question about why we have "multi" when its omission unnecessarily restricts extension? 11:42
Can it not be inferred/ 11:43
moritz requiring "multi" allows to catch accidental re-definition of only subs 11:46
Altreus then why not require only instead? 12:19
it also prevents you from intentionally re-defining subs that were not set up to do so 12:20
Which is a problem when you don't own the original
Adding another option for a procedure is good design, in my opinion, and should be encouraged 12:21
Therefore, preventing it by default is bad
multi should be the default
codesections Altreus: IMO, there's a bit of a library/application distinction. When writing _library_ code, I agree that it's best to default to multi for the reasons you say. But in end-user code (esp. scripts) it seems like "only" is a good default (it simplifies the mental model and restricting extension is less of an issue) 12:25
and since library authors tend to be more experienced, I'm ok with having the literal default be the one that fits application code, and asking library authors to opt in 12:26
moritz also, only subs are easier to learn for the beginner 12:27
codesections (esp. since `multi f` is only slightly longer than `sub f` -- though that doesn't apply to methods)
moritz: yeah, that's a more direct way of putting what I meant by "it simplifies the mental model" :D 12:28
Altreus So can you add a multi method to a subclass of a class that doesn't define the original as multi? 12:42
Maybe you can override the multi-ness of the existing one?
m: class A { sub a ($x) {} }; class B isa A { multi sub a ($x, $y) {} }; 12:43
camelia 5===SORRY!5=== Error while compiling <tmp>
Unable to parse class definition
at <tmp>:1
------> 3class A { sub a ($x) {} }; class B is7⏏5a A { multi sub a ($x, $y) {} };
expecting any of:
whitespace
Altreus er
m: class A { sub a ($x) {} }; class B is A { multi sub a ($x, $y) {} };
camelia ( no output )
Altreus m: class A { sub a ($x) { say $x } }; class B is A { multi sub a ($x, $y) { say "$x ... $y"} }; my $b = B.new; $b.a("A"); $b.a("A", "B") 12:44
camelia No such method 'a' for invocant of type 'B'
in block <unit> at <tmp> line 1
Altreus m: class A { method a ($x) { say $x } }; class B is A { multi method a ($x, $y) { say "$x ... $y"} }; my $b = B.new; $b.a("A"); $b.a("A", "B")
camelia Cannot resolve caller a(B:D: Str:D); none of these signatures match:
(B: $x, $y, *%_)
in block <unit> at <tmp> line 1
Altreus you what
codesections you'd need to add a bit of code to re-dispatch to parent when it doesn't match
Altreus OK then I object to that :) 12:45
this is anti-DWIM
codesections fair
Altreus I'm happy it let me redefine it - I expected an error there 12:52
Although the actual error is worse :D
lizmat m: class A { method foo() { dd } }; class B is A { proto method foo(|) {*}; multi method foo() { dd; nextsame } }; B.foo 13:02
camelia method foo(B: *%_)
lizmat you can use a proto
however, the proto will prevent you from doing nextsame and friends 13:03
Altreus: is that a problem ?
if so, you could do something like;
class A { method foo() { dd } }; class B is A { my constant &a = B.^find_method("foo"); proto method foo(|) {*}; multi method foo() { dd; a(self) } }; B.foo 13:05
evalable6 method foo(B: *%_)
method foo(A: *%_)
lizmat aka, save the previous dispatch chain in a constant (at compile time) *before* the new proto is added 13:06
and refer to that to go up the dispatch chain again
hmmm...self.&a() instead of a(self) probably
codesections and that foo method could be `multi method foo(|)` to come after all your own foos, right? 13:07
lizmat if I understand your question correctly, yes :-) 13:08
Altreus I dunno if that's a problem because I'm yak shaving 13:21
But it does seem like a problem if someone provides a class and I have to jump through hoops to extend it
Raku has enough gotchas
lizmat well, most of them in the core have been fixed I think for the publicly accessible methods 13:22
but please correct me if I'm wrong :-)
Altreus I was more thinking about community modules 13:23
Everyone would have to make everything multi just in case
lizmat in any case, I think this was a deliberate decision at one point by @Larry
yeah, that's the consequence of this
Altreus I wonder what the rationale is
lizmat I wonder if newdisp / RakuAST would make changes to this more easy
Altreus Because the outcome is heckin' inconvenient
codesections yeah. But my argument is that it's easier to have best practices for modules than user code 13:24
lizmat moritz was around then, maybe he can shed some light
codesections it feels like it's in the spirit of "torture the implementer", in that it puts a little extra burden on module authors to simplify things for end users 13:25
Altreus Seems like a pull request engine to me 13:26
Although with a workaround at least it's not showstopping
lizmat also: with B.can("foo").head it's less meta-oppy 13:27
instead of .^find_method
afk for a few hours& 13:30
Geth doc: sumanstats++ created pull request #3882:
Fix tuple-like structure in Raku
Geth doc: 1fe9282577 | (Suman Khanal)++ (committed by Juan Julián Merelo Guervós) | doc/Language/py-nutshell.pod6
Fix tuple-like structure in Raku

Do a minimal change as suggested in github.com/Raku/doc/commit/4cb25db...36b73da106		 13:52
linkable6 Link: docs.raku.org/language/py-nutshell
antononcube HI! I asked this question yesterday, but got disconnected, so I do not know about any responses... I wonder should I use Math::Matrix or Math::Libgsl::LinearAlgebra. Has anyone used Math::Matrix for non-trivial matrix computation workflows? 14:45
codesections I haven't, sorry (I know that's not helpful, but I wanted to make sure you know that we're not ignoring the question!) 15:37
lizmat antononcube: I think I would investigate using Math::Libgsl::LinearAlgebra girst 15:56
lizmat *first 15:56
lizmat . 18:11
Geth doc: 294096359d | Coke++ | doc/Language/py-nutshell.pod6
whitespace
 18:40
linkable6 Link: docs.raku.org/language/py-nutshell
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2021/05/10/2021-...-beta-pod/ 19:03
eseyman No!!!! Not another one! 19:12
patrickb lizmat++ 19:39
Geth doc: da1f28ba08 | (Stoned Elipot)++ | doc/Type/Num.pod6
Use code formatting
 21:50
linkable6 Link: docs.raku.org/type/Num

Powered by Cro and the Raku® Programming Language.

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

Thank you!