www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Manifest constants (was const again)

reply "Janice Caron" <caron800 googlemail.com> writes:
Hoping to branch this off to a new thread to avoid polluting the const one...

On 12/6/07, Walter Bright <newshound1 digitalmars.com> wrote:
 That leaves what to do about manifest constants. It occurs that we
 already have a mechanism for them - enums. So why not:
         enum x = 3;
         enum long y = 4;
 ? I think that solves our problem.

Will it work for reals? enum pi = 3.14159265358979; ?
Dec 06 2007
next sibling parent Lukas Pinkowski <Lukas.Pinkowski web.de> writes:
Janice Caron wrote:

 Hoping to branch this off to a new thread to avoid polluting the const
 one...
 
 On 12/6/07, Walter Bright <newshound1 digitalmars.com> wrote:
 That leaves what to do about manifest constants. It occurs that we
 already have a mechanism for them - enums. So why not:
         enum x = 3;
         enum long y = 4;
 ? I think that solves our problem.

Will it work for reals? enum pi = 3.14159265358979; ?

I just try to imagine this one: enum ireal x = ... Enumerable imaginary real -> many mathematicians rotating in their graves ;-)
Dec 06 2007
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Janice Caron wrote:
 Hoping to branch this off to a new thread to avoid polluting the const one...
 
 On 12/6/07, Walter Bright <newshound1 digitalmars.com> wrote:
 That leaves what to do about manifest constants. It occurs that we
 already have a mechanism for them - enums. So why not:
         enum x = 3;
         enum long y = 4;
 ? I think that solves our problem.

Will it work for reals? enum pi = 3.14159265358979; ?

Yes.
Dec 06 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:
 Janice Caron wrote:
 Hoping to branch this off to a new thread to avoid polluting the const 
 one...

 On 12/6/07, Walter Bright <newshound1 digitalmars.com> wrote:
 That leaves what to do about manifest constants. It occurs that we
 already have a mechanism for them - enums. So why not:
         enum x = 3;
         enum long y = 4;
 ? I think that solves our problem.

Will it work for reals? enum pi = 3.14159265358979; ?

Yes.

And arrays? enum square = [[0,0],[1,0],[[1,1],[0,1]]; and hashes? enum str2component = ["x":0, "y":1, "z":2]; --bb
Dec 06 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
mandel wrote:
 I think enums shouldn't be misused for
 compile time constants.

But they already are used that way.
Dec 06 2007
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
 mandel wrote:
 I think enums shouldn't be misused for
 compile time constants.

But they already are used that way.

They're all we've got!
Dec 06 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
mandel wrote:
 No, it's not that bad. enums are a compile time constants, sure.
 But using an enum for a single compile time constants gives me a headache.
 Still, it's smth. many people are used to, myself included.

smth?
Dec 06 2007
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:
 mandel wrote:
 I think enums shouldn't be misused for
 compile time constants.

But they already are used that way.

I think they are only used that way because there isn't an alternative. Note that it reduces all kinds of potential for error checking. For example, the Windows API contains loads of #defines which are actually enums. But it also contains loads of #defines which are bit masks. A true enum is a genuine type. Bitwise operations without a cast are always a bug, and even arithmetic operations probably are too. eg enum { RED, BLUE, GREEN } (BLUE | RED) is nonsense (since if RED=0, BLUE=1, (BLUE|RED)==BLUE). Although (a) I don't know how often such bugs occur in practice; and (b) conceivably, you could generate a warning whenever such an operation was performed on a enum which contained at least one member which did not have an explicitly assigned value. I think there's significant merit in distinguishing genuine enums from compile-time constants.
Dec 07 2007
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Don Clugston wrote:

 Walter Bright wrote:
 mandel wrote:
 I think enums shouldn't be misused for
 compile time constants.

But they already are used that way.

I think they are only used that way because there isn't an alternative. Note that it reduces all kinds of potential for error checking. For example, the Windows API contains loads of #defines which are actually enums. But it also contains loads of #defines which are bit masks. A true enum is a genuine type. Bitwise operations without a cast are always a bug, and even arithmetic operations probably are too. eg enum { RED, BLUE, GREEN } (BLUE | RED) is nonsense (since if RED=0, BLUE=1, (BLUE|RED)==BLUE). Although (a) I don't know how often such bugs occur in practice; and (b) conceivably, you could generate a warning whenever such an operation was performed on a enum which contained at least one member which did not have an explicitly assigned value. I think there's significant merit in distinguishing genuine enums from compile-time constants.

I agree. Of the keywords mentioned (macro, final, alias and enum), enum is the _worst_ match for this feature. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Dec 07 2007
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Don Clugston wrote:
 I think they are only used that way because there isn't an alternative.
 Note that it reduces all kinds of potential for error checking.
 For example, the Windows API contains loads of #defines which are 
 actually enums. But it also contains loads of #defines which are bit masks.
 A true enum is a genuine type. Bitwise operations without a cast are 
 always a bug, and even arithmetic operations probably are too. eg
 enum { RED, BLUE, GREEN }
 (BLUE | RED) is nonsense (since if RED=0, BLUE=1, (BLUE|RED)==BLUE).

I see that as one use for enums, but another use is for grouping together logically related constants. A set of bit masks would fit in the latter category.
 Although
 (a) I don't know how often such bugs occur in practice; and
 (b) conceivably, you could generate a warning whenever such an operation 
 was performed on a enum which contained at least one member which did 
 not have an explicitly assigned value.
 
 I think there's significant merit in distinguishing genuine enums from 
 compile-time constants.

Dec 07 2007
prev sibling parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Walter Bright wrote:
 mandel wrote:
 I think enums shouldn't be misused for
 compile time constants.

But they already are used that way.

But that is hardly what they are designed for. Like C++ TMP, it is discovered rather than designed. D can do much better. Like others, I propose that manifest constants use the alias keyword. Alias is perfect for this. Since they don't occupy storage, they could thus also be polysemous values in the future. alias str = "str"; could mean that foo(str) is equivalent to foo("str") Something that typed constants could not handle. -- Oskar
Dec 07 2007
next sibling parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Janice Caron wrote:
 On 12/7/07, Oskar Linde <oskar.lindeREM ovegmail.com> wrote:
 Like others, I propose that manifest constants use the alias keyword.
 Alias is perfect for this. Since they don't occupy storage, they could
 thus also be polysemous values in the future.

 alias str = "str";

I'm uncomfortable with having alias dest = source; in one circumstance, but alias source dest; in others. I would find that confusing.

Then just make the two forms equivalent and maybe depreciate the second one with time. alias pi = 3.14; alias toString = to!(string); Why would this be a problem? -- Oskar
Dec 07 2007
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
Oskar Linde wrote:
 Janice Caron wrote:
 alias str =3D "str";

alias dest =3D source; in one circumstance, but alias source dest; in others. I would find that confusing.

Then just make the two forms equivalent and maybe depreciate the secon=

 one with time.

 alias pi =3D 3.14;
 alias toString =3D to!(string);

 Why would this be a problem?

Because it breaks with the C/C++ heritage, methinks. Anyways, is there a reason why we can't use 'alias 3.14 pi;'?
Dec 07 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Simen Kjaeraas wrote:
 Oskar Linde wrote:
 Janice Caron wrote:
 alias str = "str";

alias dest = source; in one circumstance, but alias source dest; in others. I would find that confusing.

Then just make the two forms equivalent and maybe depreciate the second one with time. alias pi = 3.14; alias toString = to!(string); Why would this be a problem?

Because it breaks with the C/C++ heritage, methinks.

I hate to point out the obvious, but there is no "alias" in C or C++. Ok, yes there's typedef in C, but if you go and completely change the keyword used, I think you are justified in changing the syntax.
 Anyways, is there a reason why we can't use 'alias 3.14 pi;'?

Things like alias 3.14 + ctfe_func("two") / other_constant pi; make that much harder to read than alias pi = 3.14 + ctfe_func("two") / other_constant; But the same is true for the current type aliases. You can see it a lot in templates. There its not uncommon to see things like alias some long thing that eventually figures out a type Foo; --bb
Dec 07 2007
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
Bill Baxter wrote:
  Because it breaks with the C/C++ heritage, methinks.

I hate to point out the obvious, but there is no "alias" in C or C++. Ok, yes there's typedef in C, but if you go and completely change the =

 keyword used, I think you are justified in changing the syntax.

Thank you, I'm well aware of that. My point was typedef. Having typedef = = and alias (which do /similar/ things) have vastly different syntax would= = seem strange (and break existing code). Changing both to the 'op dst =3D= = src' syntax might have its advantages, though.
 Anyways, is there a reason why we can't use 'alias 3.14 pi;'?

Things like alias 3.14 + ctfe_func("two") / other_constant pi; make that much harder to read than alias pi =3D 3.14 + ctfe_func("two") / other_constant; But the same is true for the current type aliases. You can see it a l=

 in templates.  There its not uncommon to see things like

    alias some long thing that eventually figures out a type Foo;

 --bb

I fully agree with that. Yet that is how things are at the moment, and a= t = the very least we should strive to have a consistent syntax, so you don'= t = define constants using 'alias a =3D 4' and types using 'alias src dst'. Also, like some people like to point out (me often coding in notepad = excludes me from that group), a good IDE might make it more obvious.
Dec 07 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Simen Kjaeraas wrote:
 Bill Baxter wrote:
  Because it breaks with the C/C++ heritage, methinks.

I hate to point out the obvious, but there is no "alias" in C or C++. Ok, yes there's typedef in C, but if you go and completely change the keyword used, I think you are justified in changing the syntax.

Thank you, I'm well aware of that. My point was typedef. Having typedef and alias (which do /similar/ things) have vastly different syntax would seem strange (and break existing code). Changing both to the 'op dst = src' syntax might have its advantages, though.
 Anyways, is there a reason why we can't use 'alias 3.14 pi;'?

Things like alias 3.14 + ctfe_func("two") / other_constant pi; make that much harder to read than alias pi = 3.14 + ctfe_func("two") / other_constant; But the same is true for the current type aliases. You can see it a lot in templates. There its not uncommon to see things like alias some long thing that eventually figures out a type Foo; --bb

I fully agree with that. Yet that is how things are at the moment, and at the very least we should strive to have a consistent syntax, so you don't define constants using 'alias a = 4' and types using 'alias src dst'.

I think it would be a good candidate for preservation of C-ish syntax as an aid to porting and C refugees. Just like in D we have float[] x as the improved syntax and float x[] as legacy syntax, we could have both "alias Y=X" as new-and-improved and "alias X Y" as an aid to porting. As for being confusing, doing it the wrong way is going to be a compiler error, so I don't think it's a big deal.
 Also, like some people like to point out (me often coding in notepad
 excludes me from that group), a good IDE might make it more obvious.

I think code should be as readable as possible without an IDE. If you're going to design a language with the use of IDEs in mind then go all the way and make it integral, like with Smalltalk. --bb
Dec 07 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 Just like in D we have float[] x  as the improved syntax and float x[] 
 as legacy syntax, we could have both  "alias Y=X" as new-and-improved 
 and "alias X Y" as an aid to porting.  As for being confusing, doing it 
 the wrong way is going to be a compiler error, so I don't think it's a 
 big deal.

Looking it in the light of trying to avoid: enum int Y = X; I think it is a big deal. The enum form wouldn't have any obvious problems like that.
Dec 07 2007
parent reply John Reimer <terminal.node gmail.com> writes:
Walter Bright wrote:
 Bill Baxter wrote:
 Just like in D we have float[] x  as the improved syntax and float x[] 
 as legacy syntax, we could have both  "alias Y=X" as new-and-improved 
 and "alias X Y" as an aid to porting.  As for being confusing, doing 
 it the wrong way is going to be a compiler error, so I don't think 
 it's a big deal.

Looking it in the light of trying to avoid: enum int Y = X; I think it is a big deal. The enum form wouldn't have any obvious problems like that.

May I ask what Andrei Alexandrescu's opinion is of using 'enum' as manifest const? Seems to me that this choice wouldn't pass unnoticed by him, and I know he has some small influence on D. :-) -JJR
Dec 08 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
John Reimer wrote:
 May I ask what Andrei Alexandrescu's opinion is of using 'enum' as 
 manifest const?  Seems to me that this choice wouldn't pass unnoticed by 
 him, and I know he has some small influence on D. :-)

