#raku-dev on 8 July 2020 - Raku Programming Language Log

00:02 ShimmerFairy left, ShimmerFairy joined 00:03 sena_kun joined 00:05 Altai-man_ left 01:28 Xliff joined 02:02 Altai-man_ joined 02:05 sena_kun left 02:32 lizmat joined

timotimo

so my thinking about lembark's code is that we need to teach Proc::Async's pipes to permit the process to emit the "right" amount so we hover around a reasonable pipe buffer size, like maybe 128 megabytes? it should be big enough that in many cases you wouldn't even hit the permit limit, but if you've got a program that spits out multiple gigabytes, then it'll pause before that point is reached

03:29

so the pipe would have to issue permits when the buffer gets drained so that the process can continue writing and set the permits back to 0 when the buffer is full, maybe

03:30

and it'd be cool to have manual control over the permit process, too, but i'm not sure what the api should look like, what it should be called, etc.

if i see correctly, the IO::Pipe uses a Channel coercer on the stdout/stderr/merged supply, which is usually a way to prevent backpressure from affecting a supply's source

03:31

this might be food for a problem-solving issue

03:34

m: my Channel $c .= new; say $c.elems; $c.send($_) for ^100; say $c.elems

camelia

Cannot determine number of elements on a Channel
in block <unit> at <tmp> line 1

timotimo

i *think* you can nqp::elems a ConcBlockingQueue (but not .elems, because it's unreliable and prone to races and should never be used by users who don't know exactly which foot they're holding the gun to)

03:35

04:03 sena_kun joined 04:05 Altai-man_ left 04:42 Xliff left 06:02 Altai-man_ joined 06:05 sena_kun left 07:34 tobs joined 08:03 sena_kun joined 08:05 Altai-man_ left

lizmat

Files=1307, Tests=113021, 216 wallclock secs (29.46 usr 8.63 sys + 3025.89 cusr 287.78 csys = 3351.76 CPU)

09:15

09:22 squashable6 left 09:24 squashable6 joined

MasterDuke

timotimo: there is an elems() in src/6model/reprs/ConcBlockingQueue.c

09:55

10:02 Altai-man_ joined 10:05 sena_kun left 10:50 patrickb joined 11:45 AlexDaniel joined, AlexDaniel left, AlexDaniel joined 12:03 sena_kun joined 12:05 Altai-man_ left 12:57 MasterDuke left 13:01 stoned75 joined

sena_kun

Blin shows `1481 out of 1484 modules processed (left: Font::FreeType PDF::Font::Loader PDF::ISO_32000)` for some hours now, I wonder if it hung...

13:04

13:08 MasterDuke joined

AlexDaniel

sena_kun: I think these three are just slow

13:16

also, it's possible that blin is bisecting them…

which is slow times 11

sena_kun

Let's wait until tomorrow and see.

13:17

AlexDaniel

x)

I was about to suggest to kill the individual processes, but then they'd be started again if it's bisecting them…

13:18

timotimo: you seem to like nice tools. Let me tell you about alacritty :)

13:27

timotimo: fast gpu-based terminal, no unneeded features, seems to work natively on wayland, supports bitmap fonts

13:28

I'm switching from urxvt :)

now I need a file manager that works on wayland. Suggestions?

13:31

MasterDuke

AlexDaniel: you're using wayland on debian? how's the support?

13:32

AlexDaniel

MasterDuke: yeah, well…

MasterDuke: so transition from i3 to sway is kinda easy, it can read the same config file

so out of the box it kinda works. You do need to add something extra for keyboard layouts and stuff, but it's relatively easy

13:33

now, all apps work just find through xwayland

but what's the point of using wayland if you're not running apps natively on wayland, right? :)

so, firefox needs an ENV variable to be set in order to work natively on wayland

13:34

and let me tell you, it's very noticeable!

something about the scrolling just feels so nice

MasterDuke

ah, so noticeable in a good way?

AlexDaniel

yes

MasterDuke

i've thought about giving wayland a try

13:35

AlexDaniel

it depends on the window manager that you use

MasterDuke

but i have an nvidia gpu, and i think the support isn't quite as good

AlexDaniel

for i3 → sway transition it's extremely easy

13:36

MasterDuke

i use kde

AlexDaniel

MasterDuke: are you using proprietary or open-source drivers?

MasterDuke

proprietary

AlexDaniel

well… yeah…

MasterDuke: this rant is kinda relevant to understand the situation with nvidia: drewdevault.com/2017/10/26/Fuck-you-nvidia.html

13:37

MasterDuke

yeah, that's one reason i've been hesitant. but i believe the situation has improved a bit since then

AlexDaniel

in what way?

13:38

MasterDuke

i also need to upgrade my video card, so am considering amd

AlexDaniel

all wm devs bent over and added separate code paths for nvidia's proprietary stuff? Maybe…

if so then indeed it should be unnoticable to users

MasterDuke

i think a little of that and a little of nvidia supporting some more of the other standards

13:39

AlexDaniel

so, to summarize, I just had to install xwayland to make sure most programs keep working, then configure the keyboard layout stuff separately for sway, then switch to alacritty because urxvt doesn't run natively on wayland and alacritty should, add an env variable for firefox (btw chromium has no such thing I think, so firefox ftw)…

13:41

that's about it, it's not too much

two issues I still have: nm-applet doesn't work (it just doesn't, that's it, no solution for now), spacefm segfaults

so I have no file manager and no gui for the network manager…

13:42

and everything else is working absolutely fine

timotimo

just use iwd instead of NetworkManager ;)

AlexDaniel

timotimo: use what?

13:43

timotimo

iwd

just kidding

i only just heard of iwd's existence :D

AlexDaniel

thing is, network manager itself is working just fine, you can still control it with nmtui and stuff like that

13:44

timotimo

right

AlexDaniel

it's the tray applet that doesn't

timotimo

and nmcli :)

AlexDaniel

and I can live with that, I think… but file manager?

timotimo

media.ccc.de/v/ASG2019-127-gnu-pok...inary-data - possibly quite interesting to look at for the design of binary rules in raku

13:46

AlexDaniel

that logo tho x)

13:49

13:55 Kaiepi left 13:56 Kaiepi joined

timotimo

kaitai.io/ - did we know about this yet?

13:57

AlexDaniel

timotimo: I don't really know what you want to achieve with binary parsing in Raku. Even basic text parsing is slow as hell, why would it be useful to do anything with stuff that requires binary parsing?

13:59

timotimo

text parsing won't stay slow forever

14:00

AlexDaniel

why?

timotimo

because we have smart people!

AlexDaniel

we've had smart people for 20 years

timotimo

there's a complex web of requirements to make stuff possible

14:01

AlexDaniel

and they didn't come up with a way to parse text without polluting everything with match objects

even though you don't even need match objects in the majority of the cases, you just need the text itself that matched

14:02

14:02 Altai-man_ joined

nine

Our text parsing certainly isn't fast. But it's fast enough for many use cases. Same could be true for handling binary data

14:03

AlexDaniel

the key to performance is to not do stuff at all. Instead we do everything that anyone may possibly want, and then expect the compiler to figure out that nothing needs to be done

14:04

timotimo

true, on the other hand we're currently doing barely any smarts at the level where we still have the QRegex QAST datastructure

14:04 sena_kun left

AlexDaniel

what kind of smarts do you expect to be implemented to stop creating objects when we don't need them?

14:05

jnthn

EA.

14:06

AlexDaniel

nine: colabti.org/irclogger/irclogger_lo...07-07#l539

timotimo

we already only guarantee that {} makes a $/ usable, there's probably more spots we can use that let us signal "no need to do anything yet"

AlexDaniel

timotimo: {} makes a $/ usable? What does that mean?

14:07

timotimo

and yeah, when we have match objects just for storing positions and such inside a part of the generated code, EA can make no match object exist at all yet

i'm not speaking coherently

14:08

m: say "ahaha" ~~ / (a) .* $0 /

14:09

camelia

｢ahaha｣
0 => ｢a｣

timotimo

i'm possibly misremembering

AlexDaniel

I don't think escape analysis will ever undo the generation of all the bloat during regex matching

14:10

you are free to believe though

timotimo

the generation of that bloat is actually exactly what EA would be for

14:11

AlexDaniel

language-wise the solution is very simple – let people populate their stuff with matched strings. Zero match objects created.

timotimo

we could totally have a "use NoMatchForMe" that changes regex compilation and matching to do that

14:12

jnthn

In principle, the entire subrule call graph can not even be traversed in first place when there's no capturing and it's entirely declarative.

Meaning you could avoid the cursor creation too

timotimo

as far as signaling to the compiler that it is supposed to change how things work, i mean

nine

We've had smart people woring for 20 years, but 15 of those were to get stuff up and running

And so far only 5 years to get stuff faster that was created over 15 years

14:13

AlexDaniel

so 15 years of adding bloated features and 5 of trying to undo it with the compiler. See you in 10 years?

14:15

you can also make a fast language right from the start, other languages do it somehow

14:16

timotimo

java was crawling for the first X years, and now it's pretty widespread

14:17

they somehow didn't care about being fast from the start and turned out well, i mean

AlexDaniel

yeah, feel free to not care. I'll go try Julia for my next project

14:18

timotimo

i do care about making rakudo and moarvm faster, i don't think i'm the right person to attempt sweeping architecture changes, though

14:19

raku-bridge

<Vendethiel> jnthn: don't you need to create a cursor still, because it's often used i.e. in error reporting?

14:23

jnthn

Vendethiel: If it's reporting an error then it's got imperative parts, not purely declarative ones.

14:24

raku-bridge

<Vendethiel> ah, right

timotimo

which might mean that imperative parts are very common in grammars that have any error reporting, perhaps?

jnthn

I think those are common common in tokens than rules

14:25

uh, other way around :)

raku-bridge

<Vendethiel> that's severely limiting the scope of grammars that can be optimized that way, but for simple regexes, that sounds incredible

timotimo

for simple regexes we still have to do more than "nothing" in terms of skipping regex entirely

