undefined | Better HN

0 pointsdminik8mo ago0 comments

> It's quite rare for a function to unexpectedly gain a dependency on ...

If this was true in general, the function coloring problem wouldn't be talked about.

However, the second point is more interesting. I think there's a bit of a Stockholm syndrome thing here with Zig programmers and Allocator. It's likely that Zig programmers won't mind passing around an extra param.

If anything, it would make sense to me to have IO contain an allocator too. Allocation is a kind of IO too. But I guess it's going to be 2 params from now on.

0 comments

laserbeam8mo ago

> If anything, it would make sense to me to have IO contain an allocator too. Allocation is a kind of IO too.

Io in zig is for “things that can block execution”. Things that could semantically cause a yield of any kind. Allocation is not one of those things.

Also, it’s perfectly reasonable and sometimes desireable to have 13 different allocators in your program at once. Short lived ones, long lived ones, temporary allocations, super specific allocators to optimize some areas of your game…

There are fewer reasons to want 2 different strategies to handle concurrency at the same time in your program as they could end up deadlocking on each other. Sure, you may want one in debug builds, another in release, another when running tests, but there are much fewer usecases of them running side by side.

chrisohara8mo ago

> Io in zig is for “things that can block execution”. Things that could semantically cause a yield of any kind. Allocation is not one of those things.

The allocator may yield to the OS when requesting or releasing memory (e.g. sbrk, mmap, munmap)?

messe8mo ago

I don't find that a particularly compelling argument in this case, because so can accessing any memory address if it's not currently swapped in.

laserbeam8mo ago

Yielding in this context means to a different “thread” in your context, not the OS. If you want to express “this is a point where the program can do something else” it is a yield. If you block and can’t switch to something else… it is not.

So if you’re using an API like mmap like that you should think of it as IO (I don’t think you can, but am not sure).

1 more reply

pharrington8mo ago

Stockholm syndrome? Many years ago, I was specifically wanting a programming language where I could specify an allocator as a parameter! That's one of Zig's selling points.

throwawaymaths8mo ago

> But I guess it's going to be 2 params from now on.

>> So, if you discover that a code path you previously thought was pure actually does need to perform IO, then you don't need to apply some nasty viral change; you just grab `my_thing.io

camgunz8mo ago

Python, for example, will let you call async functions inside non-async functions, you just have to set up the event loop yourself. This isn't conceptually different than the Io thing here.

gpderetta8mo ago

But the asyncio event loop is not reentrant, so your faux sync functions cannot be safely called from other async functions. It is an extremely leaky abstraction. This is not a theoretical possibility, I stumbled on the issue 15 minutes into my foray into asyncio (turns out that jupyter notebooks use asyncio internally).

There are ways around that (spawn a separate thread with a dedicated event loop, then block), or monkey patch asyncio, but they are all ugly.

throwawaymaths8mo ago

except you cant "pass the same event loop in multiple locations". its also not an easy lift. the zig std will provide a few standard implementations which would be trivial to drop in.

1 more reply

Gibbon18mo ago

I do something like that with event driven firmware. There is an allocator as part of the context. And the idea that the function is executing under some context seems fine to me.

j / k navigate · click thread line to collapse

0 comments

laserbeam8mo ago

> If anything, it would make sense to me to have IO contain an allocator too. Allocation is a kind of IO too.

Io in zig is for “things that can block execution”. Things that could semantically cause a yield of any kind. Allocation is not one of those things.

chrisohara8mo ago

> Io in zig is for “things that can block execution”. Things that could semantically cause a yield of any kind. Allocation is not one of those things.

The allocator may yield to the OS when requesting or releasing memory (e.g. sbrk, mmap, munmap)?

messe8mo ago

I don't find that a particularly compelling argument in this case, because so can accessing any memory address if it's not currently swapped in.

laserbeam8mo ago

So if you’re using an API like mmap like that you should think of it as IO (I don’t think you can, but am not sure).

1 more reply

pharrington8mo ago

Stockholm syndrome? Many years ago, I was specifically wanting a programming language where I could specify an allocator as a parameter! That's one of Zig's selling points.

throwawaymaths8mo ago

> But I guess it's going to be 2 params from now on.

>> So, if you discover that a code path you previously thought was pure actually does need to perform IO, then you don't need to apply some nasty viral change; you just grab `my_thing.io

camgunz8mo ago

Python, for example, will let you call async functions inside non-async functions, you just have to set up the event loop yourself. This isn't conceptually different than the Io thing here.

gpderetta8mo ago

There are ways around that (spawn a separate thread with a dedicated event loop, then block), or monkey patch asyncio, but they are all ugly.

throwawaymaths8mo ago

except you cant "pass the same event loop in multiple locations". its also not an easy lift. the zig std will provide a few standard implementations which would be trivial to drop in.

1 more reply

Gibbon18mo ago

I do something like that with event driven firmware. There is an allocator as part of the context. And the idea that the function is executing under some context seems fine to me.

j / k navigate · click thread line to collapse