He immediately liked it. So the condemnation of enum isn't quite as universal as one might suspect reading these threads <g>.
Dec 08 2007
parent reply John Reimer <terminal.node gmail.com> writes:
Walter Bright wrote:
 John Reimer wrote:
 May I ask what Andrei Alexandrescu's opinion is of using 'enum' as 
 manifest const?  Seems to me that this choice wouldn't pass unnoticed 
 by him, and I know he has some small influence on D. :-)

He immediately liked it. So the condemnation of enum isn't quite as universal as one might suspect reading these threads <g>.

Yep, that's what I was wondering. It seemed that there might have been some support coming elsewhere. :-) -JJR
Dec 08 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
John Reimer wrote:
 Walter Bright wrote:
 John Reimer wrote:
 May I ask what Andrei Alexandrescu's opinion is of using 'enum' as 
 manifest const?  Seems to me that this choice wouldn't pass unnoticed 
 by him, and I know he has some small influence on D. :-)

He immediately liked it. So the condemnation of enum isn't quite as universal as one might suspect reading these threads <g>.

Yep, that's what I was wondering. It seemed that there might have been some support coming elsewhere. :-)

I didn't mention it before because appeal to authority is a logical fallacy, the idea should succeed or fail on its own merits.
Dec 08 2007
next sibling parent John Reimer <terminal.node gmail.com> writes:
Walter Bright wrote:
 John Reimer wrote:
 Walter Bright wrote:
 John Reimer wrote:
 May I ask what Andrei Alexandrescu's opinion is of using 'enum' as 
 manifest const?  Seems to me that this choice wouldn't pass 
 unnoticed by him, and I know he has some small influence on D. :-)

He immediately liked it. So the condemnation of enum isn't quite as universal as one might suspect reading these threads <g>.

Yep, that's what I was wondering. It seemed that there might have been some support coming elsewhere. :-)

I didn't mention it before because appeal to authority is a logical fallacy, the idea should succeed or fail on its own merits.

I can appreciate that, Walter: therefore perhaps it was right for you to be asked instead of you saying so first. It's a point of fact that Andrei figures heavily in the design of D; his authority in the matter is obvious... fallacy or no fallacy. But you are dealing with something much more complex in this group, and something that goes beyond formal debate rules. So make this a claim an appeal to honesty for the sake of everyone involved so they don't get too bent out of shape. :-) Some people don't appear to know what they are dealing with when they argue with you on the matter, so it's only fair for them to know the support you are receiving behind the scenes (which isn't a secret anyway), I think, so that they can consider how much sway they have in their personal arguments for or against a solution. Otherwise, people start getting "miffed" at what appears to stubborness on your part. I'm just hoping to clarify what's going on for your sake and others. It's really not nice to see people get upset over the matter. Andrei's has become a ghost in the background to such an extent that now any time something is put forward, it should be assumed that you and he have agreed prior to each proposal you make here. I think that's all that I wanted to point out. I don't mean to discredit or belittle you or him. All the best, John
Dec 08 2007
prev sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:
 John Reimer wrote:
 Walter Bright wrote:
 John Reimer wrote:
 May I ask what Andrei Alexandrescu's opinion is of using 'enum' as 
 manifest const?  Seems to me that this choice wouldn't pass 
 unnoticed by him, and I know he has some small influence on D. :-)