like going for ends-with, starts-with, contains

raku-bridge

<Vendethiel> right

14:26

timotimo

extracting dominating substrings up front

jnthn

AlexDaniel: I hope you'll find the enjoyment in doing that, that you once found with Raku.

14:27

AlexDaniel

raku is fun when you start learning it. And much less fun once you know enough, attempt to use it and then immediately see all of the ugly

14:28

to fix it you'd need to revert the mindset that you all seem to share

14:29

which I obviously won't be able to do, so yeah, let's hope I find something else

timotimo

i'm not sure i'm clear on what that is, exactly

14:31

raku-bridge

<Vendethiel> timotimo: "maybe someone will be smart enough to figure out how to clone jnthn++", surely :)

timotimo

is it more of a priorization thing, or that we need to more aggressively toss out stuff that's not optimizable, at least at the moment?

14:32

jnthn

At the end of the day, languages all make different trade-offs, and people differ on which ones they consider more trade-off-able.

If they didn't, there wouldn't be so many languages, I guess.

raku-bridge

<Vendethiel> insert Bjarne quote here

14:33

AlexDaniel

timotimo: I'd say it's more about not admitting that we ended up with something that is just plainly bad. You say it's OK-ish for now and maybe it will get better, jnthn says it's just tradeoffs. I say it's just bad. You decide which one of these allows to plan how to get things fixed as soon as possible.

14:37

raku-bridge

<Vendethiel> are we still talking about performance?

AlexDaniel

performance is not something that is isolated

we're talking about Raku

14:38

I am, at least

raku-bridge

<Vendethiel> I just wanted to make sure.

AlexDaniel

although people will disagree, I think, which is how Raku was really created. Performance as an afterthought

14:39

speaking of undoing, I hope it's clear that it's always much harder (and more time-consuming) to fix design mistakes than to implement them wrongly in the first place

14:43

Altai-man_

AlexDaniel, I think this suddenly became too polarized, maybe that's just me. It is not about black and white, utter shit and software masterpiece. It is a bit unfair to lump "performance" / "language" into a single thing and slap a label at it. Raku is rather fast compared to others in some things, it is rather slow compared to others in some things. IT industry is full of pain in general and "Language X is pure joy 100% of the time" is usually a

wrong first impression.

AlexDaniel

so the 10-year estimate is rather optimistic, actually :)

Altai-man_

AlexDaniel, good luck looking at Julia, a nice break and a change of pace is always great.

14:45

AlexDaniel

Altai-man_: for any real life code, which language you think is slower?

lizmat

AlexDaniel: I wish you you a better experience with another programming language than you've appear to have had with Raku

timotimo

and thanks for all your contributions so far, of course

lizmat

as in any relationship, at some point the infatuation either turns into love, or the relationship ends

14:46

AlexDaniel

except that I keep maintaining the stuff I made, unless anyone wants to take over :)

timotimo

\o/

glad to hear it

Altai-man_

As for 10 years, it is not like people here have a deadline to be successful kings of the programming world and unless it's done you're a complete failure. At the end of the day, nothing actually matters and we are here a bunch of folks with conciousness who try to entertain themselves somewhat. Maybe I am lecturing, though, dunno.

14:47

timotimo

that's an easy stance to take when your food is taken care of, at least

AlexDaniel

Altai-man_: no, you're right, it's an optimistic way of looking at things, very refreshing compared to my messages :)

but I do have a feeling that there's a bit of conflict between optimism and realism in this case

14:48

timotimo: I actually sorta left quite some time ago, tried to stay away from IRC because you see how it ends :P

14:49

timotimo: I actually reworked statisfiable, it has more stats and is just better now, but I didn't commit it yet

I'll try to get back to my break once it's live

14:50

timotimo

i thought that happened when i saw an amount of issues you had opened were closed

14:50 patrickb left

AlexDaniel

yeah. Though I didn't close anything that mattered? It was mostly about my own personal tickets that I used for myself

14:50

14:51 patrickb joined

timotimo

surely, how slow it was to grab all the annotations from moar's dump output was not a great experience :)

14:51

AlexDaniel

haha

timotimo

oh hey nine can you find that gist again where you wrote a moar bytecode parser in raku? i kind of couldn't find it any more

AlexDaniel

but was it? Once I switched to nqp ops I think it became really fast on my side?

14:52

it's usually the speed of my own code that I care about, for what it's worth the moar output I'd consider an external utility :)

Altai-man_

The point is, if you can be satisfied with what you have, you're a happy lucky one. If you are not and want more X, no amount of "more" can satisfy you, even if your X is 10x best in the world.

14:54

I mean, it does sound like a lame excuse, but I found a bit of stoic approach in this, which allows to care about what you can change and don't be sad over things you can't change.

14:55

Namely, IT is about tools, so it something does the job better - please do use it. There is no need to be sad with the hammer seeming wrong because it can't screw something.

14:57

timotimo

actually

i saw a super cool video where a hammer helped screw something

Altai-man_

More so, being extensive contributor you INDEED see much more horrible stuff about the language than the "average" user... And thus comes the bias "Oh, this thing is so horrible" while in fact it is not SO horrible. Maybe somewhat, true.

14:58

timotimo

i have not the slightest clue how to find that again

essentially used an extra screw on top of a plank to give the hammer leverage against another plank that was misaligned, then screwing the two together from "the front"

14:59

jdv79

i saw someone hammering screws in one day. did a double take.

15:00

Altai-man_

timotimo, well, in some conditions you can hammer a screw, it's just not how it works in general and no warranty given or implied. :P

15:01

timotimo

oof, the heaptrack record is almost a gigabyte big

15:02

AlexDaniel

well, impact drivers are essentially hammers

timotimo

what are you, the god of hammers?

AlexDaniel

and they are much more efficient than regular powered drills, for screwing screws that is

they strike to rotate the bit though, not to punch the screw through

that is, they don't push the screw, they just rotate the bit in rapid kicks

15:03

nine

timotimo: gist.github.com/niner/63a718023aba...c1ccd84e32

15:04

AlexDaniel

youtu.be/f0gSJa3L_7c?t=141

15:06

jdv79

they are also very noisy. i prefer a non-impactful screw gun.

15:07

AlexDaniel

jdv79: I'd take hearing loss over cam out any day xD

15:08

jdv79

i like music though

15:09

AlexDaniel

the first time you use it it's really loud indeed, but later it feels like you clench or something and it no longer bothers

btw, here's a positive observation

15:10

julia's startup time for scripts is a bit higher. By 10-20ms or so

statisfiable6 will be able to graph startup time now, after I commit my stuff

15:11

so you'll be able to see where it's going

jdv79

a friend of mine was raving about julia a few years ago

15:12

something about being able to get the asm and manip it or something

AlexDaniel

well, any time I compared something I didn't like in the raku language to julia I always liked what julia was offering. I have no idea if it really works in practice, hard to tell without doing a real project in it.

15:13

15:14 patrickb left

AlexDaniel

the way it is printing stacktraces is very interesting. It's really really slow, like it has to redo something in order to figure out what happened?

15:14

vrurg

Talking about performance, /me remembers the times when inlining assembler into C code was common because people were dissatisfied with performance...

15:15

tellable6

2020-07-08T12:03:15Z #raku <SmokeMachine> vrurg thanks! my irc client is out, I've haven't seen that! Thanks!

timotimo

vrurg: i'm looking forward to trying vigna when new-disp is mainline

15:34

though honestly, i think i'd really love something simple where you can have an input line at the bottom and scrolling output above, perhaps split side-by-side, maybe multiple independent ones on top of each other

15:35

for simpler tools like the debugger commandline, the heap analyzer commandline, stuff like that

maybe my idea to "do this with just the simplest escape sequences" is dumb

15:37

like how you can set an area of the terminal to be scrolling and everything else to stand still

15:38

15:38 MasterDuke left

timotimo

but then if you want to support resizing of the terminal you would probably have to keep everything in memory as well, so you can redraw what should be on screen

15:39

AlexDaniel

“Stack Overflow is currently offline for maintenance”

15:42

:)

timotimo

and i've got to think of something with regards to completion and line editing

AlexDaniel: the sound of a million coffee machines screaming in agony and suddenly being silenced by energy grids all over the world collapsing

15:59 MasterDuke joined 16:03 sena_kun joined 16:04 Altai-man_ left 16:05 stoned75 left 16:07 stoned75 joined 16:13 Kaiepi left 16:14 Kaiepi joined

[Tux]

Rakudo version 2020.06-58-g16d24a212 - MoarVM version 2020.06-20-g187b4564e

csv-ip5xs	0.812	-	0.824
csv-ip5xs-20	7.862	-	8.039
csv-parser	25.286	-	25.845
csv-test-xs-20	0.395	-	0.400
test	7.600	-	7.651
test-t	1.841	-	2.085
test-t --race	0.827	-	0.830
test-t-20	32.261	-	33.218
test-t-20 --race	8.738	-	9.513

16:22

dogbert17

AlexDaniel: out of curiosity, why Julia specifically? I mean there are lots of hyped languages out there :)

16:29

AlexDaniel

jdv79: hey remember that silly-ish benchmark you showed yesterday?

16:30

jdv79: I tried writing it in Julia. Now, I don't speak julia is it's potentially ugly, but here: gist.github.com/AlexDaniel/cbac99a...c35436528f

it's faster in julia!

that is, faster than perl

perl5

I tried doing something with one of the vars thinking it optimizes too much away, but I don't think that's the case

dogbert17: they seem to be doing a lot of things right, or at least have ways of doing things right (and all of that is pretty fast at the same time)

16:32

dogbert17: it is weirdly similar to Raku actually, rats, channels, atomic ints, last expression is returned, etc.

16:33

a lot of that not by default, but if you want a rat you can have a rat

16:34

jdv79: s/is/so/

dogbert17

interesting, seems to have lots of math/scientific stuff

here's something for timotimo: julialang.org/blog/2020/05/rr/

16:35

AlexDaniel

