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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022