View mode: basic / threaded / horizontal-split · Log in · Help
November 09, 2012
Immutable and unique in C#
Just stumbled over this, which is describing a type system extension for
C# for race-free parallelism:

http://research.microsoft.com/pubs/170528/msr-tr-2012-79.pdf

Independent of this article I think D is currently missing out a lot by
omitting a proper unique type (a _proper_ library solution would be a
start, but I'm not sure if that can handle all details). It would make a
lot of the cases work that are currently simply not practical because of
loads of casts that are necessary.
November 09, 2012
Re: Immutable and unique in C#
:) do they implement `inout`?
November 10, 2012
Re: Immutable and unique in C#
Am 09.11.2012 18:45, schrieb Kagamin:
> :) do they implement `inout`?

Haven't seen it, yet ;)

But seriously, they go a lot further with their `isolated` type
qualifier. That together with their functions, which are basically
weakly pure, opens up a lot of new opportunities for statically verified
code without casting around all the time or bending the code structure
so much that it hurts.

The article is quick to read in it's core and _really_ anyone interested
in D's development should read it. This pretty much what we have + the
bits that are currently missing (especially concerning objects in the
immutable/shared world).

It fits perfectly with what's already there, it's proven to be sound and
practical, and IMO it's definitely what should be implemented in D.
November 10, 2012
Re: Immutable and unique in C#
Sönke Ludwig:

> It fits perfectly with what's already there, it's proven to be 
> sound and
> practical, and IMO it's definitely what should be implemented 
> in D.

Seems fit to be added to Remus then :-)

Bye,
bearophile
November 10, 2012
Re: Immutable and unique in C#
On 11/10/2012 12:23 PM, Sönke Ludwig wrote:
> Am 09.11.2012 18:45, schrieb Kagamin:
>> :) do they implement `inout`?
>
> Haven't seen it, yet ;)
>
> But seriously, they go a lot further with their `isolated` type
> qualifier. That together with their functions, which are basically
> weakly pure, opens up a lot of new opportunities for statically verified
> code without casting around all the time or bending the code structure
> so much that it hurts.
>
> The article is quick to read in it's core and _really_ anyone interested
> in D's development should read it. This pretty much what we have + the
> bits that are currently missing (especially concerning objects in the
> immutable/shared world).
>
> It fits perfectly with what's already there, it's proven to be sound and
> practical, and IMO it's definitely what should be implemented in D.
>

Agreed. Do you file an enhancement request?
November 10, 2012
Re: Immutable and unique in C#
Enhancement request:

http://d.puremagic.com/issues/show_bug.cgi?id=8993
November 10, 2012
Re: Immutable and unique in C#
On Saturday, 10 November 2012 at 12:51:15 UTC, bearophile wrote:
> Sönke Ludwig:
>
>> It fits perfectly with what's already there, it's proven to be 
>> sound and
>> practical, and IMO it's definitely what should be implemented 
>> in D.
>
> Seems fit to be added to Remus then :-)
>
> Bye,
> bearophile

Gladly, if you would help me to write the necessary structures to 
emulate the behaviour. ;)
November 11, 2012
Re: Immutable and unique in C#
Am Sat, 10 Nov 2012 15:41:21 +0100
schrieb Sönke Ludwig <sludwig@outerproduct.org>:

> Enhancement request:
> 
> http://d.puremagic.com/issues/show_bug.cgi?id=8993

Its true that we avoid shared because it isn't finalized and
in its current state more or less a broken feature. It also
highlights the bluntness of the casts again, that are needed
to use it. *sigh* If it takes 5 full-time researchers to come
up with that type system extension then be it. I hope it can be
applied to D and resolves the 'shared' situation.

-- 
Marco
November 11, 2012
[OT] Re: Immutable and unique in C#
On Fri, 09 Nov 2012 14:53:27 +0100
Sönke Ludwig <sludwig@outerproduct.org> wrote:

> Just stumbled over this, which is describing a type system extension
> for C# for race-free parallelism:
> 
> http://research.microsoft.com/pubs/170528/msr-tr-2012-79.pdf
> 

Ugh, "researchers" really need to quit releasing shit in multi-column
PDF. Fucking pain in the ass to read. They need to try researching
what the current decade is, what do they think this is, 1950? Don't they
ever even try to read their *own* shit? Or, heck, even *other*
researcher's papers? Or do they just live and die by their printer? I
really don't get why they keep doing it, makes no damn sense at all.
Some sort of idiotically mandated requirement? And then they wonder why
people dismiss/ignore them as out-of-touch ivory tower. Geez.
November 11, 2012
Re: Immutable and unique in C#
On Fri, 09 Nov 2012 07:53:27 -0600, Sönke Ludwig <sludwig@outerproduct.org> wrote:

> Just stumbled over this, which is describing a type system extension for
> C# for race-free parallelism:
>
> http://research.microsoft.com/pubs/170528/msr-tr-2012-79.pdf
>
> Independent of this article I think D is currently missing out a lot by
> omitting a proper unique type (a _proper_ library solution would be a
> start, but I'm not sure if that can handle all details). It would make a
> lot of the cases work that are currently simply not practical because of
> loads of casts that are necessary.
>

What's wrong with std.typecons.Unique?
By the way, back when concurrency in D was actively being discussed and developed, (IIRC) Walter did try to implement unique as a proper type in D, but ran into several gotchas. In essence, while we all want unique/mobile, for unique/mobile to be non-broken it also needs at least a lent/scope and an owned type. Ownership type systems are a relatively new area of CS and as demonstrated by the paper, still an active area of research. The thorny issue of these systems is that you need to associate variables with types. For example, this.x = that.y; is only valid if x and y are both owned by the same region. This is easy to verify at runtime, but not at compile-time. Anyways, ownership types (or whatever supersedes them) were pushed back to D3 and we were left with message passing for the common user, synchronized for traditional lock-based shared memory and shared for lock-free programming.

P.S. Thanks for the link to the paper.
« First   ‹ Prev
1 2 3 4
Top | Discussion index | About this forum | D home