dogbert17: any time I found something debatable in Raku it was curious to find that in Julia it is almost always done in a more meaningful way

dogbert17: but look, no big ints by default. Weird.

16:37

dogbert17

but there's multiple dispatch and optional typing

AlexDaniel

yep

16:38

dogbert17 goes out for a quick walk &

Geth

rakudo/rakuast: cef320b06d | (Jonathan Worthington)++ | 3 files
RakuAST support for various regex assertion forms

16:46

jdv79

AlexDaniel: my box is loaded at the moment but i see perl beating julia a bit at ~6.6s vs 8.25s on my file "4496744 17986976 610247801 s3-pica9-logs-ls-r"

16:52

AlexDaniel

jdv79: in my case it's Julia 1.4.1 vs Perl 5.30

16:53

jdv79

ditto

16:54

AlexDaniel

interesting. It's faster by about 10% for me, but it's not a real file so who knows

jdv79

maybe julia is more sensitive to a cpu bound box

i'll try after the loading is over

wow. raku with hyper i guess is very cpu load sensitive. with hyper it takes 59s and without it takes 12s

16:56

that's with the "next unless .contains($str)" cheat

AlexDaniel

in my experience hyper didn't do anything faster ever, unless you have some sleepy tasks

vrurg

timotimo: I was away... A simple tool for simple tasks – yes. But as soon as complexity of an application grows, the requirements for a framework skyrocket.

jdv79

yeah

AlexDaniel

jdv79: oh, are you benchmarking with the cheat or not? :)

16:57

jdv79

with cheat

AlexDaniel

that's why then

ah no

ok I got very confused

time for a break I guess x) nevermind

vrurg

timotimo: BTW, I was wondering about profiling. I tried to use moarperf with vikna once. The flamegraph happened to be occupied with await because this is where most of the time is spent after all. But is there a way to exclude it from the output?

16:59

AlexDaniel

jdv79: so I created a file with 2100000 lines and it's 3.4s for julia and 4.4s for perl. The difference seems to grow if I make the file larger

17:00

but no idea what kind of tricks it has up its sleeve

jdv79

idk. the big load is over and they both are still relatively the same

17:01

perl is 5.8s and julia is 8s

meh

maybe its less uniformness of my data file?

17:02

s/its/its teh/

AlexDaniel

maybe!

trying a simple loop over the lines seems to indicate that perl is indeed faster, 0.6s vs 1.2s

17:03

vrurg

AlexDaniel: sorry if I'm out of the context and missed something, but with hyper I got really huge speed up in producing an HTML from a sqlite via Template::Mustache. Though the latter needed a patch to actually support concurrent sequences.

AlexDaniel

vrurg: I guess it can be helpful if you have very “fat” tasks

17:04

but for small code pieces like iterating over lines and doing simple matches, hyper just makes things worse

17:05

vrurg

Evidently. Otherwise the cost of spawning threads is too hight.

AlexDaniel: if there're many such short-living tasks then pre-spawning of the kind what my Async::Workers does is more helpful.

17:07

AlexDaniel

jdv79: another thing to try is gist.github.com/AlexDaniel/7317971...6aea12c617

a bit fairer comparison :)

vrurg is afk

17:08

jdv79

7s

AlexDaniel

still, I kinda hoped that it'd be able to populate existing variables. They're using pcre so maybe that makes it harder, but Raku has all the freedom to do that

17:09

something like my $foo; … /$foo=[\S+]/

17:10

just save the string and whizz by

in the past I supported the idea of making a fast .contains that simply returns a Bool (which actually got implemented…), but now I feel like that's wrong too

17:14

it's .match and friends that should not return anything at all unless you ask for it

17:15

basically, $/ should be gone

17:16

sena_kun

Is it just me or this regex can be replaced with just `.words` call and unpacking assignment?

17:17

AlexDaniel

sena_kun: correct, yes, but it's a benchmark for a simple regex

sena_kun

Fair enough.

17:18

AlexDaniel

sena_kun: perl5 and Julia are sorta exchanging blows on that one, IIRC Raku is 25 times slower

17:19

$/ was already changed to no longer by dynamic, I think? Or something like that

17:20

be*

performance was cited as one of the reasons if I remember it right

too bad it wasn't thrown away completely instead :P

17:21

jnthn

AlexDaniel: No, it was $_ that was changed to no longer be dynamic. A lot of things rely on $/ being.

17:31

AlexDaniel

I see

17:40

timotimo

vrurg: i don't have a clever idea for that yet :|

17:56

18:02 Altai-man_ joined 18:05 sena_kun left 18:12 lichtkind joined

MasterDuke

re the implementation being optimized later rather than up front, i know TimToady has mentioned something about "it" (i don't know if he was talking about the language design itself or the particular implementations) being "optimizable". i think a valid question would be whether in practice that meant people made sub-optimal (from a performance

18:30

viewpoint) decisions with the thought that a "sufficient smart compiler" would be developed eventually? or was the design such that there was/is a clear path to optimizing what we had then/now?

MasterDuke isn't trying to cast blame on anybody, but figure out whether performance issues have a pre-planned path to improvement, or do we need to come up with those plans?

18:34

18:34 Kaiepi left, Kaiepi joined

AlexDaniel

MasterDuke: well, if you read the old design docs then they sometimes mention how something can be hopefully optimized

18:45

18:45 squashable6 left

AlexDaniel

MasterDuke: but that's really not enough

18:46

basically, as I understand it, the design process was pretty much done in the dark wrt optimizability

18:47

even though the principles of making fast code are very well understood

18:48

18:49 squashable6 joined

AlexDaniel

so basically the docs say “ok this bit maybe will be optimized like that, fingers crossed”

18:51

when what should be happening is “ok this will map exactly to these operations, and that's why it will be fast”

you see, it is possible to design a language that does exactly what the users commands, which is fast by itself, and then you can spend all the time in the world in figuring out how to make the compiler ignore that and not do anything at all, making it even faster

18:53

instead, Raku does a bunch of stuff you didn't even ask it to do, and now the devs are trying to figure out how to get back to the base performance

18:54

18:56 [Coke] left 18:57 [Coke] joined, [Coke] left, [Coke] joined

AlexDaniel

and you can see that in all recent discussions. For example, let's say you take a Seq and want to skip a value. You do $s.skip(3) and get a new Seq object

18:57

well hold did I ask it to create a new object? I just wanted it to skip a certain amount of values

which I guess you can do if you play with the underlying iterator, but that's like playing with guts when you have a .skip that was sort of designed to do that?

18:58

or, another example is the last regex benchmark

all you need in that benchmark is to take a string and destructure it into a few variables

18:59

sounds simple, and it is simple, but you can't do it

instead it creates a bunch of match objects. Well, hold on, I didn't ask for match objects, I didn't even necessarily ask for anything really

of course you can argue all day that returning a match tree is the most versatile solution, sure, whatever, but it is not designed to be fast for sure

19:00

[Coke]

So at this point, do you think there's a path forward that will satisfy what you're looking for?

19:04

AlexDaniel

yes

lizmat

drumroll....

AlexDaniel

admit that we ended up with crap, dismantle the language into pieces and redo them right, release a much better Raku 7

19:05

lizmat

well volunteered!

Altai-man_

This is probably the worst time ever for this, but... Apparently, Blin hung, so here is the overview for Seq-related branch clbin.com/0Ov4J <- and around ~60 modules are broken.

19:06

AlexDaniel

oh that's not too many

lizmat

Altai-man_: I am *not* surprised

Altai-man_: of *all* modules tried, or just the ones before it hung ?

19:07

AlexDaniel

lizmat: of all modules

lizmat: 3 modules were hanging I think

Altai-man_

Yes

19:08

AlexDaniel

lizmat: it didn't generate the dependency tree because it was killed, but it's possible that out of just 60 there are some failures caused by parents

jdv79

i would say this sort of frustration isn't uncommon. others have expressed simliar sentiments.

19:09

lizmat

well, I guess you have your work cut out for you: a. fix those modules, b. start working on fixing roast

AlexDaniel

it's not that easy

lizmat

jdv79: I too have my frustrations

having spent quite an amount of time on: val processing, ..., printf and lately Match

19:10

jdv79

yup. some others flamed out. some just disappeared.

lizmat

in my case, it has led me to understand the complexity of the situation

AlexDaniel

complexity can be reduced by deleting stuff

19:11

lizmat

in the case of printf: RakuAST will allow us to revisit that *without* having to resort to EVAL

jdv79

curious if there are some underlying root causes that might be addressed...?

lizmat

some internals that rely on EVAL and which are slow because of that, will also be fixable with RakuAST

the underlying root cause, in my opinion, is that nobody knew how to implement a language as radical as Raku

19:12

AlexDaniel

it's not very radical

the biggest value is in some nice syntactic sugar, that's what makes it feel like Raku

19:13

lizmat

AlexDaniel: how many languages can change their grammar with a single statement ?

AlexDaniel

lizmat: and how many languages like to talk about features that nobody is using? :P

19:14

I get it, changing the language sounds like a wonderful idea

but others get away with just macros, and it's fine

19:15

lizmat

AlexDaniel: you should talk to the people who would like to remove "format" from Perl 5

Altai-man_

AlexDaniel, there is some fallacy... Some of those "nobody using" features are key points of raku. People are suggesting to strip them off to speed up the compiler and what this gives us? Python with braces and `sub` instead of `def`? Please no.

19:16

AlexDaniel

that's not the point. Many languages have macros and custom operators, changing the whole syntax in just a single statement is not as amazing as you make it sound

19:17

19:17 go|dfish left

AlexDaniel

if I had to choose between fast parsing of Raku code and a sophisticated grammar-changing monstrosity, I'd choose the former in a heartbeat

19:17

lizmat

then by all means, join the Perl 7 effort

AlexDaniel

right, so you say well-volunteered and then make it clear that this is definitely not something you want for Raku feature

19:18

future*

which is why nobody will ever make things right

any idea of simplifying Raku will be shot down