He immediately liked it. So the condemnation of enum isn't quite as universal as one might suspect reading these threads <g>.

Yep, that's what I was wondering. It seemed that there might have been some support coming elsewhere. :-)

I didn't mention it before because appeal to authority is a logical fallacy, the idea should succeed or fail on its own merits.

Yeh, I think it was right not to mention it. I wanted to see if it would stand or fail on its own merits too. And from my perspective it pretty much failed on the merits, but I'm willing to live with it given the authority of *two* independent experts (Walter and Andrei). The second reason to "let it be" is more or less what John Reimer said. I've made all the arguments I had against it, and it didn't convince Walter, so ... c'est la vie. It's just a programming language, and fortunately I'm pretty much free to move on to the next one if D accumulates too many design choices that I disagree with. Whereas Walter is pretty much stuck with whatever he creates. So if he thinks it's the right choice, then fine. He's the one implementing it. If he's wrong then he'll be the one sitting all alone wondering what happened to all the users of that promising new programming language he poured so many years of his life into. It's actually quite a daunting prospect, and I have a lot of respect for someone who can go all out like that. Third, I learned my lesson with foreach_reverse. Arguing with logic doesn't help. :-) And by the way, Andrei agreed that that one was ill-conceived, so that's part of why I respect his opinion on such matters now. I know he doesn't lightly tolerate ugliness in a language. (http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=50835). --bb
Dec 08 2007
prev sibling parent James Dennett <jdennett acm.org> writes:
Simen Kjaeraas wrote:
 Oskar Linde wrote:
 Janice Caron wrote:
 alias str = "str";

alias dest = source; in one circumstance, but alias source dest; in others. I would find that confusing.

Then just make the two forms equivalent and maybe depreciate the second one with time. alias pi = 3.14; alias toString = to!(string); Why would this be a problem?

Because it breaks with the C/C++ heritage, methinks.

As does C++ with the advent of generalized "using" in C++0x. Consistence with the past is one factor, but it's somtimes given too much weight.
 Anyways, is there a reason why we can't use 'alias 3.14 pi;'?

With more complex expressions, it's much less readable: the item being defined is lost at the end of the declaration (which is also a flaw with C's declaration syntax). -- James
Dec 23 2007
prev sibling next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Oskar Linde wrote:
 Walter Bright wrote:
 mandel wrote:
 I think enums shouldn't be misused for
 compile time constants.

But they already are used that way.

But that is hardly what they are designed for. Like C++ TMP, it is discovered rather than designed. D can do much better. Like others, I propose that manifest constants use the alias keyword. Alias is perfect for this. Since they don't occupy storage, they could thus also be polysemous values in the future. alias str = "str"; could mean that foo(str) is equivalent to foo("str") Something that typed constants could not handle.

I found it amusing that Walter's counter to this was that it would be "confusing" to have both alias X Y and alias Y=X. This from the guy who was telling us last week that const int foo() really isn't confusing once you get used to it. I'd say the same about alias Y=X :-) --bb
Dec 07 2007
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Oskar Linde wrote:
 Like others, I propose that manifest constants use the alias keyword. 
 Alias is perfect for this.

alias does make sense up to a point, and that point is: alias int x = 3; That makes no sense in the light of what alias currently does. Manifest constants are not untyped, although their type can often be inferred from their initializer, just like auto declarations.
Dec 07 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:
 Oskar Linde wrote:
 Like others, I propose that manifest constants use the alias keyword. 
 Alias is perfect for this.

alias does make sense up to a point, and that point is: alias int x = 3; That makes no sense in the light of what alias currently does.

Is there some reason why it matters what alias currently does? I think this is why most people here are disagreeing with you about using "enum". You seem to be looking from the language implementer's point of view and saying "which chunk of code do I have already implemented that would be easiest to change into something supporting manifest constants?". Whereas most of us are looking at the *words* and saying "which of these words best describes what we're trying to do?" Supporting alias int x = 3 may be more difficult to implement than enum int x = 3 because it changes the role of alias. But users of the language don't care. It still makes perfect sense in terms of what 'alias' *means*. x becomes an alias for the literal '3'. You can think of it as meaning alias x = cast(int)3; but who wants to type that? Since x will become something that acts a lot like an int variable, it makes sense to allow the use of the familiar "int x" declaration as well.
 Manifest 
 constants are not untyped, although their type can often be inferred 
 from their initializer, just like auto declarations.

So alias x = 3 should work too, and probably be a polysemous constant when those exist. I don't see a problem there. --bb
Dec 07 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 Is there some reason why it matters what alias currently does?

Yes, because it usually isn't a good idea to use it for something different but confusingly similar.
 I think 
 this is why most people here are disagreeing with you about using 
 "enum".  You seem to be looking from the language implementer's point of 
 view and saying "which chunk of code do I have already implemented that 
 would be easiest to change into something supporting manifest 
 constants?".

No, none of these schemes is particularly harder than the other to implement.
 Whereas most of us are looking at the *words* and saying 
 "which of these words best describes what we're trying to do?"

Keywords in programming languages often only have a remote semantic connection with their dictionary meaning, and sometimes none at all. But this still works because our brains are pretty good at switching into, say, "C mode" when reading C code, and we have no problem understanding that 'static' in one context means a member function without a 'this' pointer, while 'static' in another context means the variable is allocated space in the data segment rather than the stack segment. Neither definition is in the dictionary. I could argue similarly for 'class', 'extern', 'long', etc. What is appealing about enum is it is already used to declare manifest constants, and it is certainly already comfortably used to declare manifest constants that aren't "enumerations" in a dictionary sense of the word. My proposal is only a minor extension to an already existing use of the keyword, and I believe it is much less of a stretch than, say, using 'final'.
 Supporting  alias int x = 3  may be more difficult to implement than 
 enum int x = 3  because it changes the role of alias.

It is not more difficult to implement. But I do suggest it is more of a cognitive load, because it becomes harder to remember that: alias X Y; and: alias X = Y; are not only very different, but the *order* of the operands is reversed! This is a much more serious issue than I think it is given credit for. For example, gcc's inline assembler syntax has the operands reversed from Intel's assembler syntax. It is hard for me to explain how difficult this makes it for me to use gcc's inline assembler. If I use it for a while, I find myself staring at assembler code in complete non-comprehension. It's so bad that I refuse to write it any more. With the enum case, I doubt it would take more than a moment for someone to figure out what it was, and it is not confusingly similar to something else. Once one knows what it is, one might take a moment to ridicule the choice of keyword, but that's about it before getting past it and it becoming just more D jargon like static, class, and real.
Dec 08 2007
next sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Walter Bright wrote:
 Bill Baxter wrote:
 Whereas most of us are looking at the *words* and saying "which of
 these words best describes what we're trying to do?"

Keywords in programming languages often only have a remote semantic connection with their dictionary meaning, and sometimes none at all. But this still works because our brains are pretty good at switching into, say, "C mode" when reading C code, and we have no problem understanding that 'static' in one context means a member function without a 'this' pointer, while 'static' in another context means the variable is allocated space in the data segment rather than the stack segment. Neither definition is in the dictionary. I could argue similarly for 'class', 'extern', 'long', etc.

