This channel is intended for people just starting with the Raku Programming Language ( Logs are available at
Set by lizmat on 8 June 2022.
00:17 deoac joined 02:00 deoac left 03:33 razetime joined 04:06 razetime left 06:00 razetime joined 07:33 vlad joined 07:50 Manifest0 joined 08:02 razetime left, vlad left 08:17 teatwo left 08:18 teatwo joined 08:19 tea3po joined 08:22 teatwo left 08:27 razetime joined 09:11 wafflus joined 09:15 ab5tract joined
wafflus dd 09:16
I'm a little bit confused with how raku syntax and how it matches things is this true and what is happaning  here (2,2,2 ~~ one(4,7,1)).Bool 09:17
says its True 09:18
how can it be true 09:20
Nahita precedence 09:21
you're making a nonempty list first
then check its bool status
m: put (2,2,2 ~~ one(4,7,1))
Raku eval 2 2 False
Nahita m: put (2,2,2 ~~ one(4,7,1)).raku
Raku eval (2, 2, Bool::False)
Nahita what did you mean to do instead 09:22
wafflus i didnt really mean do do anything i'm just compating different ways trying to understand how it works it seamingly does random things atms to me lol 09:23
Nahita i see, cool
wafflus i kind of udnestand what happans when i compare a single value but not one i do multiple values
 5,2 == 2,5 whi is this (5 True 5) 09:24
Nahita yeah comma has very low precedence
wafflus btw ty for the earlier explnation i understand i was compating True to true i reality
Nahita np 09:25
wafflus i asked ai to look at my code it says it wan't valid  rakue syntax lol
Nahita lol
wafflus would it be possible to do something like [1/2/3/4] instead of [1,2,3,4] 09:28
nemokosch wafflus: with what meaning? 10:13
Like, I think the way you wrote it, it would actually do something as it stands now 10:14
m: [1/2/3/4].&dd
Raku eval [<1/24>]
nemokosch A one-element array of a rational number 10:15
wafflus i wanted to use comething diffrent than comma as array and list element seperators it can sometime be confusing
something 10:17
it appears there is something 10:18
maybe i can use <> instead 10:19
nemokosch I would rather not overload an existing operator for this purpose 10:20
wafflus hmm what a weird thing an IntStr
nemokosch I'm not super fond of IntStr 10:21
It's like a superposition of an Int and a Str
wafflus i guess an intStre means a string that is safe do do conversion on? 10:22
either explicit or inplicit
nemokosch It's actually pre-converted
It's something that has two faces: a string value with a string interface and an integer value with an integer interface 10:23
wafflus m: <<1 2 3 4>>.map(* ~ "pies");<<1 2 3 4>>.map(* + *)
camelia ( no output )
wafflus m: <<1 2 3 4>>.map(* ~ "pies")
camelia ( no output )
nemokosch You need to write to the output
wafflus k it was using the repl 10:24
nemokosch If you call Int methods on it, the Int value will be used, if you use Str methods, the Str value will be used
wafflus i'm just trying to avoid using ,
ok thanks 10:25
nemokosch m: <01 04>.map(* ~ " doggo").say 10:26
Raku eval (01 doggo 04 doggo)
wafflus like sometimes its a list and sometimes it not or you should have used brackets
nemokosch There is a fundamental difference between <> or <<>> versus the comma stuff 10:27
wafflus yeah well ideally we would have a diffrent sepeat than a , :(
nemokosch I don't think this is deliberate, there is no way around <> and <<>> work differently - ironically you like this behavior more 10:28
The comma is actually an infix operator that builds lists
this can be seen if I use an operator that has even lower precedence 10:30
wafflus yeah and also an argument seperator and also the brackets are sometimes optional and also breackets are used to group things and for function calls
nemokosch m: 1, 2, 'foo', 4 ~~ one(5, 6), -12, [6] andthen .say 10:31
Raku eval (1 2 foo False -12 [6])
nemokosch yes, I think the two first-class meanings of the comma are: an infix operator and an argument separator 10:32
the round parens have two meanings the same way: indicating the argument list for a function/method call, and clarifying precedence, like in math 10:33
these two meanings serve the same purpose: to clarify the data flow in an expression 10:34
wafflus yep and an extra space can change the meaning of the program :|
nemokosch there are several ways where that's the case 10:35
a trivial example would be composite operators
if an operator consists of multiple characters, you probably shouldn't split it up
wafflus i remebe watching a tutorial by derek bannanas and he did that but eneed up geetting the same result but i was sure it was a bug
he wanted to do a function call but ended up formating a list and got the same result 10:36
nemokosch I get why you might think that way. It's something to get used to.
There is actually a legitimate reason for this I think 10:37
wafflus its like this is not required and then you don't use brackets and find it doesn't work so end up mayve overusing brackets because your not sure what is happaning 10:38
nemokosch Raku's vocab is heavily overloaded and in addition, it's designed to be parsed in one go, radically allowing for symbols to downright switch the parsing to another grammar on the go 10:39
wafflus i can post a link to the video if you want and give you a time stamp
@nemo cool
nemokosch sure, why not
wafflus sec i will ned to watch the video i won't tell you where the bug is and spoil the fun for you
nemokosch I think < and << actually are things that switch the grammar, I'd have to check but I think they do 10:40
at least in theory they could. quotes in general have a different grammar from the main Raku syntax 10:41
wafflus timestamp 8:53 10:42
he is getting the output the wants buti'm sure that counts as a bug 10:43
nemokosch which one do you mean?
wafflus the say()
nemokosch ohh 10:44
wafflus i think i'm correct or being a total noob
nemokosch you are right
wafflus for once :D 10:45
nemokosch yeah "you can see it works" but in fact it didn't print any of "1/4 + 1/2 = "
it just printed the result of 1/4 + 1/2, which is rational 3/4
say returns with True and True got formatted into that expression, after that, it got thrown away 10:46
wafflus yep
nemokosch m: say(1/4 + 1/2).fmt("1/4 + 1/2 = %.2f").&dd
Raku eval 0.75 "1/4 + 1/2 = 1.00"
nemokosch this is what the final value of that expression was, before it got thrown away 10:47
to go back to list creation: do you get that the round parens have no special meaning regarding lists? 10:48
wafflus ok so no precedane changing?
nemokosch they are the same parens as in an expression like (1 + 2) * 3 10:49
there is precedence changing but nothing else besides
wafflus m:2 == 4,5&dd 10:51
m:say 2 == 4,5&dd
nemokosch maybe you need the space for the bot to trigger?
wafflus [16] > say 1,2 == 4,5
like it looks like i'm comparing two lists not sure how it get back that result 10:52
nemokosch you are kind of trying to do something that the joke language Dreamberd makes fun of: set precedence by the amount of spaces added 10:53
(there is at least one situation where Raku does this but generally not, thank heavens)
m: say 1 , 2 == 4 , 5 10:54
Raku eval 1False5
wafflus oh ok
nemokosch this has been 3 arguments passed into say all along
m: say(1 , 2 == 4 , 5) 10:55
Raku eval 1False5
nemokosch oh right, let's "double the trouble"
m: say((1 , 2 == 4 , 5)) # now this is surely one list
Raku eval (1 False 5)
nemokosch indeed, it is one list, and this amount of spaces makes it look like that 10:56
== has higher precedence than ,
wafflus m: say: "d",5 10:59
camelia WARNINGS for <tmp>:
Useless use of constant integer 5 in sink context (lines 1, 1)
Useless use of constant string "d" in sink context (lines 1, 1)
nemokosch now I wonder how this parsed, now that you added a colon after say 11:00
I thought this would be the same as "d".say(5)
m: "d".say(5) 11:01
Raku eval Exit code: 1 Cannot resolve caller print(Str:D: BOOTStr); none of these signatures matches: (Mu: *%_) in block <unit> at main.raku line 1
nemokosch apparently not
wafflus maybe it only works in the repl
nemokosch the REPL shouldn't have different grammar, at least 11:02
wafflus i mean the first one i did
nemokosch what was the result?
wafflus not your one i test your one same result
[21] > say: "d" ,5
(d 5)
i guess it convert the 5 to a string 11:03
nemokosch okay so apparently say: "d" returns just "d" for some reason...
from which point on this is really just "d", 5...
wafflus oh sorry it doesnt convert the 5 it keeps it as an int
nemokosch m: (say: "d").&dd
Raku eval "d"
nemokosch I think this is time to ask the parser what it saw 11:04
gonna use raku --target=parse
wafflus looks on in wonder and amazment
nemokosch you can run it in the terminal, too, it won't explode 😄 11:05
raku --target=parse -e 'say: "d"'
with say: "d", 5 it's even more visible 11:06
wafflus oh cool though it wont work on windows
thats a cool feature
the parsing not the windows thing :) 11:07
not bashing
nemokosch so it seems that say: got interpreted as a label
the reason, though, is not clear
looking up the docs, labels are only for loops 11:08
we had no loops
11:09 NemokoschKiwi joined
NemokoschKiwi bisectable6 is not here, I guess to avoid spamming 11:09
but if you check in #raku, I can show you another IRC bot that can be used to investigate the output on different builds of Rakudo 11:10
11:13 ab5tract left 11:14 ab5tract joined 11:20 NemokoschKiwi left 11:56 wafflus left 12:17 jgaz left 12:54 razetime left
antononcube In order to increase the LLM-usage awareness, here is an image sequence that might be useful to a certain avid Raku-forums participant: 13:13
13:15 wafflus joined
wafflus in one line is it possible to do sometjing like take two ranges or lists and concat them toghter something like this 13:18
m: say 1, 2, 3 | 5...7
camelia (1 2 3 4 5 6 7)
wafflus ecept i want it to go 1 2 3 4 5 6 7 13:19
so someting like [+] 1..3 | 5..7
i mea 1 2 3 5 6 7 13:21
antononcube @wafflus For example: [|(1,2,3), |(5...7)].
wafflus when i do  1...5,7...8 i get the corret list but i can not [+] over ut
oh cool 13:22
antononcube Try [+] (1...5, 7...8).List . 13:23
@wafflus This also works for me: [+] 1...5, 7...8 13:24
wafflus it works but isnt the result incorrect 13:26
m: say [+]1,2,3,5,6,7 13:27
camelia ===SORRY!=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> say [+]⏏51,2,3,5,6,7
expecting any of:
infix stopper
statement end
statement modi…
wafflus m: say [+] (1,2,3,5,6,7) 13:28
camelia 24
wafflus m: say [+] (1..3,5..7)
camelia 6
wafflus m: say [+] (1...3,5...7) 13:29
camelia 18
wafflus your earlier example works though not sure what the | does at the beginning 13:31
anways i think i can do it syntax  may take some getting used to 13:33
antononcube @wafflus You examples above introduces a new specification using ranges -- (1..3,5..7) this is a list of two ranges, not a list (or sequence) of the corresponding numbers. 13:34
wafflus yes i know i also did two lists as well 13:35
antononcube I see what you are saying -- no, the "comma junction" does not work as intuitive to a newcomer in those cases 13:42
wafflus conufsinlg if i put a range or a list into variable i can do 1..3,|($r)
nemokosch please don't use ... chained 13:43
wafflus welli kind of understand ty
nemokosch .. is fine though
... chained will make crazy guesses about what you wanted to do 13:44
librasteve ^^ I agree ... three dots is the Sequence operator and quite different from the two dots .. Range operator and chaining two of them with a comma is, well weird
wafflus i'm combining a list and a sequnce toghter ?
nemokosch m: say (1 ... 7, 4 ... 8) 13:45
Raku eval (1 2 3 4 5 6 8)
antononcube Hence, stick with [|(1,2,3), |(5...7)] . The symbol | is a "slip" : in flattens or embeds the array or list elements into the list or signature it is used in.
nemokosch if you know what is going on with my snippet, please call the hospital and treat my sanity 13:46
wafflus lol
m: say  1,2,3,((5...7).flat)
camelia 123(5 6 7)
antononcube I am sure people have called hospitals on your behalf many times.
librasteve chaining two Sequence should be a bug
nemokosch meh, you're right probably
wafflus loony hospital? 13:47
librasteve (well it should generate an error)
antononcube (Sorry, could not help it... Too much of a low hunging fruit.)
nemokosch I agree it should and it wouldn't be very difficult to do
wafflus raku seems like magic ohter time i think this shouldnt work
nemokosch but it's a breaking change
librasteve well it can go in 6.e then 13:48
wafflus is there a better way that doesn involve multple linse of code?
nemokosch let's check if there is an issue for it
wafflus: what are you trying to achieve, again?
I think some snippets from Anton were right
antononcube Hmm... How so? (If not too hard to explain...)
nemokosch I mean, ... can be chained now, and possibly there is code out there that makes use of that 13:49
whether the behavior is weird or not
wafflus [+](1,2,3,5,6,7) is what i want but  i didnt waned to use two ranges or two list
i wanted to combine two different ranges or lists
antononcube All my snippets are right !!! (@wafflus goals notwithstanding.)
nemokosch this code is for calculating the sum of a list 13:50
wafflus :D
i dunno why that is so big
nemokosch there is no operator for "flat concatenation" of lists, if that's what you mean 13:51
you can concatenate slips on the other hand
m: (|(1..3), |(7..9)).say
Raku eval (1 2 3 7 8 9)
wafflus how would you reccomend i do such a thing?
 m: ((1..3), |(7..9)).say 13:52
camelia (1..3 7 8 9)
nemokosch this would be safe with ... as well btw, the behavior is a bit different
of course you could define your own operator as well 13:53
wafflus m: [+] (|(1..3), |(7..9)).say
camelia Potential difficulties:
Useless use of [+] in sink context
at <tmp>:1
------> <BOL>⏏[+] (|(1..3), |(7..9)).say
(1 2 3 7 8 9)
nemokosch m: sub infix:<concat>($a, $b) { |$a, |$b }; (1..3) concat (7..9) andthen .say 13:54
Raku eval (1 2 3 7 8 9)
wafflus oh cool
librasteve m: say [+] ( 1..3, 5..7 )>>.Slip.flat
Raku eval 24
nemokosch hm, is flat needed?
wafflus k will have to research what a slip is and what >> does
nemokosch m: say [+] ( 1..3, 5..7 )>>.Slip
Raku eval 6
librasteve ^^ try it 13:55
_elcaro_ I did look at this the other day when you mentioned it. If i recall, It parses as (1 ... (7, 4) ... 8)
nemokosch it is apparently
yes, it does
it has always done that, that's why it can appear so clever 13:56
it inspects the lists
_elcaro_ I think of it as a DIHWIDT
nemokosch m: say([+] ( 1..3, 5..7 )>>.Slip); # nope say([+] ( 1..3, 5..7).map(&slip); # maybe? 13:57
Raku eval Exit code: 1 ===SORRY!=== Error while compiling /home/glot/main.raku Unable to parse expression in argument list; couldn't find final ')' (corresponding starter was at line 2) at /home/glot/main.raku:2 ------> y([+] ( 1..3, 5..7).map(&slip); # maybe?⏏<EOL> expecting any of: argument list
nemokosch oh I missed a paren
m: say([+] ( 1..3, 5..7 )>>.Slip); # nope say([+] ( 1..3, 5..7).map(&slip)); # maybe?
Raku eval 6 24
_elcaro_ (1..3,5..7).map(|*) will also work
nemokosch it works with map, only not with the hyper method call
re DIHWIDT: if it really was so, it could just deny chaining. However, it is actually designed in a way that embraces chaining (list associative) 13:59
I think we are going overboard tbh
antononcube @wafflus Raku is a very user friendly language. It is just very careful at picking up its friends.
librasteve i think that the slip operator '|' prepares a Slip object - a Slip object is a think that will autoflatten when it is iterated as part of an outer list
13:59 ab5tract left
nemokosch this was meant to be beginner-friendly... or something 😅 13:59
wafflus lol 14:00
i learned something
antononcube (That is why there so ~few~ many of them.)
_elcaro_ Everything is a tradeoff. The chaining allows it to do some clever stuff... but you shouldn't try to be too clever with it 🤔 14:01
14:01 ab5tract joined
nemokosch you know the Zen of Python, right? 14:01
"If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea."
librasteve yeah so raku is the unpython 14:02
nemokosch this is a classified case of doing the opposite
antononcube That is a paraphrased UNIX quote, BTW...
_elcaro_ I know the Zen of Python. I don't think much of it when a language that touts explicit is better than implicit has implicit variable declarations
librasteve antipython
nemokosch I think this statement is valid regardless of choices
and here we have not only an implementation that is downright undecipherable 14:03
but even the behavior is undecipherable
this is not okay
things that are impossible to teach shouldn't be invented
antononcube Relevant, self prmoting clickbait:
nemokosch unless the whole purpose is obscurity 14:04
Pythonitis appears on two places 😯 14:05
anyway, the point is, anything that makes you feel you are at the mercy of the underlying tool, is bad 14:06
librasteve well - the purpose is definitely not obscurity - but at least here on beginner, perhaps we should focus on what are the langiage feautres and how they work (rather than complain that the raku source code needs improving, eh?)
_elcaro_ I think the whole Zen thing was purposely meant to be a joke anyways. Like the one about "only one way" to do things uses em-dashes in 2 different ways... because there's no consensus on the way to use them.
librasteve I agree that the feature of chained Sequence operators is hard to understand
nemokosch I think the Zen thing contains actual exclamations about value choices 14:07
librasteve but I do not know where this is documented and therefore I hold judgement on how hard it is to teach until I have better understanding of hwat is the design intent
nemokosch and like regardless of where it comes from, it is just true
if the implementation is hard to explain, it really is a bad idea, no matter who says it
_elcaro_ Raku values do no need to align with Python values... and for that reason it has made different choices
librasteve so, I would like to try to make it easy to undertsand (and explain) 14:08
nemokosch but here it contradicts something that is just common sense
man, I hate myself for pointing out that this appeared in the Zen of Python
I didn't think it would make things this much harder
there is "easy things should be easy and hard things possible", do you like this more? 14:09
if something is unteachable, that's "easy things impossible"
_elcaro_ Heh, it's fine.. I know where your coming from, and putting "Python" in there didn't affect my take on it. 14:10
nemokosch and this is a recurring experience of mine. There are many examples of "easy things are impossible"
the whole modularity resolution is a big "easy things impossible"
if ... was resorted for generating one sequence, it would do one thing just fine 14:11
antononcube Yeah, for different reasons. 14:14
nemokosch you could define the starting elements, maybe there could even be some pattern deduction 14:15
then you could define your generator function and the terminal value/condition
this could work, there is no reason it couldn't
this is how people use ... anyway 14:16
antononcube That is why my most important ML packages are implemented in multiple languages.
nemokosch but somebody thought that something like 1, 2 ... 4, 5, 10 ... 22 would look cool 14:17
another person thought that the best way to support this would be to inspect all the lists that the list associative ... receives and try to make guesses based on the content 14:18
_elcaro_ Often Raku takes a novel idea and says "what if we extend this further". It sometimes leads to things that can be hard to understand. I recall similar discussions came up around .toggle with multiple expressions. But I love that toggle does that... and I love that Raku pushes ideas like that. We need languages that do that. re: ... I think also the "Huffman coding" design principle is also at play here.
Fairly common sequences, such as (x...y...x) are easy to express... less common sequences such as (|(x ... y),|(w...z)) require a little more effor
nemokosch it's all high-level language, first-class stuff
and they didn't think about the implications of that
they tried to make it behave unlike how it reads 14:19
and this is the "root of all evil" as they speak
I'm not sure how valid your judgement is when you say (x...y...x) is more common than (|(x...y),|(w...z)) 14:20
I wouldn't dare to state that
librasteve m: say 1 ... 5 ... 1
Raku eval (1 2 3 4 5 4 3 2 1)
librasteve m: say 1,3 ... 5,3 ... 1 14:21
Raku eval (1 3 5 3 1)
librasteve ^^ those two things seem pretty easy to understand to me
nemokosch m: say 1,3 ... 5,2 ... 1
Raku eval (1 3 5 2 1)
wafflus @nemokosch i'm wondering would  it be worth submitting your sub and making it part of the officall language spec i think its quite cool and i makes the syntax a little simpler
maybe also adding an alternative operator as well as the word concat 14:22
nemokosch m: say 5, 2 ... 1
Raku eval (5 2)
nemokosch @librasteve the problem is, by merely changing the values, the intuition disappears
librasteve m: say 1 ... 3,5 ... 7
Raku eval (1 2 3 5 7)
nemokosch m: say 1 ... 3,4 ... 7
Raku eval (1 2 3 4 5 6 7)
nemokosch 🤪 14:23
librasteve ^^ so this is what happens with our bad boy from above
the second ... is using 3,5 ... 7 for the second part and thus jumps with +2
nemokosch wafflus: you may even be right but I can't support it at this point; I'm in the camp of "we have too much stuff already" 14:24
if there was an option to throw something out and take this instead, I'd be for it
antononcube Did they call the loony hospital?
wafflus :O
nemokosch I called it myself :DD
librasteve see you thre 14:25
nemokosch re ...: think of people who want to create a sequence of Ranges. There is nothing crazy about that, except that the hack ... is won't let you do it
antononcube You two can start a Raku club... 14:26
nemokosch because for ... that argument will be treated as a list, and the usual woodoo starts on its values!
antononcube That would, of course, be dissolved when discovered... 14:27
wafflus yeah sometimes it  maybe be a little bit confusing if its the range it self or generated list
_elcaro_ I'm always willing to admit I'm wrong. In fact it's often better for me to always assume I'm wrong 😄 so on that note... my perspective is that expressing my "less common" sequence as a literal probably doesn't come up often. I don't think the sequence is uncommon, but maybe trying to do it in a literal expression like that might be. I'd suspect it more comes up as creating a list of ranges between 14:28
pairs, where you might do something like> ($x, $y) { |($x .. $y) })
FWIW I'm not trying to convince you I am right, or you are wrong... things are not always so absolute. 14:29
librasteve m: say 1...3...1...5...1...7...1...9
Raku eval (1 2 3 2 1 2 3 4 5 4 3 2 1 2 3 4 5 6 7 6 5 4 3 2 1 2 3 4 5 6 7 8 9)
nemokosch You are right that things aren't always so absolute, and I'm not saying they are
I'm saying, thought, that sometimes they are absolute
sometimes there is a right and a wrong
librasteve .oO
nemokosch and factual evidence and rational arguments allow us to figure out which is which 14:30
much more than emotions
librasteve in fact the docs are missing some example of this ... chaining - they are here in the design docs line 2103 14:31
nemokosch sometimes you will correct me if I state 6*9 was 55
and that's a good thing
_elcaro_ wait... lemme get my calculator 😁
What sub? 14:32
librasteve so now I have read the manual, I do think that I can explain this quite easily - it's only a bit further up the learning curve than sequence like 1,3,*+*...* 14:33
nemokosch but the behavior we get is not useful, the way it changes if your values don't align perfectly 14:34
it's actively pushing me over the limit that we are so willing to care about the personal taste and emotions of Raku designers and implementors - OVER the feelings of people who try to learn this language 14:35
antononcube @elcaro ⎡I'm always willing to admit I'm wrong. In fact it's often better for me to always assume I'm wrong [...]⎦ -- I am also anxious, eager, and willing to make this claim. (I only loosely adhere to it, if at all...)
librasteve I disagree
nemokosch it's not something I would ever ask for, when I'm working on something
being frustrated over something that doesn't turn out great is okay 14:36
librasteve why - because I think that raku syntax is easy to learn and approachable and that you do not have to go into the complex corners unless you want more
_elcaro_ It's harder that you'd think... given the amount of times our own wrongness is borne out.
nemokosch everybody can get frustrated, it's only natural 14:37
but to keep acting upon your personal comfort and taste when basically doing a service...
librasteve I do think that we fail to apply a principle of keeping the easy things easy 14:38
antononcube BTW, in case it is not clear, I was not expressing doubts that you adhere to that principle. 14:39
librasteve I do think it's fair to say "don't chain the ... sequence operator unless you know what you are doing" 14:40
much as I would say "don't use the MOP unless you know what you are doing"
_elcaro_ I didn't take it that way... just echoing your sentiment that it's not easy to adhere to
nemokosch you know, the point is also that the chainability of ... actively takes away from you, because it's not syntax 14:41
there is no difference between 3, 4, 5 appearing in that chain and $scope appearing in that chain, if it happens to have the value (3, 4, 5) or possibly even (3 .. 5) 14:42
meaning that you have a feature that won't work well if your items are compound data structures 14:43