19:19

Altai-man_

Apparently, there are people who won't choose the former and they went and did some implementation of Raku. People have opinions about what they want and if it differs from yours, then hm.

AlexDaniel

so what is Raku for, exactly? Playing around with fun ideas and fun one-liners?

19:20

because that's what it is right now, with very little applicability for real world problems

ShimmerFairy

For the record, anybody who has ever defined their own operator has changed the grammar.

Altai-man_

What's the meaning of life? Erm, almost exactly the same question. If it is for playing around with fun ideas and fun one-liners, then what?

19:21

AlexDaniel

Altai-man_: I don't blame you, I defended raku exactly like that before

Altai-man_

AlexDaniel, being blunt, I don't really care about future, because one won't predict it. You do things which sound kind of worthy (while having to pay the bills, of course) to do and that's all. You don't like it anymore and search for another thing to do.

19:23

AlexDaniel

but that's not very useful. You're basically saying that whatever Raku does is OK. I'm saying that it can be much much better

19:25

where did the LTA mindset go? :)

Altai-man_

My bad, I am broading the subject and expressing my kind of opinion on everything.

19:26

ShimmerFairy

I use Raku all the time, especially when I need to parse some text (it's invaluable for that). Just because *you* don't find it useful doesn't mean nobody does.

19:27

AlexDaniel

[Coke]: if I had to poorly summarize it, I'd say we need a somewhat coordinated effort at decluttering the language

Altai-man_

AlexDaniel, something like 6.e-level language breakage?

19:28

AlexDaniel

Altai-man_: not sure I understand?

I'm proposing Raku 7, which can be significantly reworked

19:29

timotimo

seven does what rakudon't

AlexDaniel

it'll break stuff, yeah. Luckily nobody is really using Raku so there's that.

19:30

Altai-man_

AlexDaniel, oh, sorry. I mean, we don't suddenly release a decluttered compiler breaking stuff in production. This sounds like something suitable for a language revision.

>nobody is really using Raku

AlexDaniel

sure sure you can go “but I use it”, and yes, I used it in production too

Altai-man_

This is just ridiculous right now.

AlexDaniel

no it's not. The amount of people who actually use Raku is *extremely* small

Altai-man_: but yes, I mean the next version

19:31

you see, there's a real problem of admitting stuff in this community :)

lizmat

like admitting it should have a different name ?

19:32

19:32 SmokeMachine joined

AlexDaniel

yeah

19:32

lizmat is getting angry and steps away from this discussion

AlexDaniel

many many years to do that obvious change

remember how the proposals to do that were shot down?

all of that to finally admit that yeah, we'd be better off with a different name

19:33

19:33 kawaii joined

ShimmerFairy

AlexDaniel: honest question, do you even like Raku, at all? All you ever do is complain about it, and not in a way that seems like someone noticing bits that could be improved, but as someone who's upset it doesn't match their personal ideal for a language. It really just seems like you want a completely different language.

19:36

AlexDaniel

ShimmerFairy: I liked it a lot, yeah. I'm not sure if I do anymore

19:37

it's really hard to use

Altai-man_

ShimmerFairy, "all done is complaining" is a bit of underestimation of how much amazing level of work AlexDaniel put into all this.

s/underestimation/misrepresentation/

19:38

ShimmerFairy

All I know is what I've seen since I came back.

Altai-man_

Fair enough, just noting. Honestly, I am always amazed seeing this.

19:39

AlexDaniel

ShimmerFairy: I think I felt similarly when I saw brrt's rant

19:40

can't really find it now, I think it was on #moarvm

it was something about unpredictable performance, I don't remember now as I didn't comprehend it back then

all I thought was “why is this guy complaining about this awesome language”

19:41

there was also Zoffix who craved relatively massive changes, which always felt to me like he was trying to make raku not raku

19:42

ShimmerFairy

Of course we should improve the language, and make it more attractive to other people (and I think it's fair to say very few people use it relative to other languages). But I don't think we can make Raku more appealing to others without honest-to-goodness studies to figure out what exactly is keeping people.

19:43

The reasons could range anywhere from "Most programmers are deathly allergic to anything remotely like Perl" to "The language is fine, it just doesn't get 'marketed' enough".

19:44

Altai-man_

The brrt rant mentioned is probably colabti.org/irclogger/irclogger_lo...-09-21#l99

19:46

AlexDaniel

no, the language is shit, that's not even a question. Simple, consistent, fast – pick three, it's the case when you can actually do it. Make Raku that and people will use it.

japhb

AlexDaniel: Please stop.

19:47

ShimmerFairy

There are definitely things that could improve about Raku, but if you think the whole language is garbage then you'd have a better time finding another one or making your own, compared to getting everyone else to agree to effectively replace it.

19:48

Altai-man_

Simple, consistent, fast, languages like Nim, Crystal, Odin, tons of them and they are not really popular somehow.

19:49

AlexDaniel

so is Raku

that is, not popular

19:50

Altai-man_

Yup.

AlexDaniel

if you want it to be popular, we should strive to make it better

instead it's just excuses and people being defensive

anyway, you all can do whatever you want. I was asked what would be the way forward, I think my general idea is clear

19:52

japhb

AlexDaniel: I assure you I am not being defensive when I say: I *like* Raku. I have used it exclusively for years, despite learning quite a few different languages over the last 4+ decades. If you do not like it, that is fine. Please stop attacking. If you don't like it, *implement the changes you want in a fork or replacement*, or go elsewhere.

19:52 tbrowder joined

AlexDaniel

I'll go elsewhere that's ok

19:52

it's not a big issue for me, even though I'm very frustrated

19:53

japhb

I can tell. But this channel is #raku-dev, not #raku-rant. :-)

19:53 go|dfish joined

AlexDaniel

it should be alright for devs to express that things are very not OK

19:57

timotimo

i'm not sure it's fair to say "implement the changes or go", how many of us actually implement big things on their own

AlexDaniel

if I had a mug I'd throw it :P

that is correct, the changes that raku needs not only can't be implemented by a single person, but even if that person attempts to implement them they'll face a lot of backpressure

19:59

japhb

AlexDaniel: You can totally express that. But "the language is shit, that's not even a question" is not an expression of a need for change and rebirth, it's an attack. Those are different.

Altai-man_

AlexDaniel, is it possible you do me a little favor and went for an ice-cream? (I'll pay for it)

20:00

AlexDaniel

you can look at it this way if you feel like being defensive

Altai-man_: it's already paid for, I'll go get some :)

20:01 zostay joined

japhb

timotimo: There have been people who wanted to completely change Parrot (in the old days) and Perl 6 (in the middle days). If they were nice, we accepted them and encouraged them. If they told us we were idiots, we tried to hug them, and then when we discovered hugs didn't work, let them go their own way.

20:01

AlexDaniel: I'm not defensive in the sense of "subconsciously throwing up spiked shields to protect my psyche". I am defensive in the sense of "You are currently risking severely damaging my community. I would like you to put down your swords and pick up plowshares, please."

20:02

20:03 sena_kun joined

AlexDaniel

japhb: so what would be the way forward in your opinion?

20:04

japhb

I don't want to hold you for now, Altai-man_

20:04 Altai-man_ left

japhb

's suggestion was good

20:04

:-)

lizmat

japhb: in case you didn't know: Altai-man === sena_kun

20:05

AlexDaniel

japhb: I'm eating it right now

japhb

After that, we can reassess. I have some ideas, but it depends on you. (Not saying you have to go write Raku 7 or whatever yourself, I meant, what are you interested in doing?)

lizmat: I am aware. :-)

20:06

AlexDaniel

japhb: what do you mean what *I* am interested in doing. What do you think would be best for the Raku project?

japhb

Note: I do not generally follow #raku. If there have been significant discussions there that I need to be aware of, I have missed them. I am purely trying to find a good path for the implementor channels (#moarvm, #raku-dev, etc.)

20:07

AlexDaniel: There are several things I think are good for the Raku project, some of which already exist, and some of which don't (almost entirely because of the lack of funding).

20:09

AlexDaniel

japhb: so let's say there's a lot of money, then we put it into what?

japhb

Regarding you, I meant: You are super frustrated. *Aside* from ranting, what are you interested in doing about your frustrations. Do you want to work on writing up a *cohesive* proposal for change? Do you want to work on a prototype in a fork? Start from scratch and see if you (and any others interested) can figure out a better design?

20:10

AlexDaniel: If we had lots of money? We hire the folks who have done great things already and have expressed that they cannot do more because they can't afford to.

20:11

AlexDaniel

japhb: so you have no real vision on how the language and the compiler can or should be changed, and you think that just throwing more money at those who got it to this state will somehow solve everything? It'll help somewhat but won't change the situation

20:13

japhb: but what will it solve actually

japhb: so you think more money is needed, okay, for what?

japhb

Nope. I know several things that I would change immediately if I had the right people, and I'm pretty sure who a half dozen of those people are, and have guesses for more.

AlexDaniel

for example?

20:14

japhb

Accelerate work on improving the networking (and I/O in general) stack. A few people have worked on bits of this, but it's been not cohesive or happening quickly.

20:15

Put a lot more effort into broader performance tests, that cover more of the spectrum. Give jnthn and nine and timotimo and lizmat and so forth lots to chew on.

20:16

Get the DB/ORM side in rock solid shape.

Turn the work on stress testing and fuzzing and such up to 11.

Fill in the bits that are incomplete in the Cro ecosystem.

20:17

AlexDaniel

so basically “everything is fine just more stuff needs to be done”. Most people probably agree with you, but I absolutely don't

japhb

Put more effort into the JIT, because there's lots of stuff that brrt couldn't work on.

You asked me what I'd spend money on. Language design is not a money problem. It's a REALLY HARD SPACE problem.

20:18

Unless you are referring to getting @Larry enough mental space to work on those really hard problems for a while.

Do I think there are warts? Of course, I'm not blind.

20:19

But do I think they require wholesale rip-out-key-parts surgery? No. But you are free to disagree. :-)

