www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Overloaded terms

reply Derek Parnell <derek psych.ward> writes:
This is just a general gripe, so you can dismiss it if you want.

Is it just me, or are the terms 'static' and 'dynamic' a bit too overloaded
in meaning.

'static' = compile-time processing
         = fixed-length arrays
         = never changing

'dynamic' = run-time processing
          = variable-length arrays
          = constantly changing

So when people use these words I can get confused about which meaning they
are using ;-)

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
10/08/2005 4:50:10 PM
Aug 09 2005
next sibling parent "ElfQT" <dethjunk yahoo.com> writes:
It's also confusing, that in context of Arrays, static means not dynamic
(declared fixed length),
and not static declaration like
# static int[] A1;

example:
#int[] A1 = [ 1, 2, 3, 4, 5 ];
#int[5] A2 = [ 1, 2, 3, 4, 5 ];
#
#int main(char[][] args)
#{
#    printf("sizeof staticA: [%d]\n", A1.sizeof);
#    printf("sizeof staticA: [%d]\n", A2.sizeof);
#    return 0;
#}

It's even more confusing, that .sizeof behaves differently on static and
dynamic Array.

#int[] A1 = [ 1, 2, 3, 4, 5 ];
#int[5] A2 = [ 1, 2, 3, 4, 5 ];
#
#int main(char[][] args)
#{
#    Foo1(A1);
#    Foo1(A2);
#
#    //Foo2(A1); //invalid
#    Foo2(A2);
#
#    return 0;
#}
#
#void Foo1(int[] Ax)
#{
#    printf("Foo1 sizeof: [%d]\n", Ax.sizeof);
#}
#
#void Foo2(int[5] Ax)
#{
#    printf("Foo2 sizeof: [%d]\n", Ax.sizeof);
#}

How to call Foo2 with A1: how to cast/make static array/slice of a dynamic
array?

ElfQT

"Derek Parnell" <derek psych.ward> wrote in message
news:6a4t1k8vh42r.1733y4ilwn4m5$.dlg 40tude.net...
 This is just a general gripe, so you can dismiss it if you want.

 Is it just me, or are the terms 'static' and 'dynamic' a bit too

 in meaning.

 'static' = compile-time processing
          = fixed-length arrays
          = never changing

 'dynamic' = run-time processing
           = variable-length arrays
           = constantly changing

 So when people use these words I can get confused about which meaning they
 are using ;-)

 -- 
 Derek
 (skype: derek.j.parnell)
 Melbourne, Australia
 10/08/2005 4:50:10 PM

Aug 10 2005
prev sibling next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:6a4t1k8vh42r.1733y4ilwn4m5$.dlg 40tude.net...
 This is just a general gripe, so you can dismiss it if you want.

 Is it just me, or are the terms 'static' and 'dynamic' a bit too 
 overloaded
 in meaning.

 'static' = compile-time processing
         = fixed-length arrays
         = never changing

 'dynamic' = run-time processing
          = variable-length arrays
          = constantly changing

 So when people use these words I can get confused about which meaning they
 are using ;-)

 -- 
 Derek
 (skype: derek.j.parnell)
 Melbourne, Australia
 10/08/2005 4:50:10 PM

I agree about the static/dynamic array confusion. I remembe a recent thread with some suggestions and I hope Walter can find it and considers them. I can't find the thread now but I remember thinking some of the suggestions sounded better than today's vocabulary. Here's a suggestion for him: "dynamic array" becomes "resizable array" and "static array" becomes "nonresizable array".
Aug 10 2005
parent reply AJG <AJG_member pathlink.com> writes:
Hi,

"Derek Parnell" <derek psych.ward> wrote in message 
news:6a4t1k8vh42r.1733y4ilwn4m5$.dlg 40tude.net...
 This is just a general gripe, so you can dismiss it if you want.

 Is it just me, or are the terms 'static' and 'dynamic' a bit too 
 overloaded
 in meaning.

 'static' = compile-time processing
         = fixed-length arrays
         = never changing

 'dynamic' = run-time processing
          = variable-length arrays
          = constantly changing

 So when people use these words I can get confused about which meaning they
 are using ;-)

 -- 
 Derek
 (skype: derek.j.parnell)
 Melbourne, Australia
 10/08/2005 4:50:10 PM

I agree about the static/dynamic array confusion. I remembe a recent thread with some suggestions and I hope Walter can find it and considers them. I can't find the thread now but I remember thinking some of the suggestions sounded better than today's vocabulary. Here's a suggestion for him: "dynamic array" becomes "resizable array" and "static array" becomes "nonresizable array".

