It also means that you can start up asynchronous stuff all at once, and then do things with the futures/promises before they resolve, instead of having to work around it blocking by default

i've had the need to write async shit like twice in my life for discord bots in python and it was neither pleasant nor unpleasant

^

Though I guess you still have to go through and add .awaits

async should honestly be the default and where strict sequential evaluation is needed that should be provided for by a mix of explicit sequencing and compiler guesswork

(which is another argument for .await over await xyz(), since it's way easier to just paste that after the function call instead of having to check if the parenthetization is right and stuff)

yeah lmao

@UnrelatedString Wait wdym

@UnrelatedString SAME

@RadvylfPrograms Is this an argument for async/await, treating everything as if it's synchronous from the programmer's perspective, or something else

@RadvylfPrograms Oh wait I guess it's still kinda necessary since async changes the return type

@RadvylfPrograms i don't know eithe :P

r

I actually don't mind having to spam async/await, especially in Rust where verbosity around that sort of thing is kind of important, but I guess another option would be the compiler guessing where they're needed, and having a syntax to explicitly tell it to return a promise from a function call

E.g., xyz() would return the result, and await it if xyz is async (invisibly making the function the call is in async too if this occurs), and xyz?() would return the future unchanged if xyz is async, or wrap the result of xyz in a resolved future otherwise

That way you get select/join when you need them, but the far more common option of just awaiting is the default, and no distinction between async and non-async functions ever needs to be made

mmm

yeah that sounds nice

I actually might include this in Tundra, since it's intended to be written iteratively, and I've definitely run into "oh no, 20 new features in I need to add an async library" in JS before when doing that

Like rSNBATWPL. I had like a thousand sloc, thousands of function calls, then I realized I needed them all to be async since I'd doing I/O asynchronously. That was a lot of copying and pasting.

Yeah, I mentioned it a few days ago I think

huh

yep at least once on wednesday

@RadvylfPrograms I feel like there's probably some big problem with this approach, which is why existing languages don't do it, but I don't understand async enough to guess what it is. So I'd say go ahead and do it this way in Tundra, and then if there's a big problem with it, you'll find out and we can all learn something. :D

Inspired by my realization of why I like JS so much, that being that I can kind of just jump in and start writing stuff, whereas Rust takes more planning and kind of bullies you into writing bug-free, finished code

yeah i do remember that connversation

LDQ: What are good names for the following two operations? They both take a list L and a number N. One operation splits L into sublists of length N; the other splits L into N sublists of equal length.

chunk and divide? maybe

Ash called the first one "group" but that's a lot less clear than either of ^

although divide's a terrible name to distinguish it from numeric operations :P

yeah i'd expect group to be something about the values themselves

Do you really need both? You can accomplish the other given one of them just by dividing based on the array length

@RadvylfPrograms In a praclang, maybe not. In a golflang, absolutely.

I actually do like the idea of both for something like a golfing language though, as like, a generalization of the half list operation

Oh ninja'd

They can also have different behaviors when N doesn't evenly divide the length of L.

@RadvylfPrograms I'm not sure what syntax I'd want to use for this. ?() looks nice to me, except that it's already taken (optional chaining)

Ideally it'd be before the () rather than after so it's clear that it's changing the behavior of the function itself rather than the return value

I could do something really weird like a method on every function :p

xyz.future(...args_for_xyz)

some ellipsis variant :P

@DLosc In Pip, they are called Group (<>) and Chop (CH). I don't like how unrelated the two names are, tho. (Chop was added much much later than Group.)

chunk and chop for the alliteration :p

also come to think of it did either of you take "group" from brachylog or is there actually some deeper intuition to it

@RadvylfPrograms which is both a good thing and a bad thing

@RadvylfPrograms They don't really communicate the distinction between them though

Right

@UnrelatedString I don't think I did. Possibly it's from some older golflang.

If you're fine with longer names "chunks of N" and "N chunks" would be pretty clear

@DLosc vyxal calls them "chunk wrap" and "Divide List Into N Equal Length Parts"

So "Terse. Elegant." doesn't apply to the operator names, I'm guessing? :p

I'm looking for names I can write in UpperCamelCase that aren't too long. :P

@RadvylfPrograms yeah i feel like chop is too conceptually similar to chunk--if you're chopping vegetables, chances are you don't care how many slices you end up with, but you do care about he size

@RadvylfPrograms I only said the programs are short, not the docs :p

@UnrelatedString Hm, that's a good point. Shoot.

I honestly can't think of any words that clearly communicate to me a specific number of equally sized chunks

come to think of it chop might actually place stronger emphasis on the size than chunk :P

Parcel?

parcel's a good one

I'd really like "divide" if it weren't for the confusion with division

distribute?

Ooh that's not bad

divvy :P

I thought of that too :p

:þ

@DLosc "divideListIntoNEqualLengthParts" isn't too long though

Try it online!

See?

@UnrelatedString Honestly not a bad choice, it's short and at least to me clearly communicates the "into N piles" constraint

@UnrelatedString Hm! I like this developing theme of "words that would be used by pirates sharing booty equally among themselves"

"Spread" maybe, since it's spreading the items between N lists?

@lyxal Yeah but Try it online!

@lyxal right, it's much, much worse

@DLosc Now we just need operators named "shiver", "batten", "scrub", "keelhaul", "walkplank", and "landlub"

half of why i thought of divvy is it also has "div" in it without actually being divide

LDQ: Do you prefer Python's * or JS's ...? *'s quicker to type, but I feel ... is more intutiive and harder to confuse with things from other languages

@RadvylfPrograms Cop-out answer: I like both of them

@UnrelatedString yeah i forgot objects are always truthy

i prefer * for splatting but ... for writing the varargs

*

honestly the happy compromise is probably ..

:|

@RadvylfPrograms depends on what functionality you're comparing

because three monospaced periods are huge but we have two-character operators everywhere

@lyxal I mean they're basically identical functionality-wise, right?

and i agree that * is too close to other stuff

@RadvylfPrograms I mean are you talking about multiplication contexts, unpacking contexts or varargs contexts?

They both can splat into collection literals and function arguments, and both can be used for varargs in function definitions

@lyxal The last two, where *'s prefix rather than infix

conceptually i imagine for specifying varargs it looks like a kleene star (but on the wrong side of the expression :P) and for splatting into them it looks like something that has gone splat on your screen

but it's still the same character as the multiplication operator and c's dereference

double dot is invalid grammar :P

it's used for range operators :P

Issue with .. is that I'm probably already using it for ranges, and it's got all sorts of meanings in different languages, none of which are splatting AFAIA

yeah lmao

Like Lua uses it for concat IIRC, which I actually kinda like

...that's kind of disgusting

Compromise and do *** instead

(still prolly going for + tho since both JS and Python use it)

@lyxal Oh well that's used by my brand new "first-class redaction" feature where you can redact parts of your code in order to more easily treat them as black boxes

go the julia route and use the same operator as matrix multiplication since it's non-commutative :P

@UnrelatedString actually that gives me an idea - what if varargs modifiers were postfix in function headers instead of prefix and you used ? for optional, * for 0 or more and + for one or more arguments

...that's actually pretty based

^

And yuo could go full regex and have ??/*?/+? lazy variants, allowing for much more complicated vararg structures :p

having dedicated syntax for optional arguments without needing explicit defaults is especially smart

@RadvylfPrograms Tbis'd only make sense with type requirements or other constraints tho

that way you don't need any =None stuff for that, if you're strongly typed and have a dedicated optional type you can lift into it implicitly, etc.

@RadvylfPrograms async bad, threading good

@Ginger Apples and oranges

there is no comparison, I'm just spittin fax

And having to explicitly make threads for every little async thing is so much worse than even callback hell

i feel like explicit threading for async stuff would kind of defeat the point of all of this

let the compiler worry about that shit

And anyway, how do you deal with the results of those threads? Sure would be convenient if you had some way to...idk, await the results :p

@UnrelatedString what compiler

like yeah you'd literally still have to explicitly block on the results of the threads

Unless you forced people to use mutexes to return the result

Because as we all know the hot new thing in programming is more mutation

mutation is cool and good :p

this just in, maximum statefulness new best practice

@RadvylfPrograms is it bad that I'm actually considering this

there is one type and everything else is just a mutated version of that

honestly no :P

It'd just be a .future (or some better name) ()-less method of functions that returns the same function wrapped in a promise

what exactly are you considering it for

i want to say that's basically what python does but now i'm forgetting lmao

like i feel like there's just some dunder that the await operator calls under the hood

okay so not quite that

because __await__ is on the returned coroutine object instead of the function itself

and it's also the other way around

but you get the idea

huh?

no I do not get the idea

forget i said anything

since when have you had a neuralizer :p

you're asking that like you'd remember :P

oh no