🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). Log available at irclogs.raku.org/raku/live.html . If you're a beginner, you can also check out the #raku-beginner channel!
Set by lizmat on 6 September 2022.
guifa Actually on further thought, I don't think it fails because negatives numbers don't have literals 00:12
I'm fairly certain 2e1 will compile as a literal 00:13
And it's fairly reasonable to forbid that in the colon syntax: :2e1foo makes my eyes awnt to bleed lol
Nemokosch Hm, I think this is a logical fallacy, could be one on both of our sides 00:21
guifa I've always seen :2a as a useful short hand for some contexts allowed because numbers can't validly begin identifiers 00:22
guifa . o O ( although if someone wrote a slang making <ident> start with <alnum> instead of <alpha> ... )
Nemokosch ":-1a only doesn't work because negative numbers don't have literals" <=> "by changing only one thing - to support negative numbers as literals - :-1a would start working" 00:23
I think you don't disprove that by saying "there are literals that don't work with this colon pair syntax" 00:24
I definitely feel less positive about :2e1foo than :-1a, gotta give you that
guifa And then Rats too! 00:25
:1/2foo
oh
what's the correct interpretation of :i :-) 00:26
that's a literal number after all hahaha
Nemokosch :1.2foo looks fine by me, to be honest
are you sure it is a literal and not an operator?
guifa it's a term 00:27
say i.WHAT
evalable6 (Complex)
Nemokosch oh okay, the sole i is indeed a term
guifa say :٧foo 00:28
evalable6
guifa say :7foo
evalable6
guifa hmm, both compile on that, so it is using <digit> at least
Nemokosch and now imagine
that sub foo( --> i) {} works but sub foo( --> -1) {} doesn't... 00:29
I kinda hope this feels anomalistic enough not only for me haha
guifa I think that situation could be solved by allowing anything known at compile time
guifa says as if that's simple
That would allow something like 00:30
Nemokosch Pretty sure you have said this before 00:31
And yes, I think that's much harder to do everywhere consistently than to just say "okay scrap that, -1 IS a literal after all"
guifa But would bring other benefits :-)
namely
Nemokosch and as you could see, negative numbers are explicitly hacked with the presence or absence of whitespace
guifa BEGIN my $bar = [calculation]; sub foo (--> $bar) { … }
Nemokosch -1 .succ is not the same as -1.succ and stuff like that
oh right, something I wanted to at least mention one more time, although I already got labelled "a pedantic ding dong" (or whatever) for it 00:33
guifa RIght now 2 -1 is valid for 2 - 1. Would making it literal cause that to be parsed as 2 (-1), and thus a syntax error? (I'm not sure, but it might require more grammar rewriting) 00:34
Nemokosch Raku is not Rakudo, and this is good to keep in mind, even if we sometimes pretend they are the same thing 00:35
where I'm getting at is that it would be important to avoid the situation where Rakudo behavior gets specced simply for being Rakudo behavior. "Undefined behavior" is not the way to go in my opinion, but if something feels odd to document, it's probably "wrong behavior" 00:37
in which case "Rakudo does not conform with Raku", rather than "Raku lacks specification for Rakudo behavior"
sortiz Well, roast specs raku, not rakudo, and in fact in roast there are lots of "rakudo todo" and NYI 00:39
guifa So Raku standard grammar (going all the way back to Perl 6's STD.pm6) does not define numbers with a negative literal
github.com/perl6/std/blob/28329a77....pm6#L2538
Nemokosch guifa: to be honest, I wouldn't mind 2 -1 being a syntax error, for my 2 cents 00:40
guifa hmm, actually nm. numeric underneath does
guifa hunts this down in Rakudo grammar
huh, we don't have a <numeric>. I wonder where down the line that changed 00:41
nemokosch: there's your argument for Rakudo :-) just wrap <number> in a <numeric> that handles the signs 00:42
tellable6 guifa, I'll pass your message to Nemokosch
Nemokosch yes well, this case is specified pretty well, I didn't mean this for Rakudo - if anything, I rather meant the whitespace-sensitivity around negative pseudo-literals 00:45
what can I say, I think this is an "esoterism" in the specification, to define something with the name "number" or "integer" that doesn't cover "half of the numbers" that we write down in our everyday lives, so to speak
I don't see any advantages of it and theoretically it's very impure but it's not such an impactful "esoterism" as some others are 00:49
confer "negation lifting" or what the term was
you know, when (1, 2, 3).any != 2 turns into !((1, 2, 3).any == 2) 00:51
I don't intend to hurt anyone by saying this but that behavior... really only resembles INTERCAL 00:53
lizmat weekly: fosdem.org/2023/news/2022-11-07-ac...um=twitter 05:27
notable6 lizmat, Noted! (weekly)
lizmat plenty of devrooms that someone could give a Raku based presentation in 05:28
see also: news.perlfoundation.org/post/fosdem # mini-grants 05:34
sortiz lizmat, I'm preparing a companion for your PR#5095, I would greatly appreciate your comments. github.com/salortiz/POSIX-PWDENT 05:45
lizmat sortiz: you're aware of raku.land/zef:lizmat/P5getpwnam and raku.land/zef:lizmat/P5getgrnam ? 05:49
sortiz Yes of course, but I'm trying a more "idiomatic" API 05:52
lizmat ok, sure: you either might want to use that as a dependency, or steal the code from it 05:59
lizmat I found some tricky stuff with getpwent between the various OSes that has been intergrated into P5getpwnam / P5getgrnam 06:00
different OSes having different length structs
sortiz You're right, I'll take a look. 06:02
Thanks a lot. 06:04
lizmat you're welcome :-) 06:05
I like the API :-)
lizmat sortiz: I don't like the caveat Isn't there a way around it? aka, copy the values out of the struct to create a PwdEnt object ? 06:10
I mean, with this interface, something like $*PWDENT<foo> eq $*PWDENT<bar> would always be true ? 06:11
sortiz You can use .Map (or .Hash or .List) to get persistent objects, but the casual and common use (to get some specific data) is much cheaper returning the raw CStruct. 06:14
And that's the reason for having two Iterables. 06:16
lizmat somehow this feels like a premature optimization 06:18
I mean, how many entries do you expect a /etc/passwd to have, and how many times would you run it?
anyways, it was my 2c worth :-) 06:19
sortiz Much appreciated!
I suspect the most common use cases will be ~$*PWDENT[Int] and +$*PWDENT<Str>, hence the optimization. 06:23
sortiz BTW, I left a comment on PR#5095 06:25
tonyo half tempted to volunteer for the go room and give a talk about using the C macro preprocessor to get real macros in go in the stead of generators 06:27
my `real macros in go` got a lot of h8 06:28
Nemokosch Hello hello 10:54
tellable6 2022-11-08T00:42:11Z #raku <guifa> nemokosch: there's your argument for Rakudo :-) just wrap <number> in a <numeric> that handles the signs
Nemokosch oops, wrong chat again... the bait
gfldex is there a way to get hold of the raw bits of a bigint? 11:36
El_Che tonyo: I don't think that macros is that big sale as you think in the go world 12:27
"how to make go more like C" is not that popular :) 12:28
tonyo: what use case of macro specifically are you thinking of? 12:31
surely not constants and generics? 12:32
japhb lizmat: Had my first non-trivial need for rak yesterday. It was *way* faster than I expected for what I asked it to do. Bravo! 15:58
tonyo El_Che: it was mostly just a "could it work" article, i know go people are less than thrilled about anything until bob pike says it's ok 16:03
the talk would just be a troll talk
El_Che tonyo: you could dress it up ass converting go into rust 16:11
tonyo transpiler for two compiled languages..haha
El_Che nah, just adding the rust complexity at the lang level 16:12
lizmat japhb: nice! 17:33
lizmat clickbaits rakudoweekly.blog/2022/11/07/2022-...aluersion/
melezhik o/ 17:34
melezhik . 17:37
melezhik Anton Antonov, you live in Coral Springs, Florida, right ? We think about moving this area ... I'd good to talk ))) 19:55
guifa gfldex: raw bits as ... a buf or ? 22:23

Powered by Cro and the Raku® Programming Language.

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

Thank you!