ICK nonresizable. How about "fixed" instead? Also, I agree with the gist of this thread. The terms are badly overloaded. "const" is also related because like "static" it can mean compile-time (a storage-class) or "never-changing" (though in D that's not yet available). I say change "const" to mean neverchanging (which is the very definition of constant), and use some other word for the storage class. Hey, now that I think about it, you could use "fixed" for this too. fixed int CompileTimeValue = 5; const int RunTimeValue = rand(); // Error: fixed expression needed: fixed int RunTimeValue = rand(); CompileTimeValue = 42; // Error: fixed expr. RunTimeValue = 42; // Error: const expr. fixed int[3] CompileTimeArray = [1, 2, 3]; const int[3] RunTimeArray = [rand(), rand(), rand()]; // Error: fixed expression needed: fixed int[3] RunTimeArray = [rand(), rand(), rand()]; CompileTimeArray[0] = 42; // Error: fixed expr. RunTimeArray [0] = 42; // Error: const expr. This way, static can then be made to mean exclusively "shared" in the sense "all instances share it," or "all function calls share it." Comments? ================ Or, it the opposite could be done: fixed as neverchanging and const remains the storage class. But I prefer it the other way. It's more intuitive. Yes, I'm aware it breaks with C. Then again, D is not C. Cheers, --AJG.
Aug 10 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"AJG" <AJG_member pathlink.com> wrote in message 
news:ddd7cq$6of$1 digitaldaemon.com...
 Hi,

"Derek Parnell" <derek psych.ward> wrote in message
news:6a4t1k8vh42r.1733y4ilwn4m5$.dlg 40tude.net...
 This is just a general gripe, so you can dismiss it if you want.

 Is it just me, or are the terms 'static' and 'dynamic' a bit too
 overloaded
 in meaning.

 'static' = compile-time processing
         = fixed-length arrays
         = never changing

 'dynamic' = run-time processing
          = variable-length arrays
          = constantly changing

 So when people use these words I can get confused about which meaning 
 they
 are using ;-)

 -- 
 Derek
 (skype: derek.j.parnell)
 Melbourne, Australia
 10/08/2005 4:50:10 PM

I agree about the static/dynamic array confusion. I remembe a recent thread with some suggestions and I hope Walter can find it and considers them. I can't find the thread now but I remember thinking some of the suggestions sounded better than today's vocabulary. Here's a suggestion for him: "dynamic array" becomes "resizable array" and "static array" becomes "nonresizable array".

ICK nonresizable. How about "fixed" instead?

To me "fixed" doesn't say what is fixed. Plus one can interpret "fixed" in different ways: fixed as in "not broken" or also fixed as in "neutered" (shudder). Since static arrays are less common in practice than dynamic arrays the unmodified word (resizable) will be used more often than the modified word (nonresizable).
 Also, I agree with the gist of this thread. The terms are badly 
 overloaded.
 "const" is also related because like "static" it can mean compile-time (a
 storage-class) or "never-changing" (though in D that's not yet available).

 I say change "const" to mean neverchanging (which is the very definition 
 of
 constant), and use some other word for the storage class. Hey, now that I 
 think
 about it, you could use "fixed" for this too.

 fixed int CompileTimeValue = 5;
 const int RunTimeValue     = rand();
 // Error: fixed expression needed:
 fixed int RunTimeValue     = rand();

 CompileTimeValue = 42; // Error: fixed expr.
 RunTimeValue     = 42; // Error: const expr.

 fixed int[3] CompileTimeArray = [1, 2, 3];
 const int[3] RunTimeArray     = [rand(), rand(), rand()];
 // Error: fixed expression needed:
 fixed int[3] RunTimeArray     = [rand(), rand(), rand()];

 CompileTimeArray[0] = 42; // Error: fixed expr.
 RunTimeArray    [0] = 42; // Error: const expr.

 This way, static can then be made to mean exclusively "shared" in the 
 sense "all
 instances share it," or "all function calls share it."

 Comments?

ICK :-)
 ================

 Or, it the opposite could be done: fixed as neverchanging and const 
 remains the
 storage class. But I prefer it the other way. It's more intuitive. Yes, 
 I'm
 aware it breaks with C. Then again, D is not C.

 Cheers,
 --AJG.

 

Aug 10 2005
next sibling parent reply Vathix <chris dprogramming.com> writes:
 ICK   nonresizable. How about "fixed" instead?

To me "fixed" doesn't say what is fixed. Plus one can interpret "fixed" in different ways: fixed as in "not broken" or also fixed as in "neutered" (shudder). Since static arrays are less common in practice than dynamic arrays the unmodified word (resizable) will be used more often than the modified word (nonresizable).

