www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Const system names

reply bearophile <bearophileHUGS lycos.com> writes:
Alternative names for the transitive const regime of D2, the main difference is
that now immutable values are the default:

- "immutable" ==> (nothing, it's the default).
- "const" ==> "valview" (a local immutable value view of something).
- mutable variable ==> "var"
- "enum" ==> "const" (or maybe it can be removed, so it becomes immutable, that
is no annotation. The link-time optimization of LDC is able to remove unused
values from the binary. Ten years from now all D compilers can be able to do
this).

This is not compatible with C, but if you try to port C code to D2 with this
const regime, the code can't assign new values to variables that lack the "var"
attribute, it produce compile errors, so such porting doesn't look bug-prone to
me.

So this code:
  immutable int x1 = 1;
  const int x2 = 2;
  int x3 = 3;
  enum int x4 = 4;

Becomes:
  int x1 = 1;
  valview int x2 = 2;
  var int x3 = 3;
  int x4 = 4;

With such immutability by default, thread-local by default, notnull references
by default, the language starts to look quite different from C++ ;-)

Bye,
bearophile
Feb 15 2010
next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
bearophile wrote:

 Alternative names for the transitive const regime of D2, the main difference
is that now immutable values are the default:
 
 - "immutable" ==> (nothing, it's the default).
 - "const" ==> "valview" (a local immutable value view of something).
 - mutable variable ==> "var"
 - "enum" ==> "const" (or maybe it can be removed, so it becomes immutable,
that is no annotation. The link-time optimization of LDC is able to remove
unused values from the binary. Ten years from now all D compilers can be able
to do this).
 
 [...]


I don't agree that immutable should be the the default.  The default 
should be the most common case, which is mutable.

Regarding names; the fact that we currently have to write "enum x = 
123;", which to me reads like "enumerate this single constant for me 
please, and BTW when I say 'enumerate' I really mean that I want to 
assign 123 to it", is one of the last remaining things in D that really 
bugs me.

I have suggested the following scheme at least twice:

     const: manifest constants, no storage (like const in D1, enum in D2)
  readonly: a read-only view of mutable data (like const in D2)
immutable: immutable data (like now)

(Both times Yigal Chiprun was the first to reply, saying he thinks there 
should only be const and non-const, and the rest is up to the compiler. 
  I'd almost be disappointed if that doesn't happen now. :) I still 
disagree, though.)

