|
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:49
habere-et-disper left
01:01
MasterDuke joined
02:24
tea3po joined
02:27
teatwo left
10:06
habere-et-disper joined
10:58
habere-et-disper left
12:05
habere-et-disper joined
12:24
habere-et-disper left
14:02
habere-et-disper joined
14:11
habere-et-disper left
14:31
tea3po left,
tea3po joined
14:33
teatwo joined
14:36
tea3po left
19:21
ab5tract joined
20:01
ab5tract left
20:45
habere-et-disper left
|
|||
| Tirifto | Does fat arrow pair declaration work with line breaks or not? :o | 22:45 | |
| nemokosch | see it for yourself 😛 | 22:46 | |
| Tirifto | I ask because I’m not sure what I’m seeing. x) In the REPL and a dead-simple test file, it seems to work alright. But then I have some longer code where the compiler reports a bogus statement. I guess I should try and reproduce it in a simpler example… | 22:47 | |
| nemokosch | yep... I would be curious where it didn't work | 22:50 | |
| Tirifto | Okay, I’ve got it! I guess this is just a more general syntax rule that I’ve overlooked. The problem arises when I try to use a block as the key, followed by a newline, then followed by the fat arrow. It seems like that’s not a valid way to use the block as a key. | 22:57 | |
| Example code: tirifto.xwx.moe/d/pairs.raku | 22:58 | ||
| nemokosch | yes, and most importantly it's not a good idea. You most probably won't be able to look that piece of code up later, unless maybe if you always pass the same reference of a code object into the hash | 23:00 | |
| Tirifto | Oh, I was trying to make a list of pairs, not a hash table. | 23:02 | |
| nemokosch | hm, fair enough, but then I have even less idea why | 23:03 | |
| I guess it's time for the mandatory disclaimer: regardless the name, a "pair" is not meant to represent a symmetric two-element tuple | |||
| it's better thought of as (possibly mutable, as in lvalue) data, with a custom name | 23:04 | ||
| it's a good data structure to back up named arguments and hash entries | 23:05 | ||
| Tirifto | Ah, interesting. | ||
| nemokosch | if you want a two-element, conceptually horizontal tuple, just use a list with two elements | 23:06 | |
| Tirifto | I’m writing a simple game for a jam, and I’m looking for an elegant way of declaring conversations the player can initiate. Each conversation has a list of topics the player can talk about. Each topic has a string identifier (shown to the player), a block of test code (which returns True if the topic should be available), and a block of content code (which presumably makes the characters talk). | ||
| nemokosch | you might argue that the built-in List is not truly immutable and therefore not really "hashable" in the Pythonic sense - however, this is absolutely true for a Pair as well | 23:07 | |
| Tirifto | I was looking to declare (Str => Block => Block) with the arrows on new lines, because that looks really pretty and fairly readable. But I guess I’ll have to do @(Str, Block, Block) instead. x) | 23:08 | |
| nemokosch | the "hashability" might come handy for the strings, depending on the way you want to use it | 23:09 | |
| so it might actually be useful to do Str => (Block, Block) | |||
| Tirifto | Hmmm… I’ll see which one looks better then! | 23:20 | |
| kjp | Tirifto: If you have a block with a right-brace at the end of a line, there is an implied semicolon after the brace. (In general, a block needs a semicolon after it; this rule means you can omit most of them.) | 23:32 | |
| Tirifto | Ohh, I hadn’t realised. | 23:53 | |
| Now I understand what happened. | 23:54 | ||