what it does. As for the others, your argument doesn't stand: class A class of people or things is a number of people or things that are considered together because *they have similar characteristics* It is therefore natural to define a class by the "similar characteristics" of its instances; extern (short for "external" or "externally") Happening, coming from, or existing outside a particular place [...] That is precisely what happens with most "extern" identifiers: they exist outside the current source file. From there, it is not too stretching to use the "extern" keyword to define how public identifiers will behave as seen from the outside; long (short for "long int") Long is used when giving information about the length of something [...] Again, this is very descriptive of what a "long" is. However, the dictionary definition for enumerate doesn't fit for a single value: enumerate When you enumerate a *list* of things, you name each one in turn. Jerome PS: All definitions courtesy of the Collins Cobuild dictionary, emphasis added by me. - -- +------------------------- Jerome M. BERGER ---------------------+ | mailto:jeberger free.fr | ICQ: 238062172 | | http://jeberger.free.fr/ | Jabber: jeberger jabber.fr | +---------------------------------+------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHWmaKd0kWM4JG3k8RAoXsAJ4+qETWDtMQFk2zRD5bJYVj04MwGwCaAy21 BVtkfQEng8VLfiMDJjr9/U8= =8Hq1 -----END PGP SIGNATURE-----
Dec 08 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jérôme M. Berger wrote:
 	I've always thought that "static" was a poor keyword for
 what it does. As for the others, your argument doesn't stand:
 
 class
     A class of people or things is a number of people or things that
     are considered together because *they have similar
     characteristics*
 
     It is therefore natural to define a class by the "similar
     characteristics" of its instances;

I'll concede that one.
 extern (short for "external" or "externally")
     Happening, coming from, or existing outside a particular place
     [...]
 
     That is precisely what happens with most "extern" identifiers:
     they exist outside the current source file. From there, it is
     not too stretching to use the "extern" keyword to define how
     public identifiers will behave as seen from the outside;

How does that fit with extern(C) ?
 long (short for "long int")
     Long is used when giving information about the length of
     something [...]
 
     Again, this is very descriptive of what a "long" is.

Ask someone who is a programmer, but not a C programmer, what a "long" is, and they will have no idea.
 	However, the dictionary definition for enumerate doesn't fit
 for a single value:
 
 enumerate
     When you enumerate a *list* of things, you name each one in
     turn.

A list of one is still a list. My dictionary defines enumerate as: "to name one by one". That certainly fits: enum X = 3; enum Y = 4; as I'm naming X and Y one by one. At least it fits as well as the other keywords do. 'virtual' should also be added to the list of keywords that have no connection to their dictionary meaning.
Dec 08 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:
 Jérôme M. Berger wrote:
     I've always thought that "static" was a poor keyword for
 what it does. As for the others, your argument doesn't stand:

 class
     A class of people or things is a number of people or things that
     are considered together because *they have similar
     characteristics*

     It is therefore natural to define a class by the "similar
     characteristics" of its instances;

I'll concede that one.
 extern (short for "external" or "externally")
     Happening, coming from, or existing outside a particular place
     [...]

     That is precisely what happens with most "extern" identifiers:
     they exist outside the current source file. From there, it is
     not too stretching to use the "extern" keyword to define how
     public identifiers will behave as seen from the outside;

How does that fit with extern(C) ?

What's the confusion? In that case you're declaring something that uses an externally defined calling convention, that defined by C. The calling convention is something outside the realm of that which is defined by D. There's no trouble with it linguistically.
 long (short for "long int")
     Long is used when giving information about the length of
     something [...]

     Again, this is very descriptive of what a "long" is.

Ask someone who is a programmer, but not a C programmer, what a "long" is, and they will have no idea.

That's not the point. The point is if you explain the etymology of the use of long to a non-C programmer it will make sense to them. Ok, long as in long number stored using a longer string of bytes than a normal integer. The original meaning still makes sense applied to the programming use. Which is not at all the same thing as saying that it completely explains and characterizes the programming use.
     However, the dictionary definition for enumerate doesn't fit
 for a single value:

 enumerate
     When you enumerate a *list* of things, you name each one in
     turn.

A list of one is still a list. My dictionary defines enumerate as: "to name one by one". That certainly fits: enum X = 3; enum Y = 4; as I'm naming X and Y one by one. At least it fits as well as the other keywords do.

So why don't we use array syntax to define all variables? A single variable is just an array of one, after all. Ok, I know why, but still that seems to be the sort of argument you're making there.
 'virtual' should also be added to the list of keywords that have no 
 connection to their dictionary meaning.

It doesn't seem so inappropriate to me. "Virtual" is used in optics to describe images that you can see but aren't really there . That sort of meaning was borrowed for computer memory. A virtual memory is one you can use as if it were really there. A virtual method is one that you can call as if it were really there. Sort of. Anyway what other word would you use to describe virtual methods? There's no real good word for it. Maybe "polymorphic" would have been better. I don't think Stroustrup had any particular constraints that forced him to pick "virtual", so I suspect he probably has a pretty good rationale for using that word. It's probably in his big book about the design of C++. Anyway, at the end of the day a finding precedents for poorly-named keywords in programming languages does not justify creating more of them. --bb
Dec 08 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Denton Cockburn wrote:
 On Sat, 08 Dec 2007 19:34:14 +0900, Bill Baxter wrote:
 
 That's not the point.  The point is if you explain the etymology of the
 use of long to a non-C programmer it will make sense to them.  Ok, long
 as in long number stored using a longer string of bytes than a normal
 integer.  The original meaning still makes sense applied to the
 programming use.  Which is not at all the same thing as saying that it
 completely explains and characterizes the programming use.

Doesn't this actually support Walter's point?

Nope. It does not. If the explanation involves "...so then we decided to just forget the original meaning of the word in English" then that's not really an etymological explanation. But whatever. I agree with John Reimer: if Walter can get this one past his inner cabal (namely Andrei) then fine. --bb
Dec 08 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 I agree with John Reimer: if Walter can get this one 
 past his inner cabal (namely Andrei) then fine.

Actually, Andrei thought it was a rather natural extension of the use of the word enum. I have been very surprised by the level of resistance here to it.
Dec 08 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:
 Bill Baxter wrote:
 I agree with John Reimer: if Walter can get this one past his inner 
 cabal (namely Andrei) then fine.

Actually, Andrei thought it was a rather natural extension of the use of the word enum.

I'm surprised by that, but he's the one who's going to have to explain it in a book, so if he's ok with it then well... I'll manage somehow.
 I have been very surprised by the level of resistance 
 here to it.

Not the first time I've heard you say that. ;-) --bb
Dec 08 2007
prev sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Walter Bright wrote:
 extern (short for "external" or "externally")
     Happening, coming from, or existing outside a particular place
     [...]

     That is precisely what happens with most "extern" identifiers:
     they exist outside the current source file. From there, it is
     not too stretching to use the "extern" keyword to define how
     public identifiers will behave as seen from the outside;

How does that fit with extern(C) ?

* Either the following is something that is outside the current code (external) and will be accessed using the "C" convention; * Or it is something that is inside the current code but should be accessible from outside (externally) using the "C" convention.
 
 long (short for "long int")
     Long is used when giving information about the length of
     something [...]

     Again, this is very descriptive of what a "long" is.

Ask someone who is a programmer, but not a C programmer, what a "long" is, and they will have no idea.

all its nuances simply from its name. However, tell any programmer, whether a C programmer or not, that "long" is short for "long integer" and they will understand immediately.
 
     However, the dictionary definition for enumerate doesn't fit
 for a single value:

 enumerate
     When you enumerate a *list* of things, you name each one in
     turn.

A list of one is still a list.

you need at least two elements in a list. Moreover, even if there is only one element in the list at this particular time, there is still the implication that there could be others.
 'virtual' should also be added to the list of keywords that have no
 connection to their dictionary meaning.

