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. |
|||
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 | www.youtube.com/watch?v=l0zPwhgWTgM 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 | ||
1False5 | |||
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 | |
cdn.discordapp.com/attachments/768...ions-1.png | |||
cdn.discordapp.com/attachments/768...ions-2.png | |||
cdn.discordapp.com/attachments/768...ions-3.png | |||
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 infix stopper postfix 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 | |
np | |||
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: pythonforprediction.wordpress.com/...-projects/ | ||
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 @pairs.map(-> ($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 design.raku.org/S03.html 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 |