01:52 Manifest0 left 03:03 MasterDuke joined 03:40 kjp left 03:41 kjp joined 09:02 dakkar joined 09:03 dakkar left 09:05 dakkar joined 10:49 gfldex left 11:25 librasteve_ left
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2024/12/02/2024-49-advention/ 12:48
13:15 gfldex joined
fridge777 > <1 2 3>.Bag{2} 0 > <1 2 3>.Bag{<2>} 1 14:00
why do i need <> ß
yabobay i'm guessing <2> makes it a list 14:01
lizmat no, <2> makes it a Str 14:02
and 2 is an Int
fridge777 but then shouldnt {"2"}work too?
lizmat good question: actually, makes <2> it an allomorph IntStr 14:03
m: dd <2>
camelia IntStr.new(2, "2")
lizmat so still different from the Int 2
m: dd <foo>
camelia "foo"
lizmat if it cannot be converted to a numerical value < > produces Str 14:04
fridge777 um....so bag indexing needs an intstr? or something?
why
lizmat Bag uses value typing, aka the .WHICH value 14:05
m: say 2.WHICH, say "2".WHICH, say <2>.WHICH
camelia IntStr|Int|2|Str|2
Str|2True
Int|2True
lizmat m: say 2.WHICH, say "2".WHICH; say <2>.WHICH
camelia Str|2
Int|2True
IntStr|Int|2|Str|2
lizmat m: say 2.WHICH; say "2".WHICH; say <2>.WHICH
camelia Int|2
Str|2
IntStr|Int|2|Str|2
lizmat grrr
they are all different and as such are considered to be different for Set / Bag semantics 14:06
fridge777 ooh so its cause i made the initial list this way and not 14:07
> (1,2,3).Bag{2} 1
i see 14:08
thank you
yabobay what was the inspiration/utility for creating allomorphs?
fridge777 theres too many ways to do something ....
lizmat command line parameters and dispatch to MAIN was the original reason, I believe
also, in Perl all int/string values are effectively allomorphs 14:09
yabobay is it required for context to work? 14:12
lizmat what do you mean by context in this context? 14:13
yabobay like, numeric operators casting strings into numbers. sorry i guess that's not what context is 14:15
antononcube @lydia I am/was generally puzzled by allomorths (coming from Mathematica, R, etc.) But I find them useful now when dealing with graphs (in Raku.) The graph objects of "Graph" have strings as vertex IDs, but very often is needed to have the corresponding integer IDs. So, allomorphs get handy. 14:16
(That is in addition to CLI-related motivations.) 14:17
14:51 MasterDuke left 17:34 dakkar left 19:22 librasteve_ joined
librasteve in Perl all int/string values are effectively allomorphs <== this ++ 19:33
in raku Allomorphs are the way to get perl int/string behaviour in a typed world imo 19:34
lizmat m: dd "42" + "666" 19:41
camelia 708
lizmat you don't need allomorphs per se for all cases
but for MAIN dispatch from command line args, I don't see how you could do without 19:42
ab5tract I think if coercers-in-signatures had existed earlier on in the Rakudo implementation, there could have been some different design choices take around the Str <-> Int intermingling 20:05
*taken
librasteve maybe - nevertheless if the proposition is "the type system should enable me to do everything that I can in perl" then really coercion is a sidestep rather than a solution 20:22
I prefer that the language design provides a way to combine strict types and still deliver the goods and I suspect that this was a key design goal back in the day given what we ended up with 20:24
20:28 sjn left
librasteve_ www.irccloud.com/pastebin/OtfP4k2A 20:32
ab5tract My point is that `~` and `+` could have been built out of coercion and then IntStr would not need to exist 20:35
librasteve not that I don't really like coercions too
ab5tract Anyway, I think that allomorphism is one of the largest pitfalls awaiting beginners
That alone makes me question its ultimate utility 20:36
I'm obviously not saying I would change anything. necessarily at this point. But if there were ever a "major revision" of Raku that was as big a leap as Perl -> Raku was, I would expect to see allomorphs on the proverbial should-we-consider-chopping-this block 20:37
librasteve yeah - I agree on both points and I would say that the "problem" is that the allomorph literal <> is so darn nice ... 20:38
ab5tract It's worth noting that coercions themselves would need some revision to be able to support this, as demonstrating by the following:
m: multi m(Num() $n) { dd :$n }; multi m(Int() $i) { dd :$i }; m("1.234"); m("222")
camelia Ambiguous call to 'm(Str)'; these signatures all match:
(Num(Any) $n) from <tmp> line 1
(Int(Any) $i) from <tmp> line 1
in block <unit> at <tmp> line 1
ab5tract I may have to poke at this and see if I can't massage the dispatcher into distinguishing these two 20:39
but it might just not be possible with current type implementions/conceptions because "222" could easily be "222.0" as easily as "1.234" could be "1" 20:41
librasteve yes and no - this all match error is an indication that you cannot go Num->Str and Int->Str and expect the Str to carry on that "original info" 20:42
ab5tract I'm not sure what you mean, as these are Str -> Int and Str -> Num 20:49
librasteve_ m: “222”.^name.say 20:50
camelia Str
librasteve_ you are passing Str s to the multis
m: multi m(Num() $n) { dd :$n }; multi m(Int() $i) { dd :$i }; m(<1.234>); m(<222>) 20:51
camelia Ambiguous call to 'm(RatStr)'; these signatures all match:
(Num(Any) $n) from <tmp> line 1
(Int(Any) $i) from <tmp> line 1
in block <unit> at <tmp> line 1
librasteve_ m: multi m(Num() $n) { dd :$n }; multi m(Int() $i) { dd :$i }; m(<1.234e0>); m(<222>) 20:52
camelia :n(NumStr.new(1.234e0, "1.234e0"))
:i(IntStr.new(222, "222"))
librasteve_ qed
ab5tract m: multi m(Num() $n) { dd :$n }; ; m("1.234"); m("222")
camelia :n(1.234e0)
:n(222e0)
ab5tract I still don't see your point
m: multi m(Int() $n) { dd :$n }; ; m("1.234"); m("222")
librasteve_ m: multi m(Num $n) { dd :$n }; multi m(Int $i) { dd :$i }; m(<1.234e0>); m(<222>)
camelia :n(1)
:n(222)
:n(NumStr.new(1.234e0, "1.234e0"))
:i(IntStr.new(222, "222"))
ab5tract Your examples are not coercing 20:53
When you reduce the number of coercive candidates, it works as expected. Even if it involves losing information, as the Int() version shows 20:54
librasteve_ iiuc your example `m(“222”)` passes a Str to eg `multi m(Int() $i) {}` and while that can coerce the number 222 back out by re-parsing the Str, it has lost the ability to gate on whether the original 222 was an Int or Num literal 20:56
ab5tract the original 222 is clearly a string?
and the ambiguous call is a result of the fact that both Num() and Int() have equally valid answers to the question of "coerce '222'" 20:58
librasteve_ yes - so you can coerce the string 222 to a Num and to an Int - or you can say 222 can only coerce to an Int and fails to coerce to a Num since there is no `e` in it
ab5tract how can I specify the former? 20:59
librasteve_ our coercion is the more receptive one - but in the process we necessarily loose the original info that the Str was in fact an Int representation
ab5tract erm, sorry, the latter
librasteve_ yeah - so I am saying that our coercion works well and tries its best but it does not preserve the original literal as a second level check 21:01
ab5tract But the ambiguous call error isn't about losing information
Let me rephrase, because I think I understand what you are saying 21:02
librasteve_ well yes, because both Num() and Int() on `222` succeed, right?
ab5tract yes... but that isn't because information is lost
it's because both are equally valid
librasteve_ where is the original string `222` or `222e0` kept after you succeed with Num() ? 21:03
ab5tract wherever the programmer stored it, if they cared to do so 21:04
Anyway, I think this is going a bit off the rails for the beginner channel
librasteve_ but inside the multi after the coercion you can’t know what the original string would have been 21:05
ab5tract so what?
if we had a Num() that didn't take Int() and an Int() that didn't take Num(), it's irrelevant
21:05 destroycomputer- is now known as destroycomputers
ab5tract and if you want to know what it was as a string, you call .Str on it 21:06
librasteve_ so how can you go back and check which coercer Num() or Int() was the correct one
ab5tract because in a less fuzzy type system, there wouldn't be a way to go from "1.234" to "1"
librasteve_ my point is that Allomorphs do provide this level of information 21:07
ab5tract librasteve_: in what world are we going back and checking whether the subroutine signature does its job WRT types?
librasteve_ and yes I agree this is too detailed for the beginner channel ;-) sorry
ab5tract My experience is YAGNI, and it causes way more damage to being able to believe in the sanity of Raku's type system than it does to support faith in it
librasteve ok - guess we will have to agree to differ 21:09
ab5tract This started out with a simple statement saying that with the tools we have now, things might have turned out different. 21:12
It's like named arguments. There are plenty of things in core that already do look different based on whether they were implmented before or after
librasteve fair points both 21:13
21:39 Manifest0 joined
Manifest0 hi! How do i read from $*IN, without getting stuck? I have a process that's writing stuff to the console. I want to pipe it to my script what will read what's being written and act on it. 21:52
I want to do this in bash `prompt$ process | raku my_prog.raku`. Currently i'm doing `react whenever $*IN.Supply.lines`but it hangs. What am i doing wrong?
ab5tract Manifest0: when you say "hangs", do you mean that it processes as expected for some time and then stops? or does nothing happen at all? 22:15
Manifest0: it may help to run the pocess via Proc::Async instead 22:43
Manifest0 ab5tract: it processes as expected in the begining and then it stops 22:56
it keeps processing but it takes a lot of time to read the next lines. I believe it's buffering, but i don't know how to flush it 22:57
ab5tract it might actually be a flushing issue on the providing process 23:00
Manifest0 on the providing process? But if i ran that process without piping the output i don't have this hangs 23:02
ab5tract flushing is weird 23:03
but its also usually an output thing and not an input thing
Either way, I'd investigate using Proc::Async to call the process 23:04
But it's worth noting that just because output is "normal" when sent to stdout of a terminal doesn't mean it will behave the same way outside of a pty 23:05
Manifest0 just noticed that `react whenever $*IN.lines` works. Adding the .Supply, makes it to hang 23:26
ab5tract interesting 23:38
that's still in conjunction with react/whenever?
fridge777 why wont this work: (^@x.elems).map({@x.clone.splice($_, 1)}) ? error i am getting is Cannot resolve caller splice(List:D, Int:D, Int:D); but thats the signature isnt it..? 23:42
Manifest0 ab5tract: yep
ab5tract fridge777: not sure 23:49
m: my @x = 'c' .. 'z'; dd (^+@x).map({@x.clone.splice($_, 1)})
camelia (["c"], ["d"], ["e"], ["f"], ["g"], ["h"], ["i"], ["j"], ["k"], ["l"], ["m"], ["n"], ["o"], ["p"], ["q"], ["r"], ["s"], ["t"], ["u"], ["v"], ["w"], ["x"], ["y"], ["z"]).Seq
ab5tract seems ok to me? 23:50
fridge777 weird
ab5tract Assuming that's the output you want, I would probably have written it as: 23:51
m: dd ('s' .. 'z').map: { [$_] }
camelia (["s"], ["t"], ["u"], ["v"], ["w"], ["x"], ["y"], ["z"]).Seq
ab5tract but that doesn't exactly explain the signature issue you are seeing 23:52
what version of rakudo are you running?
fridge777 2023.11 23:53
ab5tract hmm.. I don't recall anything added to splice besides my own refinements in 2024 (talk about bias!) but those are only exposed via use v6.e.PREVIEW 23:54
fridge777 yeah i dont know..ill sleep on it and try again tomorrow. thank you! 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!