www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: Spec#, nullables and more

reply bearophile <bearophileHUGS lycos.com> writes:
J. M. Berger: 

 <sarcasm>
 Consider immutable type immutable T:
 
   immutable T] a = new immutable T[4];
   ... time goes by ...
   T[1] = foo;
   T[3] = bar;
 
 In other words I create an array that I mean to fill in later,
 because I don't have meaningful data for it in advance. How do I do
 that with immutable types?
 </sarcasm>

Despite your answer was sarcastic, it's a very interesting note. In a recent post I have explained how Spec# solves this problem with arrays of nonnulls, using NonNullType.AssertInitialized(): http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=121140 What's interesting in your sarcastic note is that you have shown that building a collection of immutables and a collection of nonnulls in some situations share the same basic problem, that is how to build something that has constraints regarding its changes or its not being present yet. Two bug reports about the topic: http://d.puremagic.com/issues/show_bug.cgi?id=5147 http://d.puremagic.com/issues/show_bug.cgi?id=5081 In my opinion currently in D there aren't very good ways to build collections of immutables. The Clojure solves a related problem (it's a performance problem too), using transients: http://clojure.org/transients In practice even the Spec# solution uses a kind of "transient", you use NonNullType.AssertInitialized() to mark inside a function the point where you state an array of nonnulls is done, the transient had ended. Even if syntactically they are very different, on a semantic level they are doing the same thing, they are both ways to tell apart the building phase from the finished phase. Surely there are many different ways to tell the compiler a way to tell apart such two phases. A solution for the creation of immutable collections in D may be used to build collections of nonulls too. They aren't the same problem, but they share enough that the same solution (with little changes) may be used for both. Bye, bearophile
Nov 06 2010
parent Don <nospam nospam.com> writes:
bearophile wrote:
 J. M. Berger: 
 
 <sarcasm>
 Consider immutable type immutable T:

   immutable T] a = new immutable T[4];
   ... time goes by ...
   T[1] = foo;
   T[3] = bar;

 In other words I create an array that I mean to fill in later,
 because I don't have meaningful data for it in advance. How do I do
 that with immutable types?
 </sarcasm>

Despite your answer was sarcastic, it's a very interesting note. In a recent post I have explained how Spec# solves this problem with arrays of nonnulls, using NonNullType.AssertInitialized(): http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=121140 What's interesting in your sarcastic note is that you have shown that building a collection of immutables and a collection of nonnulls in some situations share the same basic problem, that is how to build something that has constraints regarding its changes or its not being present yet. Two bug reports about the topic: http://d.puremagic.com/issues/show_bug.cgi?id=5147 http://d.puremagic.com/issues/show_bug.cgi?id=5081 In my opinion currently in D there aren't very good ways to build collections of immutables. The Clojure solves a related problem (it's a performance problem too), using transients: http://clojure.org/transients In practice even the Spec# solution uses a kind of "transient", you use NonNullType.AssertInitialized() to mark inside a function the point where you state an array of nonnulls is done, the transient had ended. Even if syntactically they are very different, on a semantic level they are doing the same thing, they are both ways to tell apart the building phase from the finished phase. Surely there are many different ways to tell the compiler a way to tell apart such two phases. A solution for the creation of immutable collections in D may be used to build collections of nonulls too. They aren't the same problem, but they share enough that the same solution (with little changes) may be used for both. Bye, bearophile

As was pointed out in a recent post, the return value of a pure function is guaranteed to be unique, so could be allowed to implictly cast to immutable. I'm planning a patch for that soon, to see how well it works in practice. But I don't think that would work for non-nulls. I don't think the two situations have a great deal in common.
Nov 06 2010