"Fixed-length" sounds good. Instead of "dynamic array" or "resizable array" we could just say slice. A slice is a reference to array elements.
Aug 10 2005
parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"Vathix" <chris dprogramming.com> wrote in message 
news:op.svaw5xmgl2lsvj esi...
 ICK   nonresizable. How about "fixed" instead?

To me "fixed" doesn't say what is fixed. Plus one can interpret "fixed" in different ways: fixed as in "not broken" or also fixed as in "neutered" (shudder). Since static arrays are less common in practice than dynamic arrays the unmodified word (resizable) will be used more often than the modified word (nonresizable).

"Fixed-length" sounds good.

We could pronounce "fixed-length array" as "fillay" (fillet). Thinking along those lines a dynamic array reference can be called a "lointer" (length and pointer). For example "I'm passing an array lointer to function foo". :-)
 Instead of "dynamic array" or "resizable array" we could just say slice. A 
 slice is a reference to array elements.

My only complaint with slice is that it tends to imply the existence of a reference array that this is the slice of. It would be like saying we don't need the word "set" once we have the word "subset".
Aug 10 2005
prev sibling parent reply AJG <AJG_member pathlink.com> writes:
Hi,

 ICK   nonresizable. How about "fixed" instead?

To me "fixed" doesn't say what is fixed. Plus one can interpret "fixed" in different ways: fixed as in "not broken" or also fixed as in "neutered" (shudder).

Oh, c'mon! By that same token, one can interpret "constant" to mean "faithful"! Look it up, I speak truths. Realistically though, fixed would come from "fixed-length," so it would be merely an abbreviation. In addition, it would be consistent with the docs, if the docs dropped the confusing "static" already.
Since static arrays are less common in practice than dynamic 
arrays the unmodified word (resizable) will be used more often than the 
modified word (nonresizable).

The only way I see to avoid the ugly nonresizable is to make it implicit and then require resizable for everything else. But then you say resizable is more common, so that wouldn't fly.
 Comments?

ICK :-)

Touché! ;) But how about the concept itself: That there are, and that we should have at our disposal, two distincts things: 1) A compile time, constant-foldable, declaration. 2) A run-time, dynamically set (once), neverchanging, readonly declaration. If you agree, then it's just a matter of keywords then ;) I have an aversion to nonresizable, you to fixed. The solution is obvious and self-evident: fixedlynonresizable int[] array; ;) Cheers, --AJG.
Aug 10 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
 But how about the concept itself: That there are, and that we should have 
 at our
 disposal, two distincts things:

 1) A compile time, constant-foldable, declaration.
 2) A run-time, dynamically set (once), neverchanging, readonly 
 declaration.

IMHO the current syntax is fine.
Aug 10 2005
parent reply AJG <AJG_member pathlink.com> writes:
Hi,

In article <dddmrp$rvf$1 digitaldaemon.com>, Ben Hinkle says...
 But how about the concept itself: That there are, and that we should have 
 at our
 disposal, two distincts things:

 1) A compile time, constant-foldable, declaration.
 2) A run-time, dynamically set (once), neverchanging, readonly 
 declaration.


Fine, as in... not broken? Yes, then it's more or less fine. Doesn't it leave room for improvement, though? For instance, the second case I talked about is not supported. Why? Say I want to create a _constant_ value, it will not change throughout its life, but I want to set this value at runtime. Does the current syntax support that? No. In C# there's a similar "readonly" keyword, but it's not exactly what I mean. Would you be opposed to something like the following? (If yes, then what's the alternative)? # const int foo = rand(); # foo = 5; // error. Make no mistake, foo is a _constant_ by all definitions, except it's not a compile time one. So, my gut tells me overloading const (the current syntax) yet again is not the best idea ;), which is why I proposed "fixed." Cheers, --AJG.
Aug 10 2005
next sibling parent reply xs0 <xs0 xs0.com> writes:
AJG wrote:

 Make no mistake, foo is a _constant_ by all definitions, except it's not a
 compile time one. So, my gut tells me overloading const (the current syntax)
yet
 again is not the best idea ;), which is why I proposed "fixed."

final might also not be a bad idea, especially because it's already a keyword and works in exactly the way you describe in Java. OTOH, DMD 0.129 allows this: import std.stdio; class Foo { const int bar; public this() { bar=5; } } void main() { Foo foo=new Foo(); writefln(foo.bar); } Looking at DMD source changes, it would seem that initializing constants in constructors has silently been allowed :) xs0
Aug 10 2005
parent reply =?ISO-8859-1?Q?Thomas_K=FChne?= <thomas-dloop kuehne.THISISSPAM.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

xs0 schrieb:
 AJG wrote:
 
 Make no mistake, foo is a _constant_ by all definitions, except it's
 not a
 compile time one. So, my gut tells me overloading const (the current
 syntax) yet
 again is not the best idea ;), which is why I proposed "fixed."