I think what they mostly need is people who are capable of thinking about the problems and don't have their attention super divided.

20:20

leont

Why do people think language design quality matters for popularity

I mean, *javascript* is currently the most popular language for server side programming, and that has been designed in less than two weeks (and it showed)

20:21

sena_kun

.oO ( Java is soooo super designed )

japhb

leont: I don't know. But AlexDaniel is correct that benchmarks are much easier for people to make decisions over than looking at a language holistically.

leont

Frameworks and tooling matter much more

20:22

japhb

And I understand his frustrations about performance.

And after watching this community for years, the best I can tell is that over half our performance team is benched.

NPI.

timotimo

"NPI"?

20:23

leont

No pun intended

AlexDaniel

I'd make sure that any raku feature can be described in just a few sentences, remove all edge casing that we currently have (allowing very easy mental model of any feature and language as a whole). I'd remove a lot of features that are rarely used, making the language and compiler plainly smaller, allowing devs to focus on the good stuff. I'd also make sure that any feature can be easily translated into efficient code without any black

magic, and leave the black magic for making it even faster. Stuff like that.

japhb

(I wrote our earliest OpenGL binding, back in the Parrot days. I sped up Terminal::Print until it could do animation. I *get* performance complaints.)

AlexDaniel

leont: that's a very good question indeed

japhb

AlexDaniel: I think what you're describing is a different language. Depending on how you approach it, it might still be in the Perlish family of languages, but maybe you're looking to go farther and just want "inspired by". Ruby, for instance.

20:25

ShimmerFairy

I'm personally not a fan of a reductive approach for a language humans are intended to use. (MIPS CPUs aren't designed to be enjoyable to program, for example)

AlexDaniel

I'm describing a better language that Raku can become

20:26

japhb

I have a very simple bias: I have only so much available keyboard time, and certain limitations on how I think. I need to be able to express my thoughts in a very high-leverage language that fits my brain patterns well. This one mostly does.

AlexDaniel

you can say that any proposed change, if big enough, describes a different language. It's not a very useful way of approaching the issue at hand

20:27

japhb

That said, a language with some of the design patterns of a Perl, but with the FAST FIRST view of something like LuaJIT might be quite interesting for certain tasks.

AlexDaniel: I meant as different as Perl and Raku are. More than that and you get Perl v. Ruby and ever wider variants of clearly different languages.

20:28

20:28 chansen_ joined

japhb

Raku is Perl made much bigger. You seem to be asking for Raku made much smaller.

20:29

ShimmerFairy

But you're saying that the entire language is crap and needs to be reworked, which is the biggest kind of change you could possibly advocate for, and would actually make it a different language.

japhb

Which is totally interesting, but not the same language anymore.

AlexDaniel

I thought that Raku is Perl done better, not bigger

20:30

I guess I was wrong to think that

japhb

IMO, it *is* better. But there are a lot of Perl folks who would disagree.

leont

Perl and Raku have one thing in common that may not be obvious anymore in case of the former: they're incredibly ambitious projects doing something that hadn't been done before

Raku's main problem is that this ambition level is hard to keep up with given rather limited resources

20:31

japhb

But you can't deny that when @Larry set down the original design documents for Perl 6, they definitely went *way* bigger.

MasterDuke

i would say the grammar support (and the concept of braids) is certainly a "bigger" feature than its closest equivalent in Perl

leont

Size is not necessarily the problem, you don't need to know 90% of it to use it.

20:32

lizmat

and things like STM got completely scrapped

AlexDaniel

leont: but that's the problem, nobody really knows more than that

leont: for any feature you use you'll find painful edge cases

japhb

lizmat: jnthn I think did the best job of scrapping that one -- by pointing out why it actually didn't solve the problems we needed to solve.

20:33

AlexDaniel

and at some point I just got frustrated with that

what's STM?

lizmat

Software Transactional memory

leont

Raku keeps giving me things to learn, that's something I enjoy about it

lizmat

basically rollback for variables

well, actually a bit more than that

20:34

AlexDaniel

leont: I look at stuff like this: docs.raku.org/language/traps#Using...t_of_lists

MasterDuke

huh, i either never knew or have completely forgotten than Raku had any plans for STM. when i think of a language and STM all that comes to mind is PyPy

AlexDaniel

leont: and get extremely paranoid

japhb

AlexDaniel: Right, so. Here's my suggestion for you, you are free to ignore it. Jnthn right now is going through the really hard work of defining what exactly this language means, because having a DOM for the program forces you to think that way. He is cutting down externalities and forcing each node type to show its own complexity. Perhaps work from that to determine what you want to cut or clean?

sena_kun

MasterDuke, haskell as well...

MasterDuke

ah, right

20:35

AlexDaniel

leont: like, if things behave differently depending on the amount of elements, how do I write the code correctly?

leont: for this particular case there isn't even a good solution

japhb

MasterDuke, sena_kun: Yeah, I think Audrey++ implemented an early STM because the Haskell folks were working on it.

AlexDaniel

at least I don't think I have seen one

japhb

lambdacamel work

AlexDaniel: The waterbed theory of complexity is a real thing, not (just) a joke.

20:36

AlexDaniel

well you are forgetting that other languages don't have that trap

my believe is that having code that does exaclty what you tell it to do is good, even if it'll be a tiny bit more verbose

20:37

japhb

AlexDaniel: Yes, they do. C is perhaps the strongest example of it.

Larry just chose to push down on *different parts* than other language designers.

20:37 stoned75 left

AlexDaniel

japhb: single argument rule in C? What do you mean?

20:38

japhb

I didn't say anything about a single argument rule?

sena_kun

AlexDaniel, horstmann.com/presentations/c-traps/#(1)

20:39

AlexDaniel

japhb: “here's a trap in Raku that other languages don't have” “yes, they do” ?

japhb

I meant, C tried to be as simple as possible, and thus created an epic nightmare for everyone who wants to write portable and secure code. The complexity was passed HEAVILY to the language users.

lizmat

the single argument rule allows "for @a { }" to work

nine

AlexDaniel: just a note. I personally am not using raku all that much. My company however is using it at a level where breaking it would throw a serious wrench into the works and we're moving fast towards mission critical usage. And we do so because it allows for us to get more done and because it solves a lot of problems we had in 15 years of using Perl.

20:40

lizmat

otherwise you would have to say something llike

japhb

I had thought you were responding to me, but it was to someone else.

lizmat

for @a.list { }

AlexDaniel

sena_kun: that's a very nice presentation, yes

ShimmerFairy

One minor trap I can think of in C is that objects are identified by structure and not by name, which would be a surprise for people from other languages.

20:41

AlexDaniel

lizmat: um… are you sure?

lizmat

yes

AlexDaniel

lizmat: I mean, really?

lizmat

yes

AlexDaniel

so if I write that in any other language… why does it work there? :)

20:42

lizmat

because logically, "for" is basically map @a, { ... }

AlexDaniel

not really? IIRC there were enough differences

lizmat

AlexDaniel: probably because they a. don't have arrays as objects, or b. they special case it ?

japhb

AlexDaniel: Because the other languages slice the iteration special cases differently.

20:43

ShimmerFairy

For example, C++ 's for (auto & i : vector) { } loop only works on things that have iterators.

AlexDaniel

ShimmerFairy: and what's wrong with that?

20:44 stoned75 joined

nine

AlexDaniel: you can't do for (x, y, z) { } in C++ and that's something I'd very much miss if it was no longer possible in Raku

20:44

ShimmerFairy

nothing, just pointing out that other languages have their own "special" rules for loops.

japhb

AlexDaniel: We're not saying they're wrong. Just different.

AlexDaniel

alright, and what I'm saying is the way Raku does it is just wrong

20:45

by wrong I mean could be much better, more predictable

again, you can feel free to disagree and be all defensive about it, that's fine

lizmat wishes AlexDaniel had been around before and during the GLR

japhb

AlexDaniel: You are caught up in right and wrong I think, and also *seem* to be under the assumption that small changes can be made without ripple effects.

ShimmerFairy

I mean, it is predictable. Like in any language, you just have to be predicting from the right start point.

AlexDaniel

japhb: I know that it can't be done easily, ... operator is a great example of that

20:46

japhb

Perl 5 tried to adopt things they liked from Perl 6, and then discovered much to their surprise and unhappiness that the complexity is not so easily divisible.

AlexDaniel

which is why I'm saying “dismantle the language into pieces and redo them right”

japhb

Smart match being I think the most infamous example.

ShimmerFairy

Funny thing is I barely remember GLR, but I faintly recall it was a relief. I still have problems with lists, but it's probably just a case of me needing to go over the documentation to understand things better (and maybe shake loose some pre-GLR remnants in my head)

20:47

japhb

AlexDaniel: So ... what's stopping you? I'll turn around something you said earlier: If you had money and time, how would you go about making the changes you want?

AlexDaniel

lizmat: I was around during the GLR, just as a user though

japhb: I explained it earlier after your answer

20:48 lichtkind left

japhb

AlexDaniel: I was around for the GLR. (I remember it well because one of the participants actively mocked me at the time.) But we ended up with something I think works better than any of my ideas would have.

20:48

AlexDaniel

japhb: basically get everyone to work on simplifying everything

leont

Single argument rule doesn't always work out well, that I agree with. I'm not sure what the alternative would be

20:49

japhb

AlexDaniel: But that's the one thing you can't do -- get any of us to do anything we don't want to do.

ShimmerFairy

But that's not really an answer. Part of the issue is that "just change everything" is an idea people can't really work with. Either there are a few specific things you're not describing in detail, or you're asking the community to just get together and design a new language when they don't already want to.

AlexDaniel

ShimmerFairy: there are not a few specific things, there are a lot of specific things I can give you

japhb

AlexDaniel: SO DO SO. Write them down in your own design docs.

20:50

AlexDaniel

too much work for a single person

does anybody want to join?

japhb

I don't want a small language for my day to day, for the same reason I don't speak C to my family, I speak English.

Best question. :-)

nine