-Lars
Feb 16 2010
parent reply retard <re tard.com.invalid> writes:
Tue, 16 Feb 2010 10:28:28 +0100, Lars T. Kyllingstad wrote:


 bearophile wrote:

 Alternative names for the transitive const regime of D2, the main
 difference is that now immutable values are the default:
 
 - "immutable" ==> (nothing, it's the default). - "const" ==> "valview"
 (a local immutable value view of something). - mutable variable ==>
 "var"
 - "enum" ==> "const" (or maybe it can be removed, so it becomes
 immutable, that is no annotation. The link-time optimization of LDC is
 able to remove unused values from the binary. Ten years from now all D
 compilers can be able to do this).
 
 [...]


 
 I don't agree that immutable should be the the default.  The default
 should be the most common case, which is mutable.


BTW, have you got some numbers from concrete examples such as real world 
programming projects. Note that many variables are not immutable in real 
projects, but they also could be:

Integer boxedIntegerSum(Integer a, Integer b) {
  Integer c = new Integer();
  c.assign(a.getValue() + b.getValue());
  return c;
}

Here you have three immutable variables a, b, and c. In reality they all 
could as well be constant references, a and b also could be immutable 
views:

Integer boxedIntegerSum(immutable Integer a, immutable Integer b) {
  const Integer c = new Integer();
  c.assign(a.getValue() + b.getValue());
  return c;
}
Feb 16 2010
parent reply =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
On 02/16/2010 04:27 PM, retard wrote:

 Tue, 16 Feb 2010 10:28:28 +0100, Lars T. Kyllingstad wrote:


 bearophile wrote:

 Alternative names for the transitive const regime of D2, the main
 difference is that now immutable values are the default:

 - "immutable" ==>  (nothing, it's the default). - "const" ==>  "valview"
 (a local immutable value view of something). - mutable variable ==>
 "var"
 - "enum" ==>  "const" (or maybe it can be removed, so it becomes
 immutable, that is no annotation. The link-time optimization of LDC is
 able to remove unused values from the binary. Ten years from now all D
 compilers can be able to do this).

 [...]


 I don't agree that immutable should be the the default.  The default
 should be the most common case, which is mutable.


 BTW, have you got some numbers from concrete examples such as real world
 programming projects. Note that many variables are not immutable in real
 projects, but they also could be:

 Integer boxedIntegerSum(Integer a, Integer b) {
    Integer c = new Integer();
    c.assign(a.getValue() + b.getValue());
    return c;
 }

 Here you have three immutable variables a, b, and c. In reality they all
 could as well be constant references, a and b also could be immutable
 views:

 Integer boxedIntegerSum(immutable Integer a, immutable Integer b) {
    const Integer c = new Integer();
    c.assign(a.getValue() + b.getValue());
    return c;
 }


Only if you're assuming that the assign() doesn't alter the integer, but 
in that case it's kind of meaningless. Also, requiring immutability for 
the input is not what you usually want.
Feb 16 2010
parent retard <re tard.com.invalid> writes:
Tue, 16 Feb 2010 17:05:23 +0100, Pelle Månsson wrote:


 On 02/16/2010 04:27 PM, retard wrote:

 Tue, 16 Feb 2010 10:28:28 +0100, Lars T. Kyllingstad wrote:


 bearophile wrote:

 Alternative names for the transitive const regime of D2, the main
 difference is that now immutable values are the default:

 - "immutable" ==>  (nothing, it's the default). - "const" ==> 
 "valview" (a local immutable value view of something). - mutable
 variable ==> "var"
 - "enum" ==>  "const" (or maybe it can be removed, so it becomes
 immutable, that is no annotation. The link-time optimization of LDC
 is able to remove unused values from the binary. Ten years from now
 all D compilers can be able to do this).

 [...]


 I don't agree that immutable should be the the default.  The default
 should be the most common case, which is mutable.


 BTW, have you got some numbers from concrete examples such as real
 world programming projects. Note that many variables are not immutable
 in real projects, but they also could be:

 Integer boxedIntegerSum(Integer a, Integer b) {
    Integer c = new Integer();
    c.assign(a.getValue() + b.getValue()); return c;
 }

 Here you have three immutable variables a, b, and c. In reality they
 all could as well be constant references, a and b also could be
 immutable views:

 Integer boxedIntegerSum(immutable Integer a, immutable Integer b) {
    const Integer c = new Integer();
    c.assign(a.getValue() + b.getValue()); return c;
 }


 Only if you're assuming that the assign() doesn't alter the integer, but
 in that case it's kind of meaningless.



 Also, requiring immutability for
 the input is not what you usually want.


Yea, I don't really remember how the d2 const/immutability system works 
so that's why I said immutable view and not plain immutable. Basically a 
function usually shouldn't have an 'and' in its description so modifying 
the inputs is often not recommended. Anyways in other cases the 
references should be at least const if the objects aren't. This way the 
common noob bug:

class foo {
  int a;
  this(int a) { a = a; }
}

can be avoided.
Feb 16 2010
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Lars T. Kyllingstad:


I don't agree that immutable should be the the default.  The default should be
the most common case, which is mutable.<


Is it true that mutables are the most common? 

Is it true that mutables will be the most common in D programs written few
years from now? You must design a language for tomorrow, not for yesterday.

Typing var " in the code is not that costly. While writing "immutable " often
in the code is a lot of typing.

Scala e Clojure like immutables, they are good for multicores :-)

I've done a small search of the "val" and "var" attributes in Scala language:

val (immutables):
http://www.google.com/codesearch?q=%22val%22+lang%3Ascala
29_300

var (variables):
http://www.google.com/codesearch?q=%22var%22+lang%3Ascala
15_200

It's not a scientific search, but shows that immutables are not that uncommon
in Scala.



      const: manifest constants, no storage (like const in D1, enum in D2)
   readonly: a read-only view of mutable data (like const in D2)
 immutable: immutable data (like now)


"const" and "readonly" are synonims, so I don't like those names, I prefer
names that mean something different (related to their different semantics). (I
agree that "valview" is not nice looking).

Bye,
bearophile
Feb 16 2010
next sibling parent reply retard <re tard.com.invalid> writes:
Tue, 16 Feb 2010 12:34:15 -0500, bearophile wrote:


 Lars T. Kyllingstad:
 

I don't agree that immutable should be the the default.  The default
should be the most common case, which is mutable.<


 
 Is it true that mutables are the most common?
 
 Is it true that mutables will be the most common in D programs written
 few years from now? You must design a language for tomorrow, not for
 yesterday.
 
 Typing var " in the code is not that costly. While writing "immutable "
 often in the code is a lot of typing.
 
 Scala e Clojure like immutables, they are good for multicores :-)
 
 I've done a small search of the "val" and "var" attributes in Scala
 language:
 
 val (immutables):
 http://www.google.com/codesearch?q=%22val%22+lang%3Ascala 29_300
 
 var (variables):
 http://www.google.com/codesearch?q=%22var%22+lang%3Ascala 15_200
 
 It's not a scientific search, but shows that immutables are not that
 uncommon in Scala.


Note that also function parameters are val in scala unlike in java or d. 
From my experiences with various kinds of (functional) languages with 
first class functional features, const values become the common case. 
Why? Because everything can return a value, you don't need uninitialized 
references.
Feb 16 2010
parent retard <re tard.com.invalid> writes:
Tue, 16 Feb 2010 17:45:06 +0000, retard wrote:


 Tue, 16 Feb 2010 12:34:15 -0500, bearophile wrote:
 

 Lars T. Kyllingstad:
 

I don't agree that immutable should be the the default.  The default
should be the most common case, which is mutable.<


 
 Is it true that mutables are the most common?
 
 Is it true that mutables will be the most common in D programs written
 few years from now? You must design a language for tomorrow, not for
 yesterday.
 
 Typing var " in the code is not that costly. While writing "immutable "
 often in the code is a lot of typing.
 
 Scala e Clojure like immutables, they are good for multicores :-)
 
 I've done a small search of the "val" and "var" attributes in Scala
 language:
 
 val (immutables):
 http://www.google.com/codesearch?q=%22val%22+lang%3Ascala 29_300
 
 var (variables):
 http://www.google.com/codesearch?q=%22var%22+lang%3Ascala 15_200
 
 It's not a scientific search, but shows that immutables are not that
 uncommon in Scala.


 
 Note that also function parameters are val in scala unlike in java or d.
 From my experiences with various kinds of (functional) languages with
 first class functional features, const values become the common case.
 Why? Because everything can return a value, you don't need uninitialized
 references.