final might also not be a bad idea, especially because it's already a keyword and works in exactly the way you describe in Java. OTOH, DMD 0.129 allows this: import std.stdio; class Foo { const int bar; public this() { bar=5; } } void main() { Foo foo=new Foo(); writefln(foo.bar); } Looking at DMD source changes, it would seem that initializing constants in constructors has silently been allowed :)

# The const attribute declares constants that can be evaluated at # compile time. # A const declaration without an initializer must be initialized in a # constructor (for class fields) or in a static constructor (for static # class members, or module variable declarations). Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFC+zPI3w+/yD4P9tIRAiS8AJ95WjnYXiKgZbyMirISA3xkZTJmygCgj4TF ch8p773qKO+80HTDOWEoMfc= =YP1h -----END PGP SIGNATURE-----
Aug 11 2005
parent reply xs0 <xs0 xs0.com> writes:
Thomas Kühne wrote:
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 xs0 schrieb:
 
AJG wrote:


Make no mistake, foo is a _constant_ by all definitions, except it's
not a
compile time one. So, my gut tells me overloading const (the current
syntax) yet
again is not the best idea ;), which is why I proposed "fixed."

final might also not be a bad idea, especially because it's already a keyword and works in exactly the way you describe in Java. OTOH, DMD 0.129 allows this: import std.stdio; class Foo { const int bar; public this() { bar=5; } } void main() { Foo foo=new Foo(); writefln(foo.bar); } Looking at DMD source changes, it would seem that initializing constants in constructors has silently been allowed :)

# The const attribute declares constants that can be evaluated at # compile time. # A const declaration without an initializer must be initialized in a # constructor (for class fields) or in a static constructor (for static # class members, or module variable declarations).

I saw that too, but this also works: import std.stdio; int counter=0; int qwe() { return counter++; } class Foo { const int bar; public this() { bar=qwe(); } } void main() { for (int a=0; a<10; a++) { Foo foo=new Foo(); writefln(foo.bar); } } So I guess it's no longer compile-time only? xs0
Aug 11 2005
next sibling parent AJG <AJG_member pathlink.com> writes:
Hi,

So I guess it's no longer compile-time only?

Is this true, or is the behaviour shown a weird parsing bug? Walter? Cheers, --AJG.
Aug 11 2005
prev sibling parent =?ISO-8859-1?Q?Thomas_K=FChne?= <thomas-dloop kuehne.THISISSPAM.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

xs0 schrieb:

 Thomas Kühne wrote:
 
 # The const attribute declares constants that can be evaluated at
 # compile time.

 # A const declaration without an initializer must be initialized in a
 # constructor (for class fields) or in a static constructor (for static
 # class members, or module variable declarations).

I saw that too, but this also works: import std.stdio; int counter=0; int qwe() { return counter++; } class Foo { const int bar; public this() { bar=qwe(); } } void main() { for (int a=0; a<10; a++) { Foo foo=new Foo(); writefln(foo.bar); } } So I guess it's no longer compile-time only?

Added to DStress as http://dstress.kuehne.cn/undefined/const_24.d Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFC/MD43w+/yD4P9tIRAovMAJ9yPWRMvZ+ngmiJD2Jczk8Z6quq9QCZAfOk ZwET+Uh9vntg6nhlbGKNsTw= =0b0P -----END PGP SIGNATURE-----
Aug 12 2005
prev sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"AJG" <AJG_member pathlink.com> wrote in message 
news:dddpdh$v7r$1 digitaldaemon.com...
 Hi,

 In article <dddmrp$rvf$1 digitaldaemon.com>, Ben Hinkle says...
 But how about the concept itself: That there are, and that we should 
 have
 at our
 disposal, two distincts things:

 1) A compile time, constant-foldable, declaration.
 2) A run-time, dynamically set (once), neverchanging, readonly
 declaration.


Fine, as in... not broken? Yes, then it's more or less fine. Doesn't it leave room for improvement, though? For instance, the second case I talked about is not supported. Why?

Did you miss the lengthy 'const'/'readonly'/'final' threads from a few weeks/months ago? It's a popular topic (if I understand you correctly). You might want to start a new thread about your proposal in order to keep it distinct from this one about how to document and talk about dynamic and static arrays.
 Say I want to create a _constant_ value, it will not change throughout its 
 life,
 but I want to set this value at runtime. Does the current syntax support 
 that?
 No.

 In C# there's a similar "readonly" keyword, but it's not exactly what I 
 mean.

 Would you be opposed to something like the following?
 (If yes, then what's the alternative)?

 # const int foo = rand();
 # foo = 5; // error.

 Make no mistake, foo is a _constant_ by all definitions, except it's not a
 compile time one. So, my gut tells me overloading const (the current 
 syntax) yet
 again is not the best idea ;), which is why I proposed "fixed."

 Cheers,
 --AJG.

 