I'd certainly be interested in things that can be removed to improve performance when doing so doesn't kill the value proposition

20:51

jdv79

is it really about simplification or is it more about consistency/least surprise/more intuitive?

20:52

AlexDaniel

jdv79: they go hand in hand

jdv79

i'm not sure Perl has ever been about simple - quite the opposite actually

20:52 lichtkind joined

nine

It's funny because most WAT situations I've had with Raku so far were of the kind "WAT this actually works? Just like that?"

20:53

jdv79

there's a difference between complexity and complications

AlexDaniel

nine: well, let's say I propose a way for a regex to fill in given variables with matches

japhb

nine: :-D

rypervenche

AlexDaniel: I mean, if you're not willing to put in the work to say what you find wrong in the language, how is anyone else expected to put in the time to look at "fixing" it? I might start off with something at least that you can show to people and who knows, perhaps some of your ideas might be liked and could shape Raku in the future. But you'd need to start with something.

AlexDaniel

nine: I haven't thought that through enough, but just as an example

nine: for performance reasons, it'll also mean that by default it won't give you a pretty tree with a bunch of objects

MasterDuke

jdv79: i'd sort of disagree. i'd say it's simpler to open a file and run a regex against each line and store some info in a hash in Perl/Raku than it is in C

20:54

lizmat

if $expression that is not Bool -> $expr { } # should that stay ?

japhb

rypervenche: To be fair to AlexDaniel, he just asked for volunteers to help, I think that's fair.

ShimmerFairy

Doesn't /$<named-match>=[my regex]/ already accomplish that?

nine

Like that we can create a cro route like `get -> MeinAtikon::Authentication::User $*user {` and get the user object bound to that dynamic variable

AlexDaniel

nine: so, does that kill the value proposition?

nine: I'm asking this because for every feature that I'd remove or simplify, you'd always find somebody saying “oh but I use it” or at the very least “oh but it actually sounds very useful let's not remove it”

20:55

lizmat

"remove 'format' from Perl"

AlexDaniel

this is how we got to this point where new features are just layered on top

lizmat

but that's just where the design of Raku comes in

20:56

AlexDaniel

ShimmerFairy: can you do it into an external variable without creating any new objects?

besides a few Strs, of course

lizmat

we can (and have) removed features from older versions

ShimmerFairy

You'd have to create a new object regardless, and you can access it outside as $<named-match> (or less sugary as $/<named-match>)

20:57

leont

We have removed at least one feature that I miss

japhb

AlexDaniel: I'm not sure that's true. The core is large, because some of the concepts have to be large to be viable at all. Yes, there are things that are not core concepts that exist in Rakudo-as-implemented. But I'd say a surprisingly large part of Raku is load-bearing.

leont

jdv79: to quote the first sentence of the camel book: "Perl is a language for getting your job done" ;-)

lizmat

leont: which one is that ?

20:57 squashable6 left

AlexDaniel

ShimmerFairy: why would I need to create a new object? Strs are fine, they should be relatively cheap on moar

20:57

20:57 squashable6 joined

leont

flatmap

20:57

AlexDaniel

leont: flatmap was extremely confusing

20:58

lizmat

actually, flatmap still exists ?

nine

AlexDaniel: so what would that look like? An adverb on the regex?

ShimmerFairy

You could also do something like my $*str; ... /$<tostr>=(...) {$*str = ~$<tostr>}/

leont

I disagree, there's only one sensible way for it to work, and I used it all the time

20:59

AlexDaniel

nine: ↑ it'd look like that just less verbose, something like (but probably different): / $foo=[ . . . ] /

rypervenche

flatmap is deprecated in 6.d and will be removed in 6.e docs.raku.org/routine/flatmap

lizmat

ShimmerFairy: having just been down into the Cursor / Match / Grammar rabbit hole

leont

Which may be because I'm used to Perl, and flatmap actually does what map does in Perl

lizmat

I can agree that: a. it is a very complicated piece of code

21:00

AlexDaniel

nine: in the majority of cases you either don't need anything at all (just a Bool on whether it matched or not) or you just need to get some data out

lizmat

b. that way too many Cursor / Match objects are created

AlexDaniel

nine: with syntax like this you can pretty much destructure a string into your variables, with no overhead cpu or memory-wise

21:01

lizmat

and c. that there is no way to make this better without re-implementing the regex engine from scratch

with the current knowledge

ShimmerFairy

Yeah, I could easily see a difference in what /.../ regexes do from grammar { } regexes, but then you'd have to deal with crossing that boundary (which might not be too big a deal, but still)

21:02

AlexDaniel

nine: the compiler can still do a lot of clever stuff to figure out if you're using these variables at all, and decide not to even create the Strs

jdv79

is map().flat not the same?

i know i tried to use duckmap once and gave up cause of a bug

leont

My general impression is that the regex engine is the primary performance bottleneck anyway. I would guess a lot of it needs to be rewritten anyway.

timotimo

i do believe there's a "simple match with regex" routine, but there's also comb that doesn't return match objects by itself

unless you :match as argument

leont

jdv79: yes, but it has a very different endweight

AlexDaniel

timotimo: .contains can now take a regex and return a Bool only, but then how do you get the data out?

21:03

ShimmerFairy

It would be in $/ presumably.

AlexDaniel

ShimmerFairy: no

timotimo

you mean .from and .to info?

lizmat

not getting the data out is exactly what makes .contains(//) fast

AlexDaniel

timotimo: strings themselves

timotimo

wouldn't you use comb for that more likely?

let me dig out the simple match thing

21:04

AlexDaniel

see, my proposal is to make getting the data out fast. Only strings will be created

lizmat

and with my current knowledge of the Match machinery, can make it to break actually

nine

AlexDaniel: I wonder if type constraints on the target variables could be used by the compiler to determine that full blown Match objects aren't actually requested. That'd be something that can be done without even having to change the language.

21:04 stoned75 left

lizmat

AlexDaniel: how can you backtrack on strings ?

21:04

AlexDaniel

lizmat: Nil the variable if you go back

21:05

leont

.map().flat is confusing when the map argument takes multiple lines, and works poorly with «map: -> $foo {}»

timotimo

what was it called again ...

nine

AlexDaniel: the Cursors/Match objects are used within the regex engine itself to keep the state. So without them there can't be backtracking

AlexDaniel

lizmat: it's an extra step indeed in case of backtracking, but not much can be done about that

nine: that's just implementation details

21:06

lizmat tries not to be snarky

.oO( SMOP )

nine

Well that is actually a good point. Just one that we could read as "ok, the language is actually not the problem here, we have to improve the implementation"

AlexDaniel

nine: fast parsers exist, that's not an issue. The problem is that even if the parser itself was very fast (one way or another), you'd still be getting all the match object you didn't ask for

21:07

now, jnthn argues that some black magic can make it go away

21:08

japhb

As the oldest (IIUC) portion of the still-existing code, it stands to reason that the regex engine wasn't built to take advantage of all the stuff we've learned since about being efficient in this language.

AlexDaniel

I think that's extremely optimistic, but maybe jnthn knows better

nine

AlexDaniel: I tend to trust jnthn on these matters. His track record so far has been pretty spectacular :)

ShimmerFairy

Those match objects, to my limited knowledge, have to exist for the parser to work as it's currently designed, so hiding them from the user wouldn't help much.

AlexDaniel

and if so feel free not to change anything and just wait until the compiler suddenly fixes all inherent performance issues

21:09

nine

But then I'm very familiar with the wonders that MoarVM already does

timotimo

maybe the thing i was looking for was kicked out for some reason

japhb

AlexDaniel: Like, say, JavaScript?

JavaScript as a language was designed to be slow. And then we learned more about computer science. Jnthn has literally been doing that.

21:10

timotimo

the match objects themselves aren't so expensive, the mapping of matched things in the match object is the most expensive thing

21:11

is my understanding

AlexDaniel

timotimo: how's that?

lizmat

actually, I'm in half a mind to re-implemet the regex engine in Raku, with the current nqp::ops for the hard work

japhb

lizmat: Wow, and I thought your last attempt was ambitious.

21:12

lizmat

well, it's the logical conclusion of my attempt, really

japhb

I mean, it would be awesome if successful, but wow.

ShimmerFairy

timotimo: IIUC are you saying we could benefit from something like C++'s std::string_view class, providing a read-only look at a Str somewhere else in memory?

raku-bridge

<Vendethiel> AlexDaniel: backlogging now, if you can give me a few more languages with macros and user-defined operators, I'd love to see it. (outside of the obvious few like haskell and the like/scala/julia)

AlexDaniel

timotimo: as I see it, just save the position when starting the capture, pop it when finishing and create a lightweight vm str from the input string

21:13

lizmat

my attempt basically failed on what I perceive to be a hack (a brilliant one, but still a hack)

AlexDaniel

timotimo: what in that process can be slow?

lizmat

in the way <( and )> are implemented

japhb

ShimmerFairy: we already do that. Probably not the same way, but yeah, at the bottom layers, strings are immutable -- which we can use for referential transparency.

lizmat

they generate "fake" sub-Match objects

raku-bridge

<Vendethiel> japhb: are they?

ShimmerFairy

japhb: ah, so it's just invisible to a Raku user then.

21:14

lizmat

which means that having sub-Match objects in a Match object, does not mean there are actual sub-Match objects

japhb

Vendethiel: That was my understanding. It's possible I am wrong, but that's how I understood it.

lizmat

that the user will see

timotimo

ShimmerFairy: strings are already read-only, and when we take a substring we usually have it be a "view", these are called "strands" inside moarvm

raku-bridge

<Vendethiel> ShimmerFairy: I seem to remember chrome and firefox going for such an optimization, but with a different path. In one, if you keep a substring [0,50] of a very long strong, then that view prevents the original string from being collected

21:15

lizmat

so that makes lazy introspection of Match objects expensive, because it needs to look out for those cases all of the time

raku-bridge

<Vendethiel> ropes, strands, ...

timotimo

yeah, we may want to toss out long strings that don't have many references to them