Is used to suggest that something is in effect what you say it is, although it is not formally recognized as such. That's not too far off: a virtual method is a function that is in effect what the child class says it is although the base class doesn't know it. I'll admit that this is a little more far fetched, but: - Just because there already are a few far-fetched concepts in programming isn't a reason to add another; - There is no implied meaning in the word "virtual" that conflict with the programming concept, whereas there is an implied meaning in "enum" that it concerns a list of several values. Jerome - -- +------------------------- Jerome M. BERGER ---------------------+ | mailto:jeberger free.fr | ICQ: 238062172 | | http://jeberger.free.fr/ | Jabber: jeberger jabber.fr | +---------------------------------+------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHWngzd0kWM4JG3k8RAqrpAKC0xa2b1sAxclmKmYShEbuDYTNPLQCfTAM1 tZv7gH3U/jGnAd1VTQQK8uY= =42Tt -----END PGP SIGNATURE-----
Dec 08 2007
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Denton Cockburn wrote:
 On Sat, 08 Dec 2007 11:55:47 +0100, Jérôme M. Berger wrote:
 
 A list of one is still a list.

you need at least two elements in a list. Moreover, even if there is only one element in the list at this particular time, there is still the implication that there could be others.

No, you don't need two elements in a list. That's just crazy talk.

Try to ask any one who *isn't* (they will be much closer to the *intuitive* meaning of the word) and see if they agree. (BTW, the dictionary says that a list is a "set of things [...]" note the plural form of "things"). I agree that from a strict mathematical point of view, a list may contain only one element (or even zero) but from an *intuitive* point of view it has several.
 enum would still fit what you're saying, here:
 
 enum x = 5; // one element in this 'list'

degenerate list, not a true one. Even when you put only one element in a "list", there is still the *implication* that you will add others at a later time.
 enum {
   x = 5;
   y = 7;  // now we've got 2
 }

- -- +------------------------- Jerome M. BERGER ---------------------+ | mailto:jeberger free.fr | ICQ: 238062172 | | http://jeberger.free.fr/ | Jabber: jeberger jabber.fr | +---------------------------------+------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHWtq9d0kWM4JG3k8RApE9AJ95171JFfj4e7jlh60IOowMdgey6ACgise4 hQrvWJ+sNciYcVNJgO33vMM= =CxdV -----END PGP SIGNATURE-----
Dec 08 2007
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Sat, 08 Dec 2007 01:01:27 -0800, Walter Bright wrote:

 With the enum case, I doubt it would take more than a moment for someone 
 to figure out what it was, and it is not confusingly similar to 
 something else. Once one knows what it is, one might take a moment to 
 ridicule the choice of keyword, but that's about it before getting past 
 it and it becoming just more D jargon like static, class, and real.

True and sad. Another opportunity to "do the right thing" missed. WILL THE NEW ENUM BE ALLOWED TO GROUP MANIFEST CONSTANTS TOGETHER? WILL THE NEW ENUM INFER THE TYPE FROM ITS LITERAL? WILL THE NEW ENUM BE ABLE TO USE CTFE? (I only shout this time because these questions keep being ignored by Walter). For example ... enum { defname = "upload.log", float fudge = 61.74, char starter = 'r', qwerty = 0xF4, foobar = SomeFunc("foobar") } -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Dec 08 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Derek Parnell wrote:
 On Sat, 08 Dec 2007 01:01:27 -0800, Walter Bright wrote:
 
 With the enum case, I doubt it would take more than a moment for someone 
 to figure out what it was, and it is not confusingly similar to 
 something else. Once one knows what it is, one might take a moment to 
 ridicule the choice of keyword, but that's about it before getting past 
 it and it becoming just more D jargon like static, class, and real.

True and sad. Another opportunity to "do the right thing" missed.

C'mon, it's not that big a deal!
 WILL THE NEW ENUM BE ALLOWED TO GROUP MANIFEST CONSTANTS TOGETHER?

No.
 WILL THE NEW ENUM INFER THE TYPE FROM ITS LITERAL?

Yes.
 WILL THE NEW ENUM BE ABLE TO USE CTFE?

Yes.
 For example ...
 enum
 {
    defname = "upload.log",
    float fudge = 61.74,
    char starter = 'r',
    qwerty = 0xF4,
    foobar = SomeFunc("foobar")  
 }

No, that would be: enum defname = "upload.log"; enum float fudge = 61.74; enum char starter = 'r'; enum qwerty = 0xF4; enum foobar = SomeFunc("foobar");
Dec 08 2007
next sibling parent reply =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Walter Bright wrote:
 Derek Parnell wrote:
 For example ...
 enum
 {
    defname = "upload.log",
    float fudge = 61.74,
    char starter = 'r',
    qwerty = 0xF4,
    foobar = SomeFunc("foobar")  }

No, that would be: enum defname = "upload.log"; enum float fudge = 61.74; enum char starter = 'r'; enum qwerty = 0xF4; enum foobar = SomeFunc("foobar");

So, basically, what you're saying is that not only enum is a list with only one element, but it's a list that can never have more than one element?? What kind of enumeration is that? Jerome - -- +------------------------- Jerome M. BERGER ---------------------+ | mailto:jeberger free.fr | ICQ: 238062172 | | http://jeberger.free.fr/ | Jabber: jeberger jabber.fr | +---------------------------------+------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHWvAMd0kWM4JG3k8RAka/AJ0QTvhU01It+KfJP30nywb3XlHdUQCgm9Tr vwHIIQIT9y7eWAntV/SLaJI= =pOLK -----END PGP SIGNATURE-----
Dec 08 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Jrme M. Berger wrote:
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 Walter Bright wrote:
 Derek Parnell wrote:
 For example ...
 enum
 {
    defname = "upload.log",
    float fudge = 61.74,
    char starter = 'r',
    qwerty = 0xF4,
    foobar = SomeFunc("foobar")  }

enum defname = "upload.log"; enum float fudge = 61.74; enum char starter = 'r'; enum qwerty = 0xF4; enum foobar = SomeFunc("foobar");

So, basically, what you're saying is that not only enum is a list with only one element, but it's a list that can never have more than one element?? What kind of enumeration is that?

That is amusing. So Walter, why not allow more than one element? --bb
Dec 08 2007
parent reply "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
On Sat, 08 Dec 2007 23:19:07 -0000, Bill Baxter  =

<dnewsgroup billbaxter.com> wrote:

 J=E9r=F4me M. Berger wrote:
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
  Walter Bright wrote:
 Derek Parnell wrote:
 For example ...
 enum
 {
    defname =3D "upload.log",
    float fudge =3D 61.74,
    char starter =3D 'r',
    qwerty =3D 0xF4,
    foobar =3D SomeFunc("foobar")  }

enum defname =3D "upload.log"; enum float fudge =3D 61.74; enum char starter =3D 'r'; enum qwerty =3D 0xF4; enum foobar =3D SomeFunc("foobar");

with only one element, but it's a list that can never have more than one element?? What kind of enumeration is that?

That is amusing. So Walter, why not allow more than one element? --bb

If it was really a list you could usefully have an empty one. I suspect the objection is mixing multiple types in one declaraiton. enum { a =3D 1; b =3D 2; } makes sense in a way that: enum { a =3D 1; b =3D "foo"; } does not.
Dec 08 2007
parent =?ISO-8859-15?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bruce Adams wrote:
 On Sat, 08 Dec 2007 23:19:07 -0000, Bill Baxter
 <dnewsgroup billbaxter.com> wrote:
 
 Jrme M. Berger wrote:
  Walter Bright wrote:
 Derek Parnell wrote:
 For example ...
 enum
 {
    defname = "upload.log",
    float fudge = 61.74,
    char starter = 'r',
    qwerty = 0xF4,
    foobar = SomeFunc("foobar")  }