Aug 10 2005
parent reply AJG <AJG_member pathlink.com> writes:
Hi,

 For instance, the second case I talked about is not supported. Why?

Did you miss the lengthy 'const'/'readonly'/'final' threads from a few weeks/months ago? It's a popular topic (if I understand you correctly).

Hm... perhaps I misunderstood you. If I may ask so, when you said "the syntax is fine," which parts were you referring to? This could clarify things.
You 
might want to start a new thread about your proposal in order to keep it 
distinct from this one about how to document and talk about dynamic and 
static arrays.

Ah, the problem is this thread is not exclusively about static and dynamic arrays. It's about the terms static and dynamic in general. I think constants are very much related, and I think complete solution would take into account both static and const at once. IMHO the problem stems from trying to remain pseudo-compatible with C, and from trying to save keywords by mixing storage classes with type attributes. Cheers, --AJG.
Aug 10 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"AJG" <AJG_member pathlink.com> wrote in message 
news:dddvke$18fr$1 digitaldaemon.com...
 Hi,

 For instance, the second case I talked about is not supported. Why?

Did you miss the lengthy 'const'/'readonly'/'final' threads from a few weeks/months ago? It's a popular topic (if I understand you correctly).

Hm... perhaps I misunderstood you. If I may ask so, when you said "the syntax is fine," which parts were you referring to? This could clarify things.

The array declaration syntax is fine. I don't think we need to do anything to static arrays (eg int[5]) or dynamic arrays (eg int[]). There are lots of related concepts like readonly, const, final etc but those are different (and much larger) topics.
You
might want to start a new thread about your proposal in order to keep it
distinct from this one about how to document and talk about dynamic and
static arrays.

Ah, the problem is this thread is not exclusively about static and dynamic arrays. It's about the terms static and dynamic in general. I think constants are very much related, and I think complete solution would take into account both static and const at once.

True the OP mentioned arrays as one of the uses. But I had the impression the issue was more with using the words in conversation and documentation and less with code. I think the use of "static" in D code is pretty intuitive and standard. The word "dynamic" doesn't appear in code anywhere so that isn't an issue.
 IMHO the problem stems from trying to remain pseudo-compatible with C, and 
 from
 trying to save keywords by mixing storage classes with type attributes.

Actually "static" in C is overloaded when used for toplevel symbols to mean what D uses "private" for. So I'd say that D breaks from C for exactly the reason you mention.
Aug 11 2005
next sibling parent reply AJG <AJG_member pathlink.com> writes:
Hi,

The array declaration syntax is fine. I don't think we need to do anything 
to static arrays (eg int[5]) or dynamic arrays (eg int[]). There are lots of 
related concepts like readonly, const, final etc but those are different 
(and much larger) topics.

Ok, so you say nothing needs to be done about static arrays? I beg to differ. I think the current terminology and keywords are confusing and should be revised. As it stands, what's the difference between, and how to you describe the following: # void Foo() { # static int[] A; # static int[5] B; # int[] D # int[5] C; # } It would make more sense to me to call: 'A' a shared, dynamic array. 'B' a shared, static array. 'C' a local, dynamic array. 'D' a local, static array. As it stands, 'B' is a 'static, static' array, right? Doesn't that merit change?
 Ah, the problem is this thread is not exclusively about static and dynamic
 arrays. It's about the terms static and dynamic in general. I think 
 constants
 are very much related, and I think complete solution would take into 
 account
 both static and const at once.

True the OP mentioned arrays as one of the uses. But I had the impression the issue was more with using the words in conversation and documentation and less with code. I think the use of "static" in D code is pretty intuitive and standard. The word "dynamic" doesn't appear in code anywhere so that isn't an issue.

I'd say you are right about dynamic. It's not in code and it's fairly well understood. So I agree it's not much of an issue. But I disagree about static. I don't like how the two meanings of static (shared and compile-time) are merged into one. Particularly when the two can collide in one object. Why not disambiguate and introduce 'shared'?
 IMHO the problem stems from trying to remain pseudo-compatible with C, and 
 from
 trying to save keywords by mixing storage classes with type attributes.

Actually "static" in C is overloaded when used for toplevel symbols to mean what D uses "private" for. So I'd say that D breaks from C for exactly the reason you mention.

