Andrei Alexandrescu (See Website For Email) wrote:
> Deewiant wrote:
>> The problem with "super const" is that "super" modifies the other keyword, "const", instead of saying something about the expression/statement/whatever (in this case, the type). Even "static", in all its horror, can be seen as specifying one of "module-level" or "compile-time". The other keywords mentioned above use their English meaning as such an explanation, and so can be understood without too much thought. "super const" would make "super" another "static": lacking context, you can't be sure about about even the general meaning, let alone the one in a specific instance.
>> 
>> Upon reflection it may be moot, since one probably rarely cares about keywords' meanings without context, but I'm sure some psychologist could come up with something about intuitiveness which affects coding speed, or whatever.
> 
> Working in NLP myself, I totally disagree. Natural language is rife with homonimy and synonimy, and we're all very, very happy with that. But in this case we don't even have to go that far: "super" is an adjective meaning primarily "of high grade or quality" and qualifies a noun. If there's no noun, you don't know what is "of high grade or quality". It's a fact, and we don't even blink.

Oh, I didn't say I was of that opinion myself. In fact, I have a tendency to disagree with psychology in general. <g> You're right and that's good a point.

> The reality behind super const is that it expresses a stronger form of const. It makes a lot of sense if I dub it "super const" in natural language, to express it in the same way in the programming language. I thought that that's too verbose and devised "const!" as a shortcut (again with obvious conotations in natural language), but I'm thinking of dropping it and let type inference add "super" to "const" whenever it can. That should ensure exactness of the type system without verbosity in source code.

"const!" has the advantage of being one word, but not really a new keyword. "super const" is two words. I still can't really express why I see that as a bad thing, but it _is_ better than adding a new keyword like "superconst" (or "keepyourgrubbyhandsoff"). I wouldn't be opposed to something like "readonly" though. Maybe I've just been coding too much Java recently: if I have to write "private final static double" much more I'm going to puke. <g>

It's largely a question of what one's used to. Elsewhere in the thread the fact that some languages have "elsif" or "elif" or equivalent instead of "else if" was mentioned. I don't really see much of a difference, except that "elif" takes a bit too long to process for me since the "el" -> "else" relation isn't intuitive. But, just like an eventual "super const" (and the current "static"), coding enough in a language with such will make it intuitive to me, and I won't complain (much).

In general, I do agree with your view, found elsewhere in the thread, that using existing keywords is best. That, or constructs like "scope (success)" where success isn't a keyword. I'm just currently a bit repelled by the pair "super const".

-- 
Remove ".doesnotlike.spam" from the mail address.

Benji Smith wrote:
> I should also add that, in my opinion, any design where "const" means something other than "value resolved at compile time and immutable at runtime" would be a mistake.

Then how would you call "value that's not mutable through this alias" in a way that's not going to turn C++ immigrants away?


Andrei

Deewiant wrote:
[snip]

> In general, I do agree with your view, found elsewhere in the thread, that using
> existing keywords is best. That, or constructs like "scope (success)" where
> success isn't a keyword. I'm just currently a bit repelled by the pair "super
> const".

Well how about "real const" then :oD.

I think the good news is that you don't need to type it that often. You type:

const char[] str = "Hi!";

and the compiler figures out the "super" part itself.


Andrei

Bruno Medeiros wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Derek Parnell wrote:
>>> Yes! "const!" is bad form. Really bad. Horrible in fact. Just make it a new
>>> keyword please, without using non-alpha characters. Such as "readonly",
>>> "immutable", "keepyourgrubbyhandsoff", ... anything but using "!".
>>
>> You can use "super const". We should be really really careful about adding new keywords; D already has tons, and I have a feeling we don't want it to become Cobol or dBase.
>>
>> If there are ways to stay away from new keywords, we'll do so. I do realize that no matter the syntax, there will be people who won't like it. But avoiding adding keywords liberally is an overriding desideratum.
>>
>>
>> Andrei
> 
> So instead of making D like Cobol we make it like APL ? :/
> I don't think the problem of Cobol was *having* too many keywords, but rather forcing you to *use* lots of keywords for the simplest things. (Disclaimer: I don't actually know Cobol, I'm imagining it to be like Pascal, but worse)

No. Ada is like Pascal, but worse :oO.

Cobol has 420 keywords.

> So we should have that in consideration when talking about D. In fact, I think that any general idea of "adding more keywords is bad" is somewhat pernicious: every case should be examined in itself. In some cases it could be worth it, in others not.

I agree.


Andrei

Andrei Alexandrescu (See Website For Email) wrote:
> Benji Smith wrote:
> 
>> I should also add that, in my opinion, any design where "const" means something other than "value resolved at compile time and immutable at runtime" would be a mistake.
> 
> 
> Then how would you call "value that's not mutable through this alias" in a way that's not going to turn C++ immigrants away?


there are explicit names for that sort of thing; "immutable", "readonly" , "view" etc.  Reading through the various replies gives the impression that you're concerned about propogating the broken C++ semantics than ensuring D corrects those faults ;)

I think it's worthwhile ensuring D gets it right instead, and I'll happily change all of Tango to reflect that if necessary. Breaking source-code for a keyword that is currently used rarely is not a problem. Incorrect or dubious/confusing semantics are. It may be worthwhile dumping the "const" keyword altogether, to limit confusion.

BTW, you've also mentioned changing "inout" to "ref" instead? That would probably break more code than a renaming of const; I know both Tango and Mango use inout quite a bit, but I'm happy to change those as necessary. Other people likely feel the same way.

