00:11 arkiuat joined 00:16 arkiuat left 00:27 Nemokosch joined
Nemokosch bisectable: say ().are; 00:30
oops wrong chat
00:32 Nemokosch left
Geth doc: 2colours++ created pull request #4764:
Delete mistaken `().are` line		 00:37
doc/main: a3ccde6dd6 | (Márton Polgár)++ (committed using GitHub Web editor) | doc/Type/Any.rakudoc
Delete mistaken `().are` line (#4764)

It seems both out-of-place and incorrect: a bunch of paragraphs earlier the output for this was `Nil`
  (the only output this call has ever had)		 00:41
00:44 arkiuat joined 00:48 arkiuat left 01:06 kjp joined 01:11 arkiuat joined 01:16 arkiuat left 01:31 arkiuat joined 01:36 arkiuat left 01:55 arkiuat joined
arkiuat perhaps instead of deleting the `say ().are; # OUTPUT: True` line, it should have been changed to `say ().are(Nil);` instead 02:03
that does output True, and it seems to be what belongs there given the context.
referring to github.com/Raku/doc/pull/4764 02:04
[Coke] please feel free to update that directly. 02:08
disbot12 <arkiuat> yes, okay, I was commenting because I wasn't sure that was correct, but the longer I think about it the surer I get 02:10
arkiuat thanks for finding that though, Nemokosch! 02:12
disbot12 <nemokosch> well, Nil is a type indeed 02:14
<nemokosch> to be honest, thinking about it, I don't like that ().are(Nil) is True 02:16
<nemokosch> is ().are(Str) or ().are(Int) also True?
<nemokosch> seems like they are
<nemokosch> well, that makes sense then 02:17
Geth doc/main: 7ad9eea59a | (Eric Forste)++ (committed using GitHub Web editor) | doc/Type/Any.rakudoc
Correct example for .are method in Any.rakudoc

The example of a call on () was missing the type argument `Nil` that would make it make sense
disbot12 <nemokosch> it's a bit tricky that $some-value.are ~~ SomeType is not the same as $some-value.are(SomeType)
<nemokosch> it makes sense why but still
arkiuat well, whether it's a good feature or not, I'm pretty sure that's what the person who put that line in was attempting to document 02:18
disbot12 <nemokosch> now that you added that line, let me ask you: was it clear to you that ().are(Int) is just as fine?
<nemokosch> because now the example feels cherry-picked to me 02:19
arkiuat No, not at all. 02:20
I was just thinking about why that line was even there in the first place
The real question is what are the roast tests checking for; theoretically, the original writer wouldn't have documented that behavior if roast didn't specify it 02:21
disbot12 <nemokosch> because, like, this is what I would logically expect: no values satisfy any type constraint (or none, but any is more consistent with empty cases of products)
arkiuat If there's no roast test for it, then yeah, it should be deleted. I should have checked for that.
disbot12 <nemokosch> English is tricky - what I mean is that the lack of any value does satisfy whatever type constraint
arkiuat Nil acts in a lot of weird ways, and the way Nil acts, it just seemed clear to me that this was the intent. 02:22
disbot12 <nemokosch> which is also hard to write down in code... you know, there is a reason I have been complaining about Roast for an eternity
<nemokosch> Raku is a powerful language for a lot of things - it's not a powerful language to specify itself 02:23
<nemokosch> plain English language is much more powerful
arkiuat plain English language is very difficult to free of ambiguity though, and the roast test do have the advantage of being relatively unambiguous 02:24
disbot12 <nemokosch> yes, the tests are sound but they are incomplete - blatantly incomplete 02:25
<nemokosch> it would be hard to even estimate the measure of this incompletion; basically we get to cover a non-measurable part of the language 02:26
<nemokosch> this is not a theoretical issue either - try to look up anything in Roast and see how far you get without extrapolation 02:27
arkiuat incomplete and unambiguous is better than incomplete and ambiguous though. It's difficult to guarantee the completeness of an English-language spec too
I mean Roast is just a historical reaction to the situation with Perl, where the only spec was the implementation, which was not great. 02:28
s/was/is/
disbot12 <nemokosch> my point has always been that the difference is between difficult as in playing the Minute waltz from Chopin on the piano is difficult, versus impossible, as in drain a river with a sieve
<nemokosch> I honestly think that having the implementation of the spec has a huge advantage completeness-wise 02:30
<nemokosch> .s/of/as
<nemokosch> that's not to say Roast isn't good for something 02:31
arkiuat the behavior in question is roasted, btw. Line 14 of github.com/Raku/roast/blob/7f2d750...y/are.t#L6
disbot12 <nemokosch> but I think we have been fooling ourselves for way too long pretending that it can define the language 02:32
<nemokosch> the only thing that Roast says about ().are(SomeType) is that it returns True for Int
<nemokosch> from which we extrapolate that it's probably meant for all types 02:33
<nemokosch> this is the kind of situation where I think even a comment like # should be True for all types would make a huge difference regarding definedness 02:35
Geth doc/main: 837e9db92e | (Eric Forste)++ (committed using GitHub Web editor) | doc/Type/Any.rakudoc
Change expected type from Nil to Int in Any.rakudoc

changing the example from type Nil to type Int (which is what roast specifically checks for)		 02:37
arkiuat yeah, I'm not to concerned about it, I just think it is better to have it documented than not, that's all.
disbot12 <nemokosch> that's fair enough 02:38
<nemokosch> for me this is one of the biggest language design concerns that is barely touched in this specific situation 02:39
03:16 kjp left, kjp joined 03:38 arkiuat left 03:40 arkiuat joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!