Jump to page: 1 24  
Page
Thread overview
Immutable and unique in C#
Nov 09, 2012
Sönke Ludwig
Nov 09, 2012
Kagamin
Nov 10, 2012
Sönke Ludwig
Nov 10, 2012
bearophile
Nov 10, 2012
Namespace
Nov 10, 2012
Timon Gehr
Nov 10, 2012
Sönke Ludwig
Nov 11, 2012
Marco Leise
[OT] Re: Immutable and unique in C#
Nov 11, 2012
Nick Sabalausky
Nov 11, 2012
Robert Jacques
Nov 11, 2012
Sönke Ludwig
Nov 12, 2012
Walter Bright
Nov 12, 2012
Jonathan M Davis
Nov 12, 2012
Sönke Ludwig
Nov 12, 2012
deadalnix
Nov 12, 2012
Walter Bright
Nov 12, 2012
bearophile
Nov 12, 2012
deadalnix
Nov 13, 2012
Walter Bright
Nov 13, 2012
Sönke Ludwig
Nov 13, 2012
Walter Bright
Nov 13, 2012
Sönke Ludwig
Nov 13, 2012
Walter Bright
Nov 13, 2012
Walter Bright
Nov 13, 2012
Sönke Ludwig
Nov 13, 2012
Sönke Ludwig
Nov 14, 2012
Walter Bright
Nov 14, 2012
Timon Gehr
Nov 13, 2012
Sönke Ludwig
Nov 13, 2012
Daniel Murphy
Nov 14, 2012
Walter Bright
Nov 13, 2012
deadalnix
Nov 13, 2012
Jacob Carlborg
November 09, 2012
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
:) do they implement `inout`?
November 10, 2012
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
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
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
Enhancement request:

http://d.puremagic.com/issues/show_bug.cgi?id=8993
November 10, 2012
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
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
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
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