So what do the following mean, then? # static private void main() {} # static void main() {} # private void main() {} # void main() {} Is there a difference? Cheers, --AJG.
Aug 11 2005
next sibling parent reply Shammah Chancellor <Shammah_member pathlink.com> writes:
In article <ddg4qi$o6l$1 digitaldaemon.com>, AJG says...
Hi,

The array declaration syntax is fine. I don't think we need to do anything 
to static arrays (eg int[5]) or dynamic arrays (eg int[]). There are lots of 
related concepts like readonly, const, final etc but those are different 
(and much larger) topics.

Ok, so you say nothing needs to be done about static arrays? I beg to differ. I think the current terminology and keywords are confusing and should be revised. As it stands, what's the difference between, and how to you describe the following: # void Foo() { # static int[] A; # static int[5] B; # int[] D # int[5] C; # } It would make more sense to me to call: 'A' a shared, dynamic array. 'B' a shared, static array. 'C' a local, dynamic array. 'D' a local, static array. As it stands, 'B' is a 'static, static' array, right? Doesn't that merit change?
 Ah, the problem is this thread is not exclusively about static and dynamic
 arrays. It's about the terms static and dynamic in general. I think 
 constants
 are very much related, and I think complete solution would take into 
 account
 both static and const at once.

True the OP mentioned arrays as one of the uses. But I had the impression the issue was more with using the words in conversation and documentation and less with code. I think the use of "static" in D code is pretty intuitive and standard. The word "dynamic" doesn't appear in code anywhere so that isn't an issue.

I'd say you are right about dynamic. It's not in code and it's fairly well understood. So I agree it's not much of an issue. But I disagree about static. I don't like how the two meanings of static (shared and compile-time) are merged into one. Particularly when the two can collide in one object. Why not disambiguate and introduce 'shared'?
 IMHO the problem stems from trying to remain pseudo-compatible with C, and 
 from
 trying to save keywords by mixing storage classes with type attributes.

Actually "static" in C is overloaded when used for toplevel symbols to mean what D uses "private" for. So I'd say that D breaks from C for exactly the reason you mention.

So what do the following mean, then? # static private void main() {} # static void main() {} # private void main() {} # void main() {} Is there a difference? Cheers, --AJG.

I fully agree with you AJG, static where it means compile-time should stay the same. static where it means shared should change to shared, like in java, and C#. static int[5] foo; would become: shared int[5] foo; static assert(is(foo == int[5])) would stay the same.
Aug 11 2005
next sibling parent AJG <AJG_member pathlink.com> writes:
Hi,

I fully agree with you AJG,