- Kris

Am 16.03.2007, 18:59 Uhr, schrieb Andrei Alexandrescu (See Website For Email) <SeeWebsiteForEmail@erdani.org>:

> Because final const and super const express very different realities.

*scratches head*
Oh ... I didn't know that final const already HAD a meaning.

>  From your email I see you are Austrian, so I'm surprised. :o) German is the most synthetic (as opposed to analytical) language in use, and has the admirable property of building precise terms by combining smaller polysemous terms.

Yeah, I'm Austrian, living in the land that has been named after the chief from battlestar galactica, so I don't really speak german :) We have our own language, basically, that's why the rest of the german-speaking world can't understand us. Like the people from Switzerland can't be understood by anyone but themselves.

I like the idea of combining keywords to give them a new meaning, just using "super" for two totally unrelated concepts worries me a bit. "scope" for instance is great: It has two meanings, but they're completely related. But using super once as a call and once as a sort of amplifier for const seems kind of random. Also I can't help myself but "super const" just sounds a bit ridiculous to me:

' super duper über const int i = 3; // Holy constant, batman!

Sorry :)

Anyway, I have no better idea, so go for it!

-mike

-- 
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

Andrei Alexandrescu (See Website For Email) wrote:
> Benji Smith wrote:
>> I vote for "readonly" and "const". Anything else seems like a mistake.
> 
> Which is which? How would you have people distinguish them without running to the manual? How would you explain C++ immigrants that const is actually readonly, and there is a const, but that const means something else than their const?

How would you have people distinguish char/wchar/dchar without running to the Unicode standard to see which characters they can hold in a single unit?
Or short/int/long or float/double/real without running to the standard to look up the ranges and precision of those data types?

How would you explain to the average person from the Netherlands/Estonia/Finland/Germany/Slovakia[1] 'auto' doesn't have anything to do with transportation?
How would you explain to Dutchmen that 'long' doesn't have anything to do with breathing air? (Hint for all you foreigners out here: the Dutch word 'long' translates to 'lung' :P )

Some things are somewhat arbitrary conventions.
When you learn a new language, some words will mean different things, with other words that have the meaning you're used to.
It happens ;).

[1]: See http://dictionary.reference.com/search?q=car , specifically the first set of translations, roughly halfway down the page




Seriously though:
"readonly" would mean that you (meaning any code that can access the symbol so declared) can only read data referenced through it, but someone else _may_ be able to write to it[2].
"const" would mean it's just that: constant. *Nobody* can write to it.
Seems pretty easy to explain to me.

The only caveat I see is that "readonly" would mean the object itself can still be modified, as opposed to final. I don't see how calling it "const" would fix that, though.


[2]: Or of course that same code may be able to write to it, if for whatever reason it also has access to a mutable reference to the same data.

Andrei Alexandrescu (See Website For Email) wrote:
> We've shoved keywords like "readonly" and "view" for a while, and they just added more confusion than cleared, at a high cost. If (as I suspect) super const appears relatively infrequently, it might be fine to just encode it as the mildly verbose "super const". In fact, it's shorter than "keepyourgrubbyhandsoff". :o)

How about “const const”?  No new keywords, no reuse of keywords in disparate contexts, and equally noticeable to the eye.

--Joel

kris wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Benji Smith wrote:
>>
>>> I should also add that, in my opinion, any design where "const" means something other than "value resolved at compile time and immutable at runtime" would be a mistake.
>>
>>
>> Then how would you call "value that's not mutable through this alias" in a way that's not going to turn C++ immigrants away?
> 
> 
> there are explicit names for that sort of thing; "immutable", "readonly" , "view" etc.  Reading through the various replies gives the impression that you're concerned about propogating the broken C++ semantics than ensuring D corrects those faults ;)
> 
> I think it's worthwhile ensuring D gets it right instead, and I'll happily change all of Tango to reflect that if necessary. Breaking source-code for a keyword that is currently used rarely is not a problem. Incorrect or dubious/confusing semantics are. It may be worthwhile dumping the "const" keyword altogether, to limit confusion.
> 
> BTW, you've also mentioned changing "inout" to "ref" instead? That would probably break more code than a renaming of const; I know both Tango and Mango use inout quite a bit, but I'm happy to change those as necessary. Other people likely feel the same way.

++vote

For what it's worth, I like: 'final', 'view', and 'const' the best. They're all short and meaningful, given the intent for each.


Sean

Wow...

I've never put this much thought into const/final stuff.  Ultimately, the program *cannot* prevent data in memory from being changed.  It can at best prevent you from accidentally changing it; hence final and const declarations mean "I don't want anyone to change these, can you raise an error if someone tries to within D?"

Also, the problem breaks down to 'what am I declaring const?'.  If I declare:

const int* x; // is it the pointer, or the int?

This doesn't seem important until you get to:

const int[int**][]* x; // now what is it?

Ultimately, you have this problem going through each and every pointer, array and value.  You could theoretically write this:

const int[int**][]*[char[]][3][17][3,17]* x;  and now what are you going to do?  declare it:

final const final final const const final final final final final const?
Even final const! super const! final! const! doesn't work, in fact I agree it makes it worse.

Good luck getting readability with that.

Ultimately, something else needs to be developed.

Perhaps a character we can use in alongside each item on the type declaration, or we need to be able to hit the whole line in one blow.

Just my penny.