but that's more work for the garbage collector that needs to pull its weight

raku-bridge

<Vendethiel> yeah, well, C++ doesn't really care about its GC :)

ShimmerFairy

hard to care about a GC that doesn't exist :P

21:16

raku-bridge

<Vendethiel> it's optional since C++11 :-P.

<Vendethiel> (well, it was added optional is what I mean, and what I joked about)

japhb

I was about to say, they added one

Ah

leont

A GC with C++ wouldn't make any sense, really

21:17

ShimmerFairy

wait, C++ can ship with a GC? First I'm hearing about it (unless you mean the Allocator business)

leont

It's pretty damn good at not needing one, IME

raku-bridge

<Vendethiel> ShimmerFairy: no, I do mean a GC: www.stroustrup.com/C++11FAQ.html#gc-abi

<Vendethiel> leont: locally it can be useful (cyclic object graphs i.e.)

21:18

ShimmerFairy

Huh, I suppose that fell out of the changes they made to the memory model.

raku-bridge

<Vendethiel> I have no idea who thought it was a good idea, honestly.

<Vendethiel> (I don't know of any C++ implementation with a GC; I really did mean it as a joke.

21:19

timotimo

in cpp you usually use either unique pointers that make sure nothing gets shared and is therefore fine to locally destroy, or have shared_pointer which is a reference counting thing?

raku-bridge

<Vendethiel> However, std::string_view can be a bit dangerous with the default move operator)

<Vendethiel> timotimo: shared_ptr is not very good performance-wise and has other gotchas (of course it's C++), so it's usually raw pointer when you don't own, unique_ptr when you do own, shared_ptr when you need refcounting

leont

shared pointers should be a small minority, really

21:20

ShimmerFairy

timotimo: remember it's backwards compatible with C, which means backwards-compatible with garbage programming practices (relative to what you're supposed to do in C++, at least)

raku-bridge

<Vendethiel> (and then you need some other solution when you have a cyclic graph like I mentioned earlier, Herb Sutter made several talks about github.com/hsutter/gcpp for example)

<Vendethiel> (still, it's an incredibly low % of cases)

21:21

AlexDaniel

weekly: AlexDaniel wants to turn Raku into a much simpler, faster, and slightly different language. You decide what Raku 7 will become. Please join #raku-dev and tell us if you want to work on that. Exciting times!

21:34

notable6

AlexDaniel, Noted! (weekly)

AlexDaniel

something like that?

jnthn

A name without Raku, and a different channel, please. Enough is enough.

21:35

AlexDaniel

alright

timotimo

yeah maybe don't overplay the 7 thing too much

AlexDaniel

weekly: scratch that

notable6

AlexDaniel, Noted! (weekly)

AlexDaniel

good luck everybody!

timotimo

it could end up sounding like mocking or something?

21:35 kawaii left 21:36 kawaii joined

jnthn

Yes, quite aside from everything else, it would be incredibly bad from with regard to the Perl 7 effort.

21:36

AlexDaniel

that could've been adjusted, but the message is very clear anyway

21:37

so please don't blame anybody that nobody wants to work on that

21:38

cya

21:38 AlexDaniel left

raku-bridge

<Vendethiel> No language list for me to explore, then. Too bad, more macro-enabled languages would've been fun to look at.

21:38

lizmat

notable6: weekly

21:40

notable6

lizmat, 2 notes: gist.github.com/1d5a0017c24527385c...4c33c41045

lizmat

notable6: weekly reset

notable6

lizmat, Moved existing notes to “weekly_2020-07-08T21:40:52Z”

timotimo

i didn't think the message AD proposed for the weekly sounded self-sabotaging or anything?

21:44

MasterDuke

AlexDaniel`: i've forgotten the name, but there was that guy a while ago who was compiling a subset of raku to lua or something like that. he might have an interesting take

AlexDaniel`

timotimo: well, people kept telling me why don't I do the work myself instead of ranting here, I explained that this is impossible to do alone and tried to find those who are interested and coordinate the efforts. Then I was immediately told to stop and move elsewhere.

21:46

timotimo

oh you reappeared without me getting a "has joined" line :D

21:47

hence the third person

ShimmerFairy

It only came across to me as very presumptive. Like, "of course there's going to be a Raku 7 that makes a bunch of radical changes"

AlexDaniel`

it's totally fine, I'm not mad, it's just that there's not much I'll be able to do here

timotimo

AlexDaniel`: you can totally take it to #raku instead of #raku-dev, i would expect

AlexDaniel`

MasterDuke: there was somebody who was compiling a subset of raku to native code

21:48

or something like that

fanlang was it?

timotimo

i thought of fanlang, too

AlexDaniel`

my understanding is that they dropped the efforts

MasterDuke

that's what it was thinking of

timotimo

oh? i thought it was just going to stay in-house for a long while?

AlexDaniel`

and it wasn't open-source anyway

MasterDuke

they might have some good lessons-learned

21:49

AlexDaniel`

yeah, like don't try to reimplement the language alone

Vendethiel: raku doesn't exactly have usable macros. Sure there are some modules that manage to use them, but it's not exactly a feature to brag about. I guess it will change soon. As for other languages, I haven't really tried macros in languages like julia, so I can't really recommend you anything.

21:53

timotimo

AlexDaniel`: honestly, i think a bunch of things you've mentioned could be simple to do as a starting step

21:57

going without single-argument-rule could possibly be a challenge, depending on whether it's used in core or not

i've meant to have something that tosses out like half built-in classes to accelerate development or something like that

21:58

i never did get around to it

but i feel it could be interesting?

tobs

off the top of my head, single argument rule appears in the signature of &cross

(came up a few days ago)

21:59

timotimo

OK, toss cross for now :)

AlexDaniel`

timotimo: I will do absolutely nothing until core developers agree that they won't be hostile to coordinated efforts to create a better next version of Raku

timotimo

that sounds like something you can't really just blank-statement-sign

22:00

lizmat

I am not hostile towards creating a better next version of Raku

AlexDaniel`

timotimo: you can start by making sure not to tell me to go to another channel

22:01

japhb

AlexDaniel`: Is there a downside to starting a new project name and creating a separate channel? I don't think people were trying to be mean there, just saying "That's not what *this* space is for."

lizmat

AlexDaniel`: then stop using words as "crap"

timotimo

the "go to other channel" issue is probably a "core devs who are actually doing a load of work need a channel that's more focussed on immediately-relevant-to-raku in-the-moment stuff they can read all of regularly"

thing

22:02

raku-bridge

<Vendethiel> AlexDaniel`: I don't need to be told Raku doesn't have usable macros :)

japhb

timotimo: Exactly.

raku-bridge

<Vendethiel> But you said this: <AlexDaniel> that's not the point. Many languages have macros and custom operators, changing the whole syntax in just a single statement is not as amazing as you make it sound

22:02 Altai-man_ joined

raku-bridge

<Vendethiel> I was hoping to explore some of the "many languages"

22:02

AlexDaniel`

explore Julia

timotimo

putting a broad discussion of possible improvements, avenues of changing, building a group, etc, wouldn't be right for here

japhb

Vendethiel: raiph might have insights there. He hangs around a lot of the language design boards.

22:03

raku-bridge

<Vendethiel> Did (it's also in the list I mentioned afterwards)

japhb

(Actually, might have misgendered there. If so, sorry raiph!)

raku-bridge

<Vendethiel> My path crosses raiph's fairly often.

22:04

AlexDaniel`

timotimo: so where would it be right? I don't get it. “Yeah you are free to think about radical raku changes but not here, go away”

timotimo

i thought raiph's realname was actually "Ralphie Boy"! /s

AlexDaniel`: i would suggest #raku

AlexDaniel`

you leave me no actionable choices. No realistic ones

22:05 sena_kun left

AlexDaniel`

you can suggest all you want but jnthn said without Raku

22:05

timotimo

i believe you misread his statement

lizmat

no, I believe that's a correct assessment

22:06

timotimo

i interpreted it to mean "don't sell it under the raku name just yet" for the weekly message

(also artistic language 2 has something in it about that?)

lizmat

AlexDaniel` Raku and its sub projects are open source

you seem to want to make a new language that is simpler

but that would not be raku

22:07

yet you insist it be called Raku 7

timotimo

Ragout

Ragú?

22:08

AlexDaniel`

I don't have enough resources to start a fork, sorry

raku-bridge

<Vendethiel> tasty, tasty use v6;

lizmat

if there is *anything* in the world that the next version of Raku should be called, it should *NOT* be Raku 7

AlexDaniel`

lizmat: that I don't mind

lizmat

that could be considered willfully squatting on the Perl 7 effort

AlexDaniel`

point is, if I was working on something like that I'd fix versioning

that's a very old idea before Perl 7 came around

raku-bridge

<Vendethiel> especially considering who was against the currently "weird"-considered naming scheme :-)

lizmat

versioning will be fixed somehow

22:09

personally, I would be in favour of the next language version of Raku to be called Raku 20201

personally, I would be in favour of the next language version of Raku to be called Raku 2021

raku-bridge

<Vendethiel> hah :D

AlexDaniel`

…

raku-bridge

<Vendethiel> now that one would throw people in a loop

lizmat

as we probably won't be able to make it that far this year

raku-bridge

<Vendethiel> there are many major parts of raku I dislike and would prefer differently, but I understand why they're that way and I still consider other things I get by using Raku worth it.

lizmat

AlexDaniel` old idea or not, it is now claimed by the Perl community, and we should not want to interfere with that in any way

22:10

AlexDaniel`

it's a detail I don't care about right now

we could've changed it to Raku Next or whatever in the weekly, or just call it next major version of Raku, it's such a small detail

22:11

but the actual message is “not Raku, go away”

raku-bridge

<Vendethiel> the issue is that you want to squat it for yourself, I reckon.

lizmat

well, I guess you managed to piss off the one guy you didn't want to piss off