Yay! (Don't let them know I paid you ;)
static where it means compile-time should stay the same.  static where it means
shared should change to shared, like in java, and C#.

static int[5] foo; would become:

shared int[5] foo;

static assert(is(foo == int[5])) would stay the same.

Yep, that's exactly right. That'd be ideal. Cheers, --AJG.
Aug 11 2005
prev sibling parent Stefan Zobel <Stefan_member pathlink.com> writes:
In article <ddg5h4$oqi$1 digitaldaemon.com>, Shammah Chancellor says...
I fully agree with you AJG,

static where it means compile-time should stay the same.  static where it means
shared should change to shared, like in java, and C#.

Uhm, no - not like in Java and C#. It's static there too. Another reason to stick with "static" IMO. You perhaps meant VB.NET ... Best regards, Stefan
Aug 11 2005
prev sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"AJG" <AJG_member pathlink.com> wrote in message 
news:ddg4qi$o6l$1 digitaldaemon.com...
 Hi,

The array declaration syntax is fine. I don't think we need to do anything
to static arrays (eg int[5]) or dynamic arrays (eg int[]). There are lots 
of
related concepts like readonly, const, final etc but those are different
(and much larger) topics.

Ok, so you say nothing needs to be done about static arrays? I beg to differ. I think the current terminology and keywords are confusing and should be revised. As it stands, what's the difference between, and how to you describe the following: # void Foo() { # static int[] A; # static int[5] B; # int[] D # int[5] C; # } It would make more sense to me to call: 'A' a shared, dynamic array. 'B' a shared, static array. 'C' a local, dynamic array. 'D' a local, static array. As it stands, 'B' is a 'static, static' array, right? Doesn't that merit change?

I agree the concept we currently call a "static array" should be renamed. That's been the position of all the replies to this thread, from what I can tell. The part I disagree with you about is that the use of 'static' in the code to mean "static variable" needs to change. I think it's fine.
 Ah, the problem is this thread is not exclusively about static and 
 dynamic
 arrays. It's about the terms static and dynamic in general. I think
 constants
 are very much related, and I think complete solution would take into
 account
 both static and const at once.

True the OP mentioned arrays as one of the uses. But I had the impression the issue was more with using the words in conversation and documentation and less with code. I think the use of "static" in D code is pretty intuitive and standard. The word "dynamic" doesn't appear in code anywhere so that isn't an issue.

I'd say you are right about dynamic. It's not in code and it's fairly well understood. So I agree it's not much of an issue. But I disagree about static. I don't like how the two meanings of static (shared and compile-time) are merged into one. Particularly when the two can collide in one object. Why not disambiguate and introduce 'shared'?

Assuming the name "static array" is changed where does "static" mean "compile time"? Do you mean something like performing "static analysis" of a program? I think the meanings of static as it appears in code is pretty consitent and matches what one would expect from C/Java/C++ etc. I don't think introducing a new keyword is worth it.
 IMHO the problem stems from trying to remain pseudo-compatible with C, 
 and
 from
 trying to save keywords by mixing storage classes with type attributes.

Actually "static" in C is overloaded when used for toplevel symbols to mean what D uses "private" for. So I'd say that D breaks from C for exactly the reason you mention.

So what do the following mean, then? # static private void main() {} # static void main() {} # private void main() {} # void main() {} Is there a difference?

If you read the doc it explains how static behaves http://www.digitalmars.com/d/attribute.html (read the "Static Attribute" section). In your case above it says the "static" is ignored (assuming main() is a top-level function). The private or lack of private has the usual meaning (read the "Protection Attribute" section of that same page).
 Cheers,
 --AJG.

 

Aug 11 2005
parent reply AJG <AJG_member pathlink.com> writes:
Hi,

I agree the concept we currently call a "static array" should be renamed. 
That's been the position of all the replies to this thread, from what I can 
tell. The part I disagree with you about is that the use of 'static' in the 
code to mean "static variable" needs to change. I think it's fine.

A "static variable" makes no sense. Think about it. It's the same as a "constant variable". It's an oxymoron. What you mean to say is a "shared variable." It applies a little differently to arrays. A "static array" (e.g. int[5] A) is closer to the "compile-time" meaning of static. It means the array itself has been evaluated at compile time. Therefore the array itself can not change at runtime. int[5] a = new int[5]; // IIRC, error. So in other words, a static array is the opposite of a dynamic array. Dynamic we established to mean variable at runtime. Therefore, logically a static array is not variable at runtime, which effectively means compile-time. So a "static array," while not exactly a marvelous term, is much better than a "static variable," which is a total contradiction. If you want to fix "static arrays" as well, then you need (surprise!) yet another keyword. You suggested 'nonresizable', I suggested 'fixed'. Either one would be an improvement. # /* dynamic length */ int[] Dynamic = new int[5]; # fixed /* length */ int[5] Fixed;
 I don't like how the two meanings of static (shared and compile-time) are 
 merged
 into one. Particularly when the two can collide in one object. Why not
 disambiguate and introduce 'shared'?

Assuming the name "static array" is changed where does "static" mean "compile time"? Do you mean something like performing "static analysis" of a program?

Well, a static assert fails at compile-time... doesn't it? The strongest meaning of static is compile-time. Static analysis, static if, static assert, etc... So, a "static function," and a "static variable" aren't good terms.
I think the meanings of static as it appears in code is pretty 
consitent

# static assert/if: compile-time. # static function/var/class: shared at runtime. That's not consistent at all.
matches what one would expect from C/Java/C++ etc.

One would expect C top-level 'static' to remain so, not 'private'. That doesn't match. So then you could argue "well, it _mostly_ matches," but then that's arbitrary and means little. D already broke with C on static. Let's take it all the way and improve it once and for all.
I don't think introducing a new keyword is worth it.

Again with the keyword stinginess. What if instead of keywords they were made special attributes? # [shared] int Foo() { # [shared] int counter = 0; # string shared = "shared"; # return (counter++); # }
 So what do the following mean, then?
 # static private void main() {}
 # static  void main() {}
 # private void main() {}
 # void main() {}

 Is there a difference?

If you read the doc it explains how static behaves http://www.digitalmars.com/d/attribute.html (read the "Static Attribute" section). In your case above it says the "static" is ignored (assuming main() is a top-level function). The private or lack of private has the usual meaning (read the "Protection Attribute" section of that same page).

Ah, I see. Yet another reason to at least issue a warning when attributes are ignored nonchalantly. Oh well... Thanks, --AJG.
Aug 11 2005
parent xs0 <xs0 xs0.com> writes:
Hi,

 A "static variable" makes no sense. Think about it. It's the same as a
"constant
 variable". It's an oxymoron. What you mean to say is a "shared variable."

Sorry to barge in, but I beg to differ. From a dictionary: static -- having no motion, fixed, stationary, etc. A static variable is just that - its memory location is fixed at compile time, so imho a "static variable" uses the word static in the best way :)
 It applies a little differently to arrays. A "static array" (e.g. int[5] A) is
 closer to the "compile-time" meaning of static. It means the array itself has
 been evaluated at compile time. Therefore the array itself can not change at
 runtime.

