| 30 Nov 2022 | |||
| Nemokosch | Anyways, this is not only a lot of work with minor breaking changes everywhere but I frankly have no idea how `Str $smallest = $input.words.min` will ever work with it. | 16:51 | |
| when $input happens to contain no words | 16:52 | ||
| lizmat | that would never work | ||
| or: that would only work if it returned Nil | |||
| fwiw, I think the behaviour of .min and .max predates the existence of Nil | 16:53 | ||
| Nemokosch | does this possibly mean that the "old design documents" have no knowledge of Nil? | 16:56 | |
| lizmat | could well be | 17:06 | |
| nine_ | Actually Nil gets mentioned a lot by those docs | 17:07 | |
| design.raku.org/S02.html#Nil | 17:08 | ||
| "Assigning Nil to any scalar container causes the container to throw out any contents and restore itself to an uninitialized state". If we treated -Inf and Inf the same way for any non-numericly typed container, Str $smallest = $input.words.min; would get you an undefined Str | 17:10 | ||
| lizmat | the text of Nil is from 2015, the text of method min/max is from 2012 | 17:11 | |
| in S32-setting-library/Containers.pod | |||
| so I think my feeling in that regards is correct :-) | |||
| nine_ | Contrary to what I've so far written may sound, turning Inf into another Nil doesn't sound like a winning strategy to me. It just bothers me when people talk about language design while dismissing the actual design documents. A lot of thought already went into the language to make it as awesomely consistent as it is. I'd hate for that to get drowned in a sea of bolted on solutions for odd corner cases. | 17:14 | |
| I wonder, if turning Inf into a Nily thing doesn't work out. Can we turn Nil into Inf instead? I.e. make Nil be larger than the largest value and smaller than the smallest value for any type? | 17:16 | ||
| Nemokosch | I'm about to finish my comment | 17:23 | |
| I can say the same thing here as well, though. Design documents can be useful or not useful - just like the design itself can be good or bad. | 17:27 | ||
| In many cases, the design documents are super useful - here, whether you call it "dismissing" or not, I think the design document itself is totally unconvincing. | 17:28 | ||
| So I can say the same way that it bothers me when people talk about an admitted language design proposal just by reciting an old, unmaintained document that has proven to cause problems for many people in real-life scenarios. | 17:29 | ||
| (I intentionally phrased this in a radical way, to illustrate how your sentiment sounded to me.) | 17:30 | ||
| Anyways, my impression is that there is a friction within the core regarding design documents, even more so than breaking changes. Some people say they are mostly historical documents, others say they would just need a little maintenance work to be virtually authoritative. | 17:39 | ||
| steering back towards Nil & friends - I'm not sure if Nil can be the biggest and the smallest value without breaking algebra... also, fun fact: Nil acts as 0 with `min` and `max`; I'm not sure if this is intended | 17:44 | ||
| and `0 cmp Nil` says "Use of Nil in string context"... | 17:48 | ||
| nine_ | Of course, right now Nil isn't a working replacement for Inf. But maybe it could be? | 17:53 | |
| Nemokosch | I think this is a very dangerous territory, possibly the term "strangely consistent" would fit here. Let's say Nil could be a minimum and a maximum. Does that mean Nil < Nil? What about Nil >= Nil, then? And so on. | 17:54 | |
| Geth | rakudo: 6cded78e9a | (Elizabeth Mattijsen)++ | src/core.c/Code.pm6 Make two WhateverCodes non-equivalent if different In response to github.com/rakudo/rakudo/issues/5116 infix:<eqv> falls back to the calling .raku if two objects are of the same type. This makes sure that WhateverCode.raku will produce different strings for different WhateverCode objects. |
18:04 | |
| roast: e4f4f0945d | (Elizabeth Mattijsen)++ | S03-operators/eqv.t Add tests for WhateverCode equivalence See github.com/rakudo/rakudo/issues/5116 |
18:12 | ||
| leont | lizmat++ # that was a much quicker fix than I expected :-) | 18:22 | |
| lizmat | it was basically cat-licensed from Block.raku | 18:23 | |
| the only thing tricky was referencing $!signature like that: it needed the nqp::getattr() as the attribute is not known in HLL space | 18:24 | ||
| Nemokosch | What does HLL stand for? | 18:27 | |
| nine_ | High Level Language | 18:29 | |
| [Coke] | like raku, perl, etc. as opposed to nqp, or moarvm bytecode (or PIR if you're as old as I am) | 18:31 | |
| Nemokosch | that's in the PAST 😛 | ||
| nine_ | Depending on context, NQP may also be a HLL | ||
| Nemokosch | oh okay, so it's an umbrella term? | 18:35 | |
| In my mind, it was a mysterious third thing besides Raku and NQP 😅 | 18:36 | ||
| [Coke] | nine: fair; could just be "higher in the chain than what I'm writing in currently" | 18:56 | |
| 1 Dec 2022 | |||
| could use someone to look at github.com/Raku/doc/issues/4058 | 21:42 | ||
| 2 Dec 2022 | |||
| Geth | rakudo: vrurg++ created pull request #5117: RakuAST origins (provenance) |
04:09 | |