AlexDaniel`

so, again, not much I can do. Sorry if anyone is interested.

timotimo

putting a project out with A Name right now will make that name unavailable for other different projects in the future

22:13

so make Raku Next or whatever now, that'll be awkward if for any reason it does not pan out

lizmat

I've spent a lot of time in Raku's internals, mostly in Rakudo, some in NQP, hardly anything in MoarVM

raku-bridge

<Vendethiel> I don't understand the confusion. If you contributed to Ruby, and then asked "I want a better Ruby to be made, can I call it Ruby 4 and hopefully people make it real?" -- would you expect it to be received well?

lizmat

I agree a lot of things could be done better, and whenever I can, I will make them better

22:14

some require a lot of work

and sometimes (more often than not), it is all in vain

because of some edge case, or because the refactor turns out to not be faster after all

val() processing is a case in point

22:15

weeks of work got nixed because of a difference in the 10th decimal of the string representation of a floating point value

shit happens

22:16

is it frustrating? yes

you have no idea

but that does not mean to me that we just should kill allomorphs

22:17

AlexDaniel`

Vendethiel: it's a fair point. I think the difference between it being received well or not is whether core devs agree with the idea. So if most people here disagree then it should not happen. I'm OK with that.

lizmat

are you?

you don't give the impression?

AlexDaniel`

I'm disappointed but I'm OK

22:18

[Coke]: I don't know of a good way forward.

22:19

for the project that is (it was a question asked by Coke that I answered differently before the conversation)

22:20

timotimo

is something wrong with my irc client? the last message from coke i see is from like 3 hours ago?

22:21

ah that could explain it

lizmat

AlexDaniel`: maybe it is an idea to describe what the ... operator should do and should not do ?

22:22

because I agree that could benefit from losing some of its magic

raku-bridge

<Vendethiel> .oO( and the crazier things it used to do :-P)

AlexDaniel`

lizmat: I did it twice I think, my final problem is how to get ranges like ‘a’…‘z’ to work

and that I wasn't able to solve

22:23

lizmat

what is the issue with "a" ... "z" ??

I thought the issue is really with "aa" ... "cc" ?

AlexDaniel`

because after my changes you won't have a .succ on Strs

22:24

m: say ("-5"…∞)[^10]

camelia

(-5 -6 -7 -8 -9 -10 -11 -12 -13 -14)

AlexDaniel`

notice how it counts the wrong way

22:25

lizmat

m: say (-5…∞)[^10]

camelia

(-5 -4 -3 -2 -1 0 1 2 3 4)

AlexDaniel`

well, “wrong”, but in code like ($foo … ∞) you don't know what it's gonna do

lizmat

m: say (<-5>…∞)[^10]

camelia

(-5 -4 -3 -2 -1 0 1 2 3 4)

AlexDaniel`

so, in Raku you can generally use numeric ops with strings and not notice it

lizmat

seems to favour the Int interpretation

AlexDaniel`

but in this particular case it shoots you in the face

22:26

lizmat

so, maybe we should warn if a string starts with - and is numeric ?

22:27

if it is the start-point of a ... or maybe just die ?

AlexDaniel`

there's a line of reasoning on why .succ on Strs doesn't make sense, and you can actually remove it just fine, if we're talking about the next version at least

but then there's this harmless case of ‘a’…‘z’

timotimo

that's a strange thing to warn about

AlexDaniel`

just don't allow .succ on Strs

lizmat

m: dd "aa" ... "cc" # note that this is *not* just doing .succ on Str

22:28

camelia

("aa", "ab", "ac", "ba", "bb", "bc", "ca", "cb", "cc").Seq

AlexDaniel`

there is a possibility to introduce a different op for stringy ranges, and temporarily compile ‘a’…‘z’ to that

right, and that behavior is just removed

so that … just does .succ or .pred

almost

lizmat

what troubles me about ... in this respect is *not* that it is using .succ basically

22:29

AlexDaniel`

but I don't know why you ask that. One way or another it'll be a noticeable change

lizmat

but that it is *not* using .succ in the "aa"... "cc" case

AlexDaniel`

yeah, exactly

22:30

lizmat

and the only reason I've been been able to find for this behaviour

m: dd "000" ... "777"

camelia

("000", "001", "002", "003", "004", "005", "006", "007", "010", "011", "012", "013", "014", "015", "016", "017", "020", "021", "022", "023", "024", "025", "026", "027", "030", "031", "032", "033", "034", "035", "036", "037", "040", "041", "042", "043"…

lizmat

aka, generating all of the possible chmod values

I feel this is making ... too magical

22:31

AlexDaniel`

I mean… this is old news to me. The behavior of … can't be described in just a sentence or two, it has special cases for everything

lizmat

... always using .succ can be understood, even if .succ is somewhat magical

AlexDaniel`

so many that it's really hard to understand the feature fully and hard to implement it properly

lizmat

no, not for everytihing

AlexDaniel`

which is why I reported many bugs when it gets things very wrong

22:32

so, yes, … should just call .succ or .pred

lizmat

I think foo ... bar ... baz is something that's icky

AlexDaniel`

that's the gist of it

lizmat

and that's the thing:

22:33

replacing the ... operator with an ecosystem module, is what Raku excels at

you can do that

tobs

m: say for 1 ... "07" ... -3

camelia

5===SORRY!5=== Error while compiling <tmp>
Unsupported use of bare "say". In Raku please use: .say if you meant
to call it as a method on $_, or use an explicit invocant or argument,
or use &say to refer to the function as a noun.
at <tmp…

lizmat

so, why not make it a module that people can use

tobs

m: .say for 1 ... "07" ... -3

lizmat

and if enough people like that, make it the default for a language version ?

22:34

ShimmerFairy

That "000"..."777" example feels like it came from the same place that said ?"0" should be False.

camelia

(timeout)1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
5…

tobs

(I never even knew ... was chaining)

lizmat

tobs: yes it is..

AlexDaniel`

well, first of all because the way I see it is that it's not just … that is wrong

22:35

lizmat

ShimmerFairy: agree it's something from the olden days

AlexDaniel`

so I can fix … and Strs will count down

and if I want to make it backward compatible to some extent, I'd have to do some tricks with the parser

lizmat

well, actually that feels like adding more magic to me

AlexDaniel`

that's a little bit too much to ask of a module

lizmat

"-5".succ can be understood

22:36

AlexDaniel`

and I don't know why you would even ask that if you want to fix the language itself

it can be understood, but it can also be removed

ShimmerFairy

I would be happy with ... only ever calling .succ and .pred on strings, since that is what it (conceptually) does with integers.

lizmat

so is your beef with .... or Str.succ ?

AlexDaniel`

if you want IO-like succ. then you can do "-5".IO.succ

both

you can fix … without fixing the other

lizmat

and one cannot be fixed without the other ?

AlexDaniel`

can't

22:37

ShimmerFairy

And yeah, making "-5"...Inf act like -5...Inf would be way too magical (it would be exactly like ?"0" eqv False)

lizmat

m: dd "foo.bar".suc # ShimmerFairy did you expect that?

camelia

No such method 'suc' for invocant of type 'Str'. Did you mean any of
these: 'sec', 'succ', 'sum', 'uc'?
in block <unit> at <tmp> line 1

lizmat

m: dd "foo.bar".succ # ShimmerFairy did you expect that?

camelia

"fop.bar"

AlexDaniel`

see, it's .IO.succ, Strs don't have a meaningful succ

22:38

lizmat

those are IO::Path semantics applied to Str

AlexDaniel`

that's why I want to remove it

lizmat

that's definitely a wart I'd like to see applied to IO::Paths only

ShimmerFairy

Isn't that for filenames like "frame00.png" ? That should definitely be in a fancier method, like say augment class Str { method nextfile() { ... } }

raku-bridge

<Vendethiel> that's what I remember as well

AlexDaniel`

well, a .succ on IO is alright

22:39

lizmat

ShimmerFairy: yeah, but having that behaviour on Str is what is being discussed here

ShimmerFairy

Yeah, my example was of a module adding that feature for people who wanted it, I should've been clearer.

lizmat

ah, ok

22:40

AlexDaniel`

that's already what .IO.succ does, I don't think it's wrong enough to need fixing

it does it through Str though, but that's just how it's implemented

22:41

ShimmerFairy imagines IO::Path.succ advancing the revision number instead of the bit before the extension on a really really old filesystem

AlexDaniel`

from what I remember

lizmat

AlexDaniel` IO.succ just does a $!path.succ

so we would need to move the logic

AlexDaniel`

yea

but what do you leave in Str.succ then?

lizmat

remove the . searching logic

AlexDaniel`

and?

22:42

describe proposed .Str.succ in a sentence or two

22:43

lizmat

with the current magic, but wiithout the extension logic

AlexDaniel`

that's cheating

22:44

:)

you do need to define it explicitly otherwise it's hard to tell what should be done with ‘a’…‘z’ and more complex cases

lizmat

look, the code for creating the .succ magic is basically already completely parametric

we could also use that to document the magic

AlexDaniel`

or just remove the magic

22:45

lizmat

github.com/rakudo/rakudo/blob/mast...C.raku#L18

AlexDaniel`

tell users to use .IO for filenames and + for numeric values

that's absolutely terrifying

22:48

ShimmerFairy

Description: Str.succ finds the last contiguous sequence of alphanumeric characters and increments it like a number. Alphabetic characters are advanced to the next character in the script they belong in.

22:48 leont left

AlexDaniel`

ShimmerFairy: did you mean numeric?

22:49

ShimmerFairy

No, I just wrote the "non-cheating" version of the description lizmat gave.

AlexDaniel`

ah…

22:50

well, it's actually a pretty good attempt for a new implementation

but I don't think it describes the current implementation well

22:51

ShimmerFairy

I literally just based it off of what docs.raku.org says, minus the filename magic.

lizmat is tired and goes to bed&

22:52

AlexDaniel`

yeah, I'm taking a break too

22:53

23:01 lizmat left 23:04 lizmat joined 23:46 lichtkind left 23:55 squashable6 left 23:57 squashable6 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!