Well, in the case of arrays the static/dynamic refers to both length and memory location, although not in quite the same sense wrt the location as above (it's on the stack vs. heap). I'm fine with static arrays, too..
 If you want to fix "static arrays" as well, then you need (surprise!) yet
 another keyword. You suggested 'nonresizable', I suggested 'fixed'. Either one
 would be an improvement.
 
 # /* dynamic length */ int[]  Dynamic = new int[5];
 #   fixed /* length */ int[5] Fixed;

Why exactly would you require 'fixed' there? It's static/fixed even without it?
 # static assert/if: compile-time.
 # static function/var/class: shared at runtime.
 
 That's not consistent at all.

It is consistent, at least a bit - in all cases, the outcome doesn't depend on runtime: static assert's success doesn't depend on runtime (and in the case it always failed, the program would be quite useless, so the compiler refuses to even compile it) static if's outcome also doesn't depend on runtime, so the compiler can choose one version or another already at compile time.. static variables' location is fixed at compile time static arrays' length is fixed at compile time static functions don't depend on runtime instances of a class static classes don't (automatically) depend on runtime instances of their outer classes
matches what one would expect from C/Java/C++ etc.

One would expect C top-level 'static' to remain so, not 'private'. That doesn't match. So then you could argue "well, it _mostly_ matches," but then that's arbitrary and means little. D already broke with C on static. Let's take it all the way and improve it once and for all.

Well, in Java the meaning of static vars, funcs and classes is exactly the same as in D, which I think is a plus and I definitely wouldn't like to see it changed.. xs0
Aug 11 2005
prev sibling next sibling parent Stefan Zobel <Stefan_member pathlink.com> writes:
In article <ddfl3d$53b$1 digitaldaemon.com>, Ben Hinkle says...
The array declaration syntax is fine. I don't think we need to do anything 
to static arrays (eg int[5]) or dynamic arrays (eg int[]). There are lots of 
related concepts like readonly, const, final etc but those are different 
(and much larger) topics.

 ....
True the OP mentioned arrays as one of the uses. But I had the impression 
the issue was more with using the words in conversation and documentation 
and less with code. I think the use of "static" in D code is pretty 
intuitive and standard. The word "dynamic" doesn't appear in code anywhere 
so that isn't an issue.

I fully agree with Ben here. We (and the doc) should change our wording since "static" is way too overloaded for informal communication, but I know what it means when I see it in code (and the same holds for programmers that come from Java or C#). Just my 2c, Stefan
Aug 11 2005
prev sibling parent Derek Parnell <derek psych.ward> writes:
On Thu, 11 Aug 2005 09:50:36 -0400, Ben Hinkle wrote:


[snip]

 
 True the OP mentioned arrays as one of the uses. But I had the impression 
 the issue was more with using the words in conversation and documentation 
 and less with code.

Yes. I was only referring to the ambiguous usage of these words in conversations. I was not advocating change in D or even advocating that D should not be changed. I was not talking about the D syntax at all. -- Derek Parnell Melbourne, Australia 12/08/2005 8:13:51 AM
Aug 11 2005
prev sibling next sibling parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:6a4t1k8vh42r.1733y4ilwn4m5$.dlg 40tude.net...
 This is just a general gripe, so you can dismiss it if you want.

 Is it just me, or are the terms 'static' and 'dynamic' a bit too 
 overloaded
 in meaning.

I added a section on the Array doc wiki for names. Feel free to add more suggestions. http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Arrays#Namesstaticanddynamicconfusing
Aug 10 2005
prev sibling parent AJG <AJG_member pathlink.com> writes:
Hi,

This is just a general gripe, so you can dismiss it if you want.
Is it just me, or are the terms 'static' and 'dynamic' a bit too overloaded
in meaning.

As I said in another branch, I agree very much with this sentiment. My suggestion, meant to alleviate the burden a little, is the following: What about replacing the class/function/var part of static with "shared"? I think it cleanly conveys what is meant, which is that all instances/functions share the same data. Then static could be made to mean stricly "compile-time," as in static assert. So you would have: shared void main() { shared int bar = 5; static assert(0); } shared class Singleton { shared void Foo(); // All good. void Baz(); // Error: non-shared method in shared class. } That's a lot more intuitive to me than a "static class", specially when compared to a "static assert". You'd think a static class is only available at compile time or something. Comments? Cheers, --AJG.
Aug 10 2005