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
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
nemokosch well, Nil is a type indeed 02:14
to be honest, thinking about it, I don't like that ().are(Nil) is True 02:16
is ().are(Str) or ().are(Int) also True?
seems like they are
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
nemokosch it's a bit tricky that $some-value.are ~~ SomeType is not the same as $some-value.are(SomeType)
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
nemokosch now that you added that line, let me ask you: was it clear to you that ().are(Int) is just as fine?
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
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.
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
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
Raku is a powerful language for a lot of things - it's not a powerful language to specify itself 02:23
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
nemokosch yes, the tests are sound but they are incomplete - blatantly incomplete 02:25
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
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/
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
I honestly think that having the implementation of the spec has a huge advantage completeness-wise 02:30
.s/of/as
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
nemokosch but I think we have been fooling ourselves for way too long pretending that it can define the language 02:32
the only thing that Roast says about ().are(SomeType) is that it returns True for Int
from which we extrapolate that it's probably meant for all types 02:33
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.
nemokosch that's fair enough 02:38
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 05:07 disbot12 left 05:08 disbot13 joined 09:43 arkiuat left
lizmat looks like $=pod doesn't have its own lemma what would be the best way to add that? 11:37
also:
at docs.raku.org/language/variables#The_=_twigil 11:38
it states:
=begin Foo
...
=end Foo
# after that, $=Foo gives you all Foo-Pod-blocks
which is simply incorrect. it now says for $=Foo in that case:
Pod variable $=Foo not yet implemented. Sorry.
also no lemma for Pod::To::Text, whereas that *is* installed in the core dist of Rakudo 11:40
only one mention of it in roast though, and probably not essential 12:03
so not sure if this is Raku or not
only one mention of it in roast though, and probably not essential 12:05
nemokosch docs.raku.org/type/IO/Socket/Async take a look at the sentence starting with "The CATCH phaser" 12:24
the example contains no CATCH - it contains QUIT, and goes on to explain the difference from CATCH 12:25
13:07 Nemokosch joined 13:09 Nemokosch left 14:06 Nemokosch joined 14:07 Nemokosch left
Geth doc/main: fa0ce42856 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | doc/Type/IO/Socket/Async.rakudoc
Change listening port from 8080 to 3333

To match with documentation		 14:58
[Coke] whoops 15:07
lizmat copypasted the example, and no server at 3333 then looked at the code and realized: aha! 15:23
Geth doc/main: df260016a7 | schultzdavid++ (committed using GitHub Web editor) | doc/Type/Any.rakudoc
Clarify parameters :$label and :$item of method map()

and update parameter name &block → &code		 16:46
[Coke] check-signatures currently failing because of Mu.does. In docs as method does(Mu $type --> Bool:D). 16:57
in rakudo source as method does(Mu \SELF: Mu $type) {
Can we declare the return type in rakudo or is that a performance issue? 16:58
the whole method is " nqp::hllbool(nqp::istype(SELF, $type.WHAT))"
lizmat checks
[Coke] sees that lizmat has fixed it in rakudo. neat. 17:16
lizmat it was an easy thing to fix :-) 17:17
[Coke] the test is only testing tags, I think, so it won't start passing until the next release. ah well. 17:18
Geth doc/main: 1ad5fffe79 | (Will Coleda)++ | doc/Type/Telemetry.rakudoc
Update types to have properly formatted links
 17:38
19:01 arkiuat joined 20:57 librasteve_ joined
nemokosch docs.raku.org/language/regexes#Pre...ed_Regexes that link in the table was meant to work, right? 22:21
[Coke] yup 23:00
will be fine when we switch to rakudoc v2, should prbably avoid it for now or move it out the table, either way with a ticket to rework it when that syntax works 23:01
nemokosch alright 23:03
[Coke] or convert the whole thing from table to items? 23:05
23:07 librasteve_ left
nemokosch I don't mind it that much - if this is something you are aware of and is on the way to be resolved, I honestly wouldn't bother 23:07
[Coke] OK. 23:58

Powered by Cro and the Raku® Programming Language.

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

Thank you!