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