www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - my d blog has idea of effect system to replace nogc etc

reply Adam D Ruppe <destructionator gmail.com> writes:
In my blog this week, I described an idea I've had percolating in 
my brain for a bit about a user-defined effect system that could 
potentially move nogc, safe, pure, etc to library aliases - which 
would let you combine them as a fun bonus - among other things:

http://dpldocs.info/this-week-in-d/Blog.Posted_2022_08_15.html

Like with other inferred attributes, the argument-dependent and 
virtual function caveats had to be mentioned, but since I talked 
about them in other posts not too long ago I didn't want to go 
over it all again.

Next week, I'll probably write up release notes on arsd 10.9, 
which is overdue now but has a few new features (including ico 
file support, more http timeout control, a couple more hidpi 
linux fixes, a windows input gui fix, data uri transparent 
support, terminal cursor save/restore, and others) I'll tag once 
I finish regression testing. I doubt I'll announce that here 
since it is p routine but maybe, we'll see how spammy I feel once 
it is posted.
Aug 15
next sibling parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 15.08.2022 um 17:08 schrieb Adam D Ruppe:
 In my blog this week, I described an idea I've had percolating in my 
 brain for a bit about a user-defined effect system that could 
 potentially move nogc, safe, pure, etc to library aliases - which would 
 let you combine them as a fun bonus - among other things:
 
 http://dpldocs.info/this-week-in-d/Blog.Posted_2022_08_15.html
 
 Like with other inferred attributes, the argument-dependent and virtual 
 function caveats had to be mentioned, but since I talked about them in 
 other posts not too long ago I didn't want to go over it all again.
That would be really nice to have. I also had a similar idea in my mind for a while, with lots of potential use cases that came up in the past. The most prominent example would be something like vibe.d's ` blocking`, which currently just acts as documentation, but would be really useful if something like ` nonblocking` could actually be enforced at compile time - currently there is just a runtime solution for that.
Aug 15
parent Adam D Ruppe <destructionator gmail.com> writes:
On Monday, 15 August 2022 at 16:16:35 UTC, Sönke Ludwig wrote:
 The most prominent example would be something like vibe.d's 
 ` blocking`, which currently just acts as documentation, but 
 would be really useful if something like ` nonblocking` could 
 actually be enforced at compile time - currently there is just 
 a runtime solution for that.
Aye, async in general has a lot of uses of this kind of thing. In addition to just not hogging the worker thread, being responsive to a cancellation request is a nice thing. Speaking of blocking, one of the effects I'd envision is something like "loops". Something blocking on a loop can more harmful to the event-driven i/o model than other blocks - at least other blocking calls can be interrupted by signals or something. On the one hand, you might think of it as madness to say `denies_effect!loops`. How will you get any work done? But there's two interesting bits: 1) you might be able to define it with higher order functions and 2) D's `foreach` loop is special. See, a foreach loop can just by syntax sugar over an opApply function call.... and we could say one of those loops instead just has the effects of opApply (which would necessarily add the effects of the user-provided delegate, of course). So you could imagine an opApply that uses the hidden effects escape to implement a loop, but inserts its own periodic `if(yield() == CANCEL) return;` logic, providing both regular returns to the scheduler event loop and opportunities to cancel the task. Indeed, the work chunks may even be auto-parallelized in the process too. Of course, users could also use the trusted hidden effect, but the act of doing so at least reminds them that they ought to be careful.
Aug 15
prev sibling next sibling parent reply Guillaume Piolat <first.last spam.org> writes:
On Monday, 15 August 2022 at 15:08:01 UTC, Adam D Ruppe wrote:
 In my blog this week, I described an idea I've had percolating 
 in my brain for a bit about a user-defined effect system that 
 could potentially move nogc, safe, pure, etc to library aliases 
 - which would let you combine them as a fun bonus - among other 
 things:
I know it isn't really related, but currently on DUB there is 4 different nogc nothrow string library, -betterC or not, friendly licence or not, with various tradeoffs, and I'm about to add another one. D is balkanized in concentric circles: - -betterC D - disabled runtime D - nogc D - full D And more basic building blocks are being made for the least restricted part of D, such as allocators and concurrency. At a more basic level, we cannot share code.
Aug 16
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
And I'm building another.

Allocators already working, tons of Unicode stuff implemented.

Working on string builders atm.

But one key difference is it is designed to work with the GC even if it 
is -betterC  nogc  safe nothrow.
Aug 16
parent reply Guillaume Piolat <first.last spam.org> writes:
On Tuesday, 16 August 2022 at 15:01:05 UTC, rikki cattermole 
wrote:
 But one key difference is it is designed to work with the GC 
 even if it is -betterC  nogc  safe nothrow.
How do you do that?
Aug 16
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 17/08/2022 3:05 AM, Guillaume Piolat wrote:
 On Tuesday, 16 August 2022 at 15:01:05 UTC, rikki cattermole wrote:
 But one key difference is it is designed to work with the GC even if 
 it is -betterC  nogc  safe nothrow.
How do you do that?
Via dub's injectSourceFiles (that I added). https://github.com/Project-Sidero/basic_memory/blob/main/source/sidero/base/allocators/gc_hook.d https://github.com/Project-Sidero/basic_memory/blob/main/source/sidero/base/allocators/gc.d https://github.com/Project-Sidero/basic_memory/blob/main/source/sidero/base/allocators/locking.d#L111
Aug 16
prev sibling parent Adam D Ruppe <destructionator gmail.com> writes:
On Tuesday, 16 August 2022 at 14:57:04 UTC, Guillaume Piolat 
wrote:
 I know it isn't really related, but currently on DUB there is 4 
 different  nogc nothrow string library, -betterC or not, 
 friendly licence or not, with various tradeoffs, and I'm about 
 to add another one.
Yeah. I think some of that is going to happen regardless just because a lot of us have the not-invented-here syndrome, and some of the tradeoffs are rooted in legitimate concerns. When they have legitimate concerns, whether you have an effect annotation or not doesn't really matter (though the static checks are not always the best way to do it; a dynamic runtime check or a test suite might be just as good or even more appropriate). The lib might not be formally documented as unsuitable for you, but if it does something you can't allow, you're gonna be forced to find an alternative. So I think multiple libraries for different requirements is always going to happen, and is actually a good thing. And having this documented and/or tested (again, whether static checks or runtime checks) can also be a good thing. Sometimes at least. Though with D I think we're more duplicating because of just NIH or other sillier reasons than due to actual hard requirements in use. But still some of them are and even if we all worked together perfectly, we'd still want some separate libs that choose different trade offs.
Aug 16
prev sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Monday, 15 August 2022 at 15:08:01 UTC, Adam D Ruppe wrote:
 [...]
It's one of those things where it is better for learning a language when there are a smaller number of orthogonal features that can be built up into more complex things. safe, pure, etc. are good, but feel a bit hackish when coming new to the language. Would require a DIP and some work in implementing it.
Aug 16