Some common examples:



"mutable" int a = initial_value;

switch(some_condition) {
  case case_1: a = something; break;
  case case_2: a = something_else; break;
  default: a = default_value;
}

 -- --

val a = some_condition match {
  case case_1 => something
  case case_2 => something_else
  case _      => default_value
}



"mutable" string s = "";

foreach(elem; collection[0..collection.length-1]) {
  s ~= elem ~ ", ";
}

s ~= collection[collection.length-1];

 -- --

val s = collection.head + collection.tail.foldLeft("")(_+", "+_)
Feb 16 2010
prev sibling parent dennis luehring <dl.soluz gmx.net> writes:
I don't agree that immutable should be the the default.  The default should be
the most common case, which is mutable.<


 Is it true that mutables are the most common?


no - but (as we all know very well) most programmers do not pay any 
attention to (i)mutable or const, final and whatever at all

so i would also vote for immutable everywhere possible - the few cases 
where mutables are needed - not based on programmers lazyness - are 
no-counters for me
Feb 16 2010
prev sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
bearophile <bearophileHUGS lycos.com> wrote:


 Alternative names for the transitive const regime of D2, the main  
 difference is that now immutable values are the default:

 - "immutable" ==> (nothing, it's the default).
 - "const" ==> "valview" (a local immutable value view of something).
 - mutable variable ==> "var"
 - "enum" ==> "const" (or maybe it can be removed, so it becomes  
 immutable, that is no annotation. The link-time optimization of LDC is  
 able to remove unused values from the binary. Ten years from now all D  
 compilers can be able to do this).


I like the idea, and would like to try D with a system like this.
However, I disagree with the names. See, with my beautiful collection
of bike shed colors, I would keep 'const' for 'const' (for backward-
compatibility and familiarity, and I think valview is an abomination),
and use 'alias' instead of 'enum' (which I still consider the most
glaring error in the history of D).

For transition purposes, 'immutable' could of course be a no-op.

-- 
Simen
Feb 16 2010