enum defname = "upload.log"; enum float fudge = 61.74; enum char starter = 'r'; enum qwerty = 0xF4; enum foobar = SomeFunc("foobar");

with only one element, but it's a list that can never have more than one element?? What kind of enumeration is that?

That is amusing. So Walter, why not allow more than one element? --bb

If it was really a list you could usefully have an empty one. I suspect the objection is mixing multiple types in one declaraiton. enum { a = 1; b = 2; } makes sense in a way that: enum { a = 1; b = "foo"; } does not.

Which only goes to show that "enum" is a poor choice of keyword for manifest constants... Jerome - -- +------------------------- Jerome M. BERGER ---------------------+ | mailto:jeberger free.fr | ICQ: 238062172 | | http://jeberger.free.fr/ | Jabber: jeberger jabber.fr | +---------------------------------+------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHW5f8d0kWM4JG3k8RAm5DAJ4j7TM5rF73yJEUBxC6CxXYM0wogQCgsJks 8dJOdmSuw2is4zSPjNMt6VM= =m+5V -----END PGP SIGNATURE-----
Dec 08 2007
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Janice Caron wrote:
 On 12/8/07, Walter Bright <newshound1 digitalmars.com> wrote:
 No, that would be:

      enum defname = "upload.log";
      enum float fudge = 61.74;
      enum char starter = 'r';
      enum qwerty = 0xF4;
      enum foobar = SomeFunc("foobar");

The first one is interesting. Can I do enum s = "hello"; auto p = s.ptr; ?

The enum proposal was just to make enum take over for const in declaring manifest constants. Not to change the behavior of manifest constants. So whatever const s = "hello" does now in D2 should be what it does in the next iteration with enum s = "hello". --bb
Dec 08 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Janice Caron wrote:
 On 12/8/07, Bill Baxter <dnewsgroup billbaxter.com> wrote:
 The enum proposal was just to make enum take over for const in declaring
 manifest constants.  Not to change the behavior of manifest constants.

 So whatever const s = "hello" does now in D2 should be what it does in
 the next iteration with enum s = "hello".


FWIW, I ran it with D2 and the const version currently compiles and gives you an "invariant(char)*". But you probably knew that.
 
 What I'm getting at is, enums have no storage. You can't take the
 address of an enum (wheras you /can/ take the address of
 const-declared things). The impact of that is obvious, for primitive
 types like ints, but string is not a primitive type - it is an
 aggregate; an array.
 
 So the question I'm asking is, do the actual bytes of the array
 consume runtime storage space? It's not completely obvious to me that
 the answer would be yes.

I see what you mean. So you're suggesting that if the keyword is going to be 'enum' then the behavior *should* perhaps be different from current D2 const storage class? For something with a literal syntax like strings I think the answer should be the same as the answer to what you get applying the operation to a literal. So in the above case, "hello".ptr actually gives you an invariant(char)* also. So that seems consistent. --bb
Dec 08 2007
parent guslay <guslay gmail.com> writes:
Sorry to bring the keyword discussion up again, but does anyone like "literal"?

literal int x = 42;
literal y = 43;
literal abc = "abc";

A literal would be a typed non-addressable invariant.
Dec 09 2007
prev sibling next sibling parent reply "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
On Sat, 08 Dec 2007 19:44:50 -0000, Janice Caron <caron800 googlemail.co=
m>  =

wrote:

 On 12/8/07, Walter Bright <newshound1 digitalmars.com> wrote:
 No, that would be:

      enum defname =3D "upload.log";
      enum float fudge =3D 61.74;
      enum char starter =3D 'r';
      enum qwerty =3D 0xF4;
      enum foobar =3D SomeFunc("foobar");

The first one is interesting. Can I do enum s =3D "hello"; auto p =3D s.ptr; ?

You're just evil aren't you? If its a manifest constant you can't take i= ts = address without making it manifest beyond the compiler. That means the .ptr = property is not useable. I think that should be a compile time error. I don't really understand the problem myself. I always thought it was common sense that a 'simple' constant should onl= y = take up space: 1) If it is used 1a) if it is never used it should use no space 1b) if it is used only a few times its the compilers decision whether to= = place it in .bss 2) If you need to take the address of it I had assumed this was the case in D. I guess the problem is to do with modules. You don't know at compile tim= e = whether it will be used. So I guess you do need a way to say don't use any space after a= ll.
Dec 08 2007
parent Robert DaSilva <sp.unit.262+digitalmars gmail.com> writes:
Bruce Adams wrote:
 On Sat, 08 Dec 2007 19:44:50 -0000, Janice Caron
 <caron800 googlemail.com> wrote:
 
 On 12/8/07, Walter Bright <newshound1 digitalmars.com> wrote:
 No, that would be:

      enum defname = "upload.log";
      enum float fudge = 61.74;
      enum char starter = 'r';
      enum qwerty = 0xF4;
      enum foobar = SomeFunc("foobar");

The first one is interesting. Can I do enum s = "hello"; auto p = s.ptr; ?

You're just evil aren't you? If its a manifest constant you can't take its address without making it manifest beyond the compiler. That means the .ptr property is not useable. I think that should be a compile time error. I don't really understand the problem myself. I always thought it was common sense that a 'simple' constant should only take up space: 1) If it is used 1a) if it is never used it should use no space 1b) if it is used only a few times its the compilers decision whether to place it in .bss 2) If you need to take the address of it I had assumed this was the case in D. I guess the problem is to do with modules. You don't know at compile time whether it will be used. So I guess you do need a way to say don't use any space after all.

It would be valid because "hello".ptr is valid, but &1 isn't valid. See the difference?
Dec 09 2007
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Sat, 08 Dec 2007 11:16:27 -0800, Walter Bright wrote:

 Derek Parnell wrote:
 On Sat, 08 Dec 2007 01:01:27 -0800, Walter Bright wrote:
 
 With the enum case, I doubt it would take more than a moment for someone 
 to figure out what it was, and it is not confusingly similar to 
 something else. Once one knows what it is, one might take a moment to 
 ridicule the choice of keyword, but that's about it before getting past 
 it and it becoming just more D jargon like static, class, and real.

True and sad. Another opportunity to "do the right thing" missed.

C'mon, it's not that big a deal!

One can tell that from the reaction, no? As your suggestion has generated almost zero comment then it must be a small deal. In any case, the point is not so much how you see the size of the deal, but how your customer's do. My reading of the situation so far is that it struck instant and vocal opposition. The group of people in support have been quiet in comparison. Also, I feel it is especially significant that many of the people who have suggested that 'enum' is a poorer choice are not from the "usual suspects" set.
 WILL THE NEW ENUM BE ALLOWED TO GROUP MANIFEST CONSTANTS TOGETHER?

No.

I take it that you are not so enamored with the school of thought that believes compilers exist to make life easier for coders. This keeps coming through in the mixed messages. You seem to want D to be an improvement over the foibles of C/C++ yet you have introduced a few constructs that are their own new foibles. This one for example, means that redundant code will be needed and it has the potential to make reading source more difficult that it needs to be. So I repeat myself ... Another opportunity to "do the right thing" missed. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Dec 08 2007
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Derek Parnell wrote:
 On Sat, 08 Dec 2007 11:16:27 -0800, Walter Bright wrote:
 
 Derek Parnell wrote:
 On Sat, 08 Dec 2007 01:01:27 -0800, Walter Bright wrote:

 With the enum case, I doubt it would take more than a moment for someone 
 to figure out what it was, and it is not confusingly similar to 
 something else. Once one knows what it is, one might take a moment to 
 ridicule the choice of keyword, but that's about it before getting past 
 it and it becoming just more D jargon like static, class, and real.



One can tell that from the reaction, no? As your suggestion has generated almost zero comment then it must be a small deal. In any case, the point is not so much how you see the size of the deal, but how your customer's do. My reading of the situation so far is that it struck instant and vocal opposition. The group of people in support have been quiet in comparison.

Naysayers are always the more vocal group. People who agree with the status quo and those who just don't care aren't likely to post on the topic.
 Also, I feel it is especially significant that
 many of the people who have suggested that 'enum' is a poorer choice are
 not from the "usual suspects" set.
 
 WILL THE NEW ENUM BE ALLOWED TO GROUP MANIFEST CONSTANTS TOGETHER?


I take it that you are not so enamored with the school of thought that believes compilers exist to make life easier for coders. This keeps coming through in the mixed messages. You seem to want D to be an improvement over the foibles of C/C++ yet you have introduced a few constructs that are their own new foibles. This one for example, means that redundant code will be needed and it has the potential to make reading source more difficult that it needs to be.

Redundant code? You mean having to repeat those 4 letters e-n-u-m for each line? Anyway the strange thing to me is that this seems to work in D2: const { int x1 = 10; float x2 = "hithere"; } Taking the address of x1 or x2 generates an error. So making it not work for enum will require Walter to disable some functionality that currently exists. Which is odd because I thought the only change was going to be the name. --bb
Dec 08 2007
prev sibling parent John Reimer <terminal.node gmail.com> writes:
Derek Parnell wrote:
 On Sat, 08 Dec 2007 11:16:27 -0800, Walter Bright wrote:
 
 Derek Parnell wrote:
 On Sat, 08 Dec 2007 01:01:27 -0800, Walter Bright wrote:

 With the enum case, I doubt it would take more than a moment for someone 
 to figure out what it was, and it is not confusingly similar to 
 something else. Once one knows what it is, one might take a moment to 
 ridicule the choice of keyword, but that's about it before getting past 
 it and it becoming just more D jargon like static, class, and real.



One can tell that from the reaction, no? As your suggestion has generated almost zero comment then it must be a small deal. In any case, the point is not so much how you see the size of the deal, but how your customer's do. My reading of the situation so far is that it struck instant and vocal opposition. The group of people in support have been quiet in comparison. Also, I feel it is especially significant that many of the people who have suggested that 'enum' is a poorer choice are not from the "usual suspects" set.
 WILL THE NEW ENUM BE ALLOWED TO GROUP MANIFEST CONSTANTS TOGETHER?


I take it that you are not so enamored with the school of thought that believes compilers exist to make life easier for coders. This keeps coming through in the mixed messages. You seem to want D to be an improvement over the foibles of C/C++ yet you have introduced a few constructs that are their own new foibles. This one for example, means that redundant code will be needed and it has the potential to make reading source more difficult that it needs to be. So I repeat myself ... Another opportunity to "do the right thing" missed.

Firstly, I just wanted to say that I don't like the enum idea myself and honestly don't see how it "fits" as a solution... but, I'm now at the "oh well" stage when it comes to D. I know that I have practically zilch expertise in these things, so I'll just go a-whistling while I work and learn what I can from the sidelines (lots of good stuff to read!). Guys like Derek, who have experience and sense, can plow into these debates (although, I think it must be a little exhausting for him by now :-) ). Secondly, after this many years, it has become obvious that this newsgroup argues many points on issues that have already been decided (or practically so) behind the scenes. Some of these issues seem to be presented here almost as a way of "breaking the news", a kind of testing the waters. Thus the only purpose the vast majority of these discussions serve is that of socialization, education, and gossip ;-) around an exciting new language: it's a LOT of good discussion too... but perhaps just a little misguided if some presume that it has control factor (or even intimidation factor with Walter). It seems kind of strange that these attitudes continue even now. This group, then, really acts as a sounding board of savvy thinkers (okay, okay... I won't patronize you guys and gals: we're really just a herd of cattle! ;-)); nevertheless, I think some people, especially the newer ones that crop up every year or so, think they are molding the language with and for Walter. True, some discussion might amount to valuable contribution, but this prevalent perception of the openness of this language is pretty much invalid (this is not an accusation), and I think people get upset unnecessarily because the presume too much. This also contributes to the lynch mob mentality prevalent here (ie, the perception that nothing will happen until people thump Walter on the head and yard him up the tree). In reality, there are likely just a precious few people who REALLY have Walter's ear. For various reasons including some of the above, I'm actually much more relaxed and less prone to get perturbed at the process (amazing, but true!); this is not because I think it's right, but more because I'm no longer worried about the outcome. Quite possibly, Walter and friends have things in hand; and with support from Andrei and others, he likely has the best chance of convincing the huge mass of hard-headed, intractable outsiders (mostly the c++ world). So the fact that "good sense" here is not always listened to seems to be inconsequential. Quite honestly, if we count all the things that should have killed D long ago (or so we thought), the language would have been dead long ago. It is still getting along; and I think it's to the point where it will get along regardless of what some might call "perverse" decisions (enum included... strange as it may seem, it's not the worst), because as much as some of the ideas seem absolutely unsound, there seems to be enough rigor in the system to keep things moving in the right direction. Please consider that even Walter's track record shows that he drops language elements that "prove in practice" that they cannot work. All is not lost... -JJR
Dec 08 2007
prev sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Janice Caron wrote:
 I thought there was a principle that if something could be done with
 templates then it shouldn't be a language feature?

Yeah, I don't think that's a principle. We have a lot of constructs not strictly necessary, but highly useful abstractions.
Dec 08 2007
prev sibling next sibling parent mandel <oh no.es> writes:
I think enums shouldn't be misused for
compile time constants.
Dec 06 2007
prev sibling next sibling parent mandel <oh no.es> writes:
On Thu, 06 Dec 2007 21:44:16 -0800, Sean Kelly wrote:

 Walter Bright wrote:
 mandel wrote:
 I think enums shouldn't be misused for compile time constants.

But they already are used that way.

They're all we've got!

We are doomed! <g> No, it's not that bad. enums are a compile time constants, sure. But using an enum for a single compile time constants gives me a headache. Still, it's smth. many people are used to, myself included.
Dec 06 2007
prev sibling next sibling parent Denton Cockburn <diboss hotmail.com> writes:
On Thu, 06 Dec 2007 23:42:45 -0800, Walter Bright wrote:

 mandel wrote:
 No, it's not that bad. enums are a compile time constants, sure. But
 using an enum for a single compile time constants gives me a headache.
 Still, it's smth. many people are used to, myself included.

smth?

something (I think).
Dec 07 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On Dec 7, 2007 5:08 AM, Walter Bright <newshound1 digitalmars.com> wrote:
 mandel wrote:
 I think enums shouldn't be misused for
 compile time constants.

But they already are used that way.

Indeed they are. I use them that way all the time myself. If I want a compile time constant, I'll write enum { ONE = 1 } rather than static const int ONE = 1; every time. Obviously I'm going to applaud a more concise syntax, so long as it's not confusing. Removing the requirement of curly braces does seem kinda logical. That said, I'm now wondering if traditional enums arel likely to get beefed up to the new standard. As in, will we be able to do enum MyReal : real { PI=3.14159265358979, E=2.71828182845905 } MyReal r; It doesn't matter if not. I'm just asking.
Dec 07 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 12/7/07, Oskar Linde <oskar.lindeREM ovegmail.com> wrote:
 Like others, I propose that manifest constants use the alias keyword.
 Alias is perfect for this. Since they don't occupy storage, they could
 thus also be polysemous values in the future.

 alias str = "str";

I'm uncomfortable with having alias dest = source; in one circumstance, but alias source dest; in others. I would find that confusing.
Dec 07 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 12/8/07, Walter Bright <newshound1 digitalmars.com> wrote:
 but that's about it before getting past
 it and it becoming just more D jargon like static, class, and real.

Actually, I'm not too happy with "ireal" or "creal" either. I'd prefer "imaginary" and "complex". ...but back on topic... anyone coming from a C/C++ background (or, for that matter, PHP), will expect the word "define" to do this job. C/C++ #define x 3 PHP define("x",3); D? define x = 3;
Dec 08 2007
prev sibling next sibling parent Denton Cockburn <diboss hotmail.com> writes:
On Sat, 08 Dec 2007 19:34:14 +0900, Bill Baxter wrote:

 That's not the point.  The point is if you explain the etymology of the
 use of long to a non-C programmer it will make sense to them.  Ok, long
 as in long number stored using a longer string of bytes than a normal
 integer.  The original meaning still makes sense applied to the
 programming use.  Which is not at all the same thing as saying that it
 completely explains and characterizes the programming use.

Doesn't this actually support Walter's point? The point is if you explain the etymology of the use of enum to a D programmer, it will make sense to them. (barely changing anything from your statement). I'm one of the few that think that now that with the current D (not C/C+ +) meaning of enum, it makes a natural transition to do what Walter proposes. The important factor will be that it's explained to people. I get the feeling everyone in here, and anyone who you'd respect as a programmer, would have the mental capacity to be able to adjust to enum having this extended usage (especially after using it for a few days even).
Dec 08 2007
prev sibling next sibling parent Denton Cockburn <diboss hotmail.com> writes:
On Sat, 08 Dec 2007 11:55:47 +0100, Jérôme M. Berger wrote:

 A list of one is still a list.

you need at least two elements in a list. Moreover, even if there is only one element in the list at this particular time, there is still the implication that there could be others.

No, you don't need two elements in a list. That's just crazy talk. enum would still fit what you're saying, here: enum x = 5; // one element in this 'list' enum { x = 5; y = 7; // now we've got 2 }
Dec 08 2007
prev sibling next sibling parent Denton Cockburn <diboss hotmail.com> writes:
On Sat, 08 Dec 2007 20:58:52 +1100, Derek Parnell wrote:

 On Sat, 08 Dec 2007 01:01:27 -0800, Walter Bright wrote:
 
 With the enum case, I doubt it would take more than a moment for
 someone to figure out what it was, and it is not confusingly similar to
 something else. Once one knows what it is, one might take a moment to
 ridicule the choice of keyword, but that's about it before getting past
 it and it becoming just more D jargon like static, class, and real.

True and sad. Another opportunity to "do the right thing" missed. WILL THE NEW ENUM BE ALLOWED TO GROUP MANIFEST CONSTANTS TOGETHER?

Yes.
 
 WILL THE NEW ENUM INFER THE TYPE FROM ITS LITERAL?

Yes.
 
 WILL THE NEW ENUM BE ABLE TO USE CTFE?
 

Yes (would make sense, this is the only one I didn't see him asked and answer)
 (I only shout this time because these questions keep being ignored by
 Walter).

I disagree. I got the rest from him (and the thread).
 
 For example ...
 enum
 {
    defname = "upload.log",
    float fudge = 61.74,
    char starter = 'r',
    qwerty = 0xF4,
    foobar = SomeFunc("foobar")
 }

Not sure about this, but I think they all end with ; instead of , separating Walter - would both , and ; be allowed for this use of enum?
Dec 08 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 12/8/07, Walter Bright <newshound1 digitalmars.com> wrote:
 No, that would be:

      enum defname = "upload.log";
      enum float fudge = 61.74;
      enum char starter = 'r';
      enum qwerty = 0xF4;
      enum foobar = SomeFunc("foobar");

The first one is interesting. Can I do enum s = "hello"; auto p = s.ptr; ?
Dec 08 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 12/8/07, Bill Baxter <dnewsgroup billbaxter.com> wrote:
 The enum proposal was just to make enum take over for const in declaring
 manifest constants.  Not to change the behavior of manifest constants.

 So whatever const s = "hello" does now in D2 should be what it does in
 the next iteration with enum s = "hello".

What I'm getting at is, enums have no storage. You can't take the address of an enum (wheras you /can/ take the address of const-declared things). The impact of that is obvious, for primitive types like ints, but string is not a primitive type - it is an aggregate; an array. So the question I'm asking is, do the actual bytes of the array consume runtime storage space? It's not completely obvious to me that the answer would be yes.
Dec 08 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 12/8/07, Bill Baxter <dnewsgroup billbaxter.com> wrote:
 For something with a literal syntax like strings I think the answer
 should be the same as the answer to what you get applying the operation
 to a literal.  So in the above case, "hello".ptr actually gives you an
 invariant(char)* also.  So that seems consistent.

...except that it breaks the analogy with #define. In C, if I write a thousand lines of the form #define FOO "Bar" then zero bytes of that will appear in the executable - /unless/ I refer to one of those defined names in my program. Then, and only then, will the bytes of the string be needed, and used. This allows you to put lots and lots of strings in header files, safe in the knowledge that they will not take up any space, unless you use them. They are known at compile-time only, and if not used, are thrown away at the end of compilation. I don't know how that could work with enum strings. Maybe the string is somehow called into existence whenever it's referenced - or maybe the bytes of storage are used regardless? I'd be interested to know the answer.
Dec 08 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 12/8/07, Walter Bright <newshound1 digitalmars.com> wrote:
      enum defname = "upload.log";
      enum float fudge = 61.74;
      enum char starter = 'r';
      enum qwerty = 0xF4;

Just to be evil... <EVIL> I thought there was a principle that if something could be done with templates then it shouldn't be a language feature? string defname()() { return "upload.log" }; float fudge()() { return 61.74; } char starter()() { return 'r'; } ubyte qwerty()() { return 0xF4 } Now... auto x = fudge; should instantiate fudge!()(), then inline it, ultimately yielding "auto x = 61.74;", but the other manifest constants won't be instantiated, because they're never referenced. :-) </EVIL>
Dec 08 2007
prev sibling parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
On Sat, 8 Dec 2007, Bill Baxter wrote:

 Simen Kjaeraas wrote:
 Oskar Linde wrote:
 Janice Caron wrote:
 alias str = "str";

alias dest = source; in one circumstance, but alias source dest; in others. I would find that confusing.

Then just make the two forms equivalent and maybe depreciate the second one with time. alias pi = 3.14; alias toString = to!(string); Why would this be a problem?

Because it breaks with the C/C++ heritage, methinks.

I hate to point out the obvious, but there is no "alias" in C or C++. Ok, yes there's typedef in C, but if you go and completely change the keyword used, I think you are justified in changing the syntax.

I think it's also worth pointing out that 'alias' in D isn't just C/C++'s weak typedef. For example alias also includes the functionality of references: int a; int &b = a; is in D int a; alias a b; Having 'alias b = a' would be more consistent with that.
 Anyways, is there a reason why we can't use 'alias 3.14 pi;'?

Things like alias 3.14 + ctfe_func("two") / other_constant pi; make that much harder to read than alias pi = 3.14 + ctfe_func("two") / other_constant; But the same is true for the current type aliases. You can see it a lot in templates. There its not uncommon to see things like alias some long thing that eventually figures out a type Foo;

Thanks for bringing this up too. I think I saw Andrei commenting in some bug report that template alias params should handle also string literals. Now if you generalize it enough, alias could point to an AST subgraph. This is something you have in certain functional programming languages, and it's a powerful concept. Of course FPLs might be a curse word here, but I just wanted to mention it. The 'foo = bar' makes it clearer what part is lhs and what part rhs and maybe possibly D could extend it later to also include more than what it does now. I think the alias should work so that it doesn't reserve storage space for the symbols and also make use of polysemous values, if possible. Possibly auto/const variables could be used if also ro/rw storage needs to be provided.
Dec 09 2007