This channel is intended for people just starting with the Raku Programming Language (raku.org). Logs are available at irclogs.raku.org/raku-beginner/live.html Set by lizmat on 8 June 2022. |
|||
01:09
razetime joined
03:32
camelia left
03:37
camelia joined
03:48
MasterDuke left
04:11
razetime left
04:32
razetime joined
04:42
teatime left,
teatime joined
04:44
teatime left,
teatime joined
05:06
teatwo joined
05:08
teatwo left,
teatwo joined
05:09
teatime left
05:40
siavash joined
07:42
habere-et-disper joined
|
|||
habere-et-disper | I grok : | 07:49 | |
m : elems gather .take if Date.new( year => 2013, month => $_, day => 13 ).day-of-week == 5 for 1..12 | |||
But I really wanted to write : | |||
m : elems gather .take if Date.new( year => 2023, month => (1..12).any, day => 13 ).day-of-week == 5 | |||
m: elems gather .take if Date.new( year => 2013, month => $_, day => 13 ).day-of-week == 5 for 1..12 | |||
camelia | ( no output ) | 07:50 | |
habere-et-disper | m: elems gather .take if Date.new( year => 2023, month => (1..12).any, day => 13 ).day-of-week == 5 | ||
camelia | Cannot call Date.new with these named parameters: month year day in block <unit> at <tmp> line 1 |
||
lizmat | (1..12).map( { my $dt := Date.new( year => 2013, month => $_, day => 13 ); $dt if .day-of-week == 5 } ) | 07:51 | |
habere-et-disper | Is the (1..12).any my misunderstanding of Junctions or only that Date does not support them ? | 07:54 | |
lizmat | 1..12 is a Range, not a Junction | 07:59 | |
ah, .any should read better :-) | |||
not sure what is going on there, but the Positional interface does work | 08:01 | ||
m: dd Date.new(2023, (1..12).any, 13) | |||
camelia | any(Date.new(2023,1,13), Date.new(2023,2,13), Date.new(2023,3,13), Date.new(2023,4,13), Date.new(2023,5,13), Date.new(2023,6,13), Date.new(2023,7,13), Date.new(2023,8,13), Date.new(2023,9,13), Date.new(2023,10,13), Date.new(2023,11,13), Date.new(2023,… | ||
habere-et-disper | Thank you lizmat That is exactly how I wanted to write it ! | 08:09 | |
m: say elems gather .take if .day-of-week == 5 for Date.new( 2023, (1..12).any, 13 ) | |||
camelia | 2 | ||
habere-et-disper | 😀 | ||
08:09
dakkar joined
|
|||
lizmat | :-) | 08:11 | |
although the use of "for" there is a bit iffy :-) | 08:12 | ||
nemokosch | I didn't even know junctions are iterable, is this a public interface? | 08:18 | |
lizmat | they aren't iterable, that's why I said the "for" was "iffy" | ||
m: .say if $_ %% 2 for 42 | 08:19 | ||
camelia | 42 | ||
lizmat | m: .say if $_ %% 2 for 43 | ||
camelia | ( no output ) | ||
lizmat | m: .say if $_ %% 2 for 42 |43 | 08:20 | |
camelia | any(42, 43) | ||
lizmat | m: .say if $_ %% 2 for (42 |43) | ||
camelia | any(42, 43) | ||
nemokosch | Heh | 08:21 | |
lizmat | m: .say gather .take if $_ %% 2 for 42 |43 | ||
camelia | ===SORRY!=== Error while compiling <tmp> Two terms in a row at <tmp>:1 ------> .say⏏ gather .take if $_ %% 2 for 42 |43 expecting any of: infix infix stopper statement end statement mo… |
||
lizmat | m: say gather .take if $_ %% 2 for 42 |43 | ||
camelia | (42) | ||
lizmat | m: say gather .take if $_ %% 2 for 42 | 43 | 44 | 08:22 | |
camelia | (42 44) | ||
nemokosch | So where did the junction ultimately distribute into its eigenvalues? | 08:23 | |
lizmat | the conditional .take | ||
nemokosch | m: say gather (1|2|3).take | 08:25 | |
Raku eval | (any(1, 2, 3)) | ||
nemokosch | Welp, i tried | ||
08:26
razetime left
|
|||
habere-et-disper | m: say ( Date.new( 2023, (1..12).any, 13 ).day-of-week == 5 ).iterator | 08:26 | |
camelia | List::Todo.new | ||
lizmat | I guess this is the reason: | 08:28 | |
multi method iterator(Junction:D:) { | |||
# If we're asked for an iterator, we should really give one rather than | |||
# auto-thread over the `iterator` method. Otherwise we get decidedly | |||
# confusing outcomes from things that do `.iterator` and then expect it | |||
# to follow the iterator API. | |||
list(self).iterator | |||
} | |||
interesting... :-) | |||
nemokosch | m: (1|2|3).list.say | 08:29 | |
Raku eval | any((1), (2), (3)) | ||
nemokosch | Lmao | ||
lizmat | github.com/rakudo/rakudo/commit/bceaeb1a9a | 08:30 | |
nemokosch | m: list(1|2|3).say | ||
Raku eval | (any(1, 2, 3)) | ||
nemokosch | Okay but how does this explain the countability in that snippet? | 08:31 | |
Okay, the if succeeds, the junction passes on, right? What do I miss? | 08:32 | ||
lizmat | m: say gather .take if .day-of-week == 5 for Date.new( 2023, (1..12).any, 13 ) | ||
camelia | (2023-01-13 2023-10-13) | ||
lizmat | the gather returns a Seq, and elems just counts the number of elems in it | ||
nemokosch | But why isn't that Seq only the one junction? | 08:33 | |
lizmat | so I guess the "for" wasn't that "iffy" after all | ||
because the "for" calls .iterator on the Junction under the hood, and thus iterates | |||
nemokosch | Didn't that commit just say that it will iterate as one? | 08:34 | |
lizmat | no, it said it will iterate, because making .iterator return a Junction would seriously be confusing to a lot of the internals | 08:35 | |
nemokosch | Not a Junction but an iterator that produces a Junction, like with scalars | 08:36 | |
But either way, NOT the eigenvalues | |||
That's what the commit message states | |||
at least this dragged me out of bed 😂 | 08:38 | ||
m: .say for (1|2|3) | |||
Raku eval | any(1, 2, 3) | ||
nemokosch | yeah | ||
lizmat | hmmmm so the "for" *is* iffy after all | 08:39 | |
hmmm | |||
nemokosch | m: say gather .take if .day-of-week == 5 given Date.new( 2023, (1..12).any, 13 ) | ||
Raku eval | (any(2023-01-13, 2023-02-13, 2023-03-13, 2023-04-13, 2023-05-13, 2023-06-13, 2023-07-13, 2023-08-13, 2023-09-13, 2023-10-13, 2023-11-13, 2023-12-13)) | ||
nemokosch | m: say gather .take if .day-of-week == 5 for Date.new( 2023, (1..12).any, 13 ) | 08:40 | |
Raku eval | (2023-01-13 2023-10-13) | ||
nemokosch | but it still isn't for some reason xd | ||
lizmat | ah.. the list(self) is a bit of a red-herring | ||
nemokosch | what does it produce? | 08:41 | |
lizmat | multi sub list(+l) { l } | ||
using the single arg rule, it returns the arg | 08:42 | ||
hmmm... | |||
ah, but that autothreads | |||
08:44
razetime joined
|
|||
lizmat | m: dd list(1|2).iterator.pull-one | 08:44 | |
camelia | any(1, 2) | ||
nemokosch | m: dd gather list(1|2).iterator.pull-one.take | ||
Raku eval | (any(1, 2),).Seq | ||
nemokosch | what really bothers me is that I can't reproduce or even imagine what happened with that for | 08:45 | |
lizmat | m: my $i := list(1|2).iterator; dd $i.pull-one for ^2 | ||
camelia | any(1, 2) IterationEnd |
||
lizmat | so it produces an iterator that produces 1 element, itself | ||
so the use of "for" *is* really "iffy" in the original case | 08:46 | ||
nemokosch | that may be true but then wouldn't for be equivalent with given? | 08:48 | |
lizmat | I guess the for deconts | 08:49 | |
nemokosch | which part takes that into account, of the if, the take and the gather? | 08:50 | |
m: my \test = (1|2|3); say gather test.take if test %% 3; | 08:52 | ||
Raku eval | (any(1, 2, 3)) | ||
lizmat | hmmm... given will just topicalize, whereas the for will return an iterator | ||
meh.. this is tricky :-) | |||
nemokosch | m: $_ := (1|2|3); say gather .take if $_ %% 3; | 08:53 | |
Raku eval | (any(1, 2, 3)) | ||
nemokosch | m: say gather .take for (1|2|3) | ||
Raku eval | (1 2 3) | ||
nemokosch | m: say .say for (1|2|3) | 08:54 | |
Raku eval | any(1, 2, 3) True | ||
nemokosch | is "gather for" something special? | ||
no other idea left | 08:55 | ||
m: my @vals = gather { .take for (1|2|3) }; dd @vals | 08:56 | ||
Raku eval | Array @vals = [any(1, 2, 3)] | ||
nemokosch | m: my @vals = gather .take for (1|2|3); dd @vals | ||
Raku eval | Array @vals = [1, 2, 3] | ||
lizmat | interesting | 08:57 | |
nemokosch | Well, it must be a bug, I see no other way out at this point 🙃 | ||
lizmat | hehe... or a feature :-) | ||
m: say gather .take for (1|2|3) | 08:58 | ||
camelia | (1 2 3) | ||
lizmat | m: .say for gather .take for (1|2|3) | ||
camelia | 1 2 3 |
||
09:55
habere-et-disper left
|
|||
lizmat | github.com/rakudo/rakudo/issues/5320 | 10:07 | |
.tell habere-et-disper your version may actually depend on a bug in Rakudo: github.com/rakudo/rakudo/issues/5320 | |||
meh | |||
nemokosch ^^ | 10:08 | ||
nemokosch | 🧐 thanks | 10:14 | |
lizmat | it appears to be a codegen issue with "for" inside a "gather" | 10:17 | |
librasteve | m: say Date.new( 2023, (1..12).any, 13 ).iterator | 10:33 | |
Raku eval | List::Todo.new | ||
librasteve | ^^ guess that means something is a bug - (and there was me thinking it was the single argument rule) | 10:34 | |
lizmat | m: my $i := Date.new( 2023, (1..12).any, 13 ).iterator; dd $i.pull-one for ^2 | ||
camelia | any(Date.new(2023,1,13), Date.new(2023,2,13), Date.new(2023,3,13), Date.new(2023,4,13), Date.new(2023,5,13), Date.new(2023,6,13), Date.new(2023,7,13), Date.new(2023,8,13), Date.new(2023,9,13), Date.new(2023,10,13), Date.new(2023,11,13), Date.new(2023,… | ||
lizmat | m: my $i := (1|2|3).iterator; dd $i.pull-one for ^2 | 10:35 | |
camelia | any(1, 2, 3) IterationEnd |
||
lizmat | nothing wrong there librasteve | ||
librasteve | ok - so docs.raku.org/type/Junction#method_iterator | 10:36 | |
Returns an iterator over the Junction converted to a List. is wrong then? | |||
in which case, what is the best way to "unpack" a junction ...? | 10:37 | ||
(or is that idea forbidden in principal?) | |||
lizmat | the idea is that the eigenstates of a Junction are opaque | 10:38 | |
librasteve | btw -- really enjoying the entertainment! | ||
lizmat | that's why I made raku.land/zef:lizmat/eigenstates :-) | ||
librasteve | ok - so its forbidden - but you have provided a workaround ? | 10:41 | |
lizmat | that's the gist of it | ||
librasteve | ^^ that's a doc bug then? (I can file an issue) | 10:42 | |
lizmat | m: my @a; sub a($a) { @a.push($a) }; a 1|2|3; dd @a # another way to unpack a junction | 10:43 | |
camelia | Array @a = [1, 2, 3] | ||
lizmat | m: sub unpack(Mu $a) { my @a; sub a($a) { @a.push($a) }; a $a; @a.List }; dd unpack 1|2|3 # another way to unpack junctions | 10:44 | |
camelia | (1, 2, 3) | ||
librasteve | use eigenstates; my $out = Date.new( 2023, (1..12).any, 13 ).day-of-week == 5; $out.&eigenstates.grep(*.so).elems.say; | 10:48 | |
nemokosch | "unpacking a junction" is kind of a confusing concept anyway. The eigenvalues are in a certain relation to each other. | 10:56 | |
librasteve | yeah - I get why it is forbidden (sorry I was using the word unpack loosley) | ||
nemokosch | oh I didn't mean to pick on the terminology, we could call it listing or iterating or whatever | 10:57 | |
by the way | |||
10:58
habere-et-disper joined
|
|||
m: my %multikey = (1|2) => True, (3&4) => False; dd %multikey | 10:58 | ||
Raku eval | Hash %multikey = {"1" => Bool::True, "2" => Bool::True, "3" => Bool::False, "4" => Bool::False} | ||
nemokosch | quite funny isn't it | ||
when this came up roughly a year ago, the & version actually benchmarked significantly faster for some reason | 10:59 | ||
lizmat | the power of junctions :-) | ||
nemokosch | m: my %multikey = (1^2) => True; dd %multikey | ||
Raku eval | Hash %multikey = {"1" => Bool::True, "2" => Bool::True} | ||
nemokosch | anyway, they all work but there is no meaningful semantics behind it | ||
lizmat | true | 11:00 | |
DIHWIDT | |||
nemokosch | like if I were to read it "either 1 or 2 is the key of this hash, with True as the value" | 11:01 | |
that would actually be a junction of two hashes | |||
but if somebody adds multiple junction keys, this interpretation either collapses or at least the number of cases will multiply and the whole thing becomes bloated in the blink of an eye | 11:02 | ||
lizmat | m: my %h{Mu} = (1|2) => 42; dd %h | 11:04 | |
camelia | Hash[Any,Mu %h = (my Any %{Mu} = any(1, 2) => 42) | ||
lizmat | if you want Junctions to be keys in an object hash | ||
nemokosch | yes, I anticipated this would work | 11:05 | |
anyway... It's not fun to be the party pooper but I think the way junctions are, the idea to count friday 13 through junctions is unsound | |||
lizmat | I would agree | 11:06 | |
nemokosch | in an alternative world there could be additive junctions that wouldn't collapse into a boolean value but a sum of the individual values | 11:07 | |
without that, the "most algebraic" solution seems to be to start from 1..12 and apply a "map-reduce" logic, transforming the value into 0's and 1's and summing them | 11:09 | ||
m: (1..12).map({ Date.new( 2023, $_, 13 ).day-of-week == 5 }).sum.say | 11:10 | ||
Raku eval | 2 | ||
librasteve | ^^ ++ | 11:11 | |
nemokosch | I'm personally biased towards this approach in general, it can be applied to a wide range of problems, the data flows in one direction and it's easy to intercept at any point (especially now with .snitch) | 11:12 | |
habere-et-disper | Looks like I stood on a junction in raku-beginner -- thank you everyone ! | 11:15 | |
'=D | |||
nemokosch | btw I could imagine a module that alters Date.new(2023, *, 13) in a way that it produces all the possible dates for this pattern | ||
In general I think the WhateverStar could be used in clever ways but it's fairly dangerous to try to guess a general case for its meaning | 11:16 | ||
it's more of a slangy thing | 11:17 | ||
there is another manifesto-like statement I wanted to make 😅 | 11:25 | ||
it's true that a simple and straightforward tool can be easier to understand and master | |||
lizmat | I can see * for months and day to be okish, but for years, that would be interesting ? | 11:26 | |
nemokosch | but it's also a virtue if one doesn't have to understand something in order to use it | ||
and this is what I do believe that Raku is not a "write-only language" | 11:27 | ||
not everyone reading code even reads that code with the intention to change it | |||
let alone radically change it | 11:28 | ||
on the other hand, this approach is drastically based on trust towards whoever gave you the high-level tool, and I am often concerned about that trust | 11:30 | ||
lizmat: um, yeah... part of the reason I can only imagine something like that in user space | 11:31 | ||
11:52
razetime left
12:09
razetime joined
12:24
siavash left
12:33
habere-et-disper left
|
|||
antononcube | A certain LLM prompt can be made for making "manifesto statements." | 14:09 | |
15:32
razetime left
15:50
Phytolizer joined
16:35
dakkar left
16:42
tea3po joined
16:45
teatwo left
17:24
Phytolizer left
18:44
tea3po left
18:46
teatime joined
19:01
Phytolizer joined
19:07
Phytolizer left,
Phytolizer joined
|
|||
SmokeMachine | m: say Date.new(2023, 1, 13), Date.new(2023, 2, 13) … * | 20:36 | |
camelia | (...) | ||
SmokeMachine | m: .say for (Date.new(2023, 1, 13), Date.new(2023, 2, 13) … *).head: 5 | 20:37 | |
camelia | 2023-01-13 2023-02-13 2023-02-14 2023-02-15 2023-02-16 |
||
nemokosch | it just uses succ probably | 20:40 | |
Phytolizer | m: .say for (Date.new(2023, 1, 13), *.later(:1month) ... *).head: 5 | 20:47 | |
camelia | 2023-01-13 2023-02-13 2023-03-13 2023-04-13 2023-05-13 |
||
librasteve | .say for ( Date.new(2023, 1, 13), *.later(:1month) ... *).head: 5 | 21:22 | |
seems that Discord swallowed a couple of stars... good way to get sequence of dates | 21:23 | ||
nemokosch | yeah, it was markdown for italics | 21:24 | |
Phytolizer | oh, ha. i guess that wouldn't show up on irc | 21:32 | |
21:41
Phytolizer left
|