www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Change some keywords and enum manifests?

reply "Aziz K." <aziz.koeksal gmail.com> writes:
Hi,

Since we've got the attribute syntax ( identifier), wouldn't it be good to  
convert certain keywords to use this syntax?

E.g.:
nothrow ->  nothrow
pure ->  pure

Bam! Two fewer keywords in the language. :-)

On a related note, I would like to suggest to get rid of the ugly enum  
manifest syntax.

Possibilities:

1. Use 'pure' or  pure for marking manifest variables. (In case the  
suggestion above is not accepted.)
2. Use new  manifest attribute. E.g.:

enum int x = 2010; // Instead of this,
 manifest int x = 2010; // we use this. :-) :D


The current enum manifest syntax really hurts my eyes and my feelings as a  
compiler writer. Please, reconsider.

-- 
Dil: http://code.google.com/p/dil/
Apr 27 2010
next sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 04/27/2010 10:32 AM, Aziz K. wrote:

 Hi,

 Since we've got the attribute syntax ( identifier), wouldn't it be good
 to convert certain keywords to use this syntax?

 E.g.:
 nothrow ->  nothrow
 pure ->  pure

 Bam! Two fewer keywords in the language. :-)


One thing about D that appeals to me is the fact that you don't have to 
type that stupid at symbol for the various attributes. I must be in a 
minority, though.


 On a related note, I would like to suggest to get rid of the ugly enum
 manifest syntax.

 Possibilities:

 1. Use 'pure' or  pure for marking manifest variables. (In case the
 suggestion above is not accepted.)
 2. Use new  manifest attribute. E.g.:

 enum int x = 2010; // Instead of this,
  manifest int x = 2010; // we use this. :-) :D


This one's an improvement.


 The current enum manifest syntax really hurts my eyes and my feelings as
 a compiler writer. Please, reconsider.
Apr 27 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Aziz K.:

 Since we've got the attribute syntax ( identifier), wouldn't it be good to  
 convert certain keywords to use this syntax?


There was a long thread about this, that I think has gone nowhere, like a
stream that goes in the desert and evaporates fully. Some people agree with you
that having random usage of   in a language is not good.


Ellery Newcomer:

 One thing about D that appeals to me is the fact that you don't have to 
 type that stupid at symbol for the various attributes. I must be in a 
 minority, though.


  is not a nice thing to see, I think most people agree with you. But it's
acceptable for certain usages, for example for attributes with user-defined
semantics that aren't used often in the code, like the  readonly I have
proposed, etc.


Aziz K.:

 On a related note, I would like to suggest to get rid of the ugly enum
 manifest syntax.


Several persons think that enum used for manifest constants is just a hack.
This too was discussed, but I think Walter is not interested in improving this.
Recently I have also suggested to replace the keyword "immutable" with
something shorter, because I am writing it often in the code, something like
"val", as used in Scala. But this has not gotten lot of interest from people.



  manifest int x = 2010; // we use this. :-) :D




I don't like that a lot :-) It's almost worse than "enum". Try again.

Bye,
bearophile
Apr 27 2010
next sibling parent reply "Aziz K." <aziz.koeksal gmail.com> writes:
bearophile wrote:

  manifest int x = 2010; // we use this. :-) :D




 I don't like that a lot :-) It's almost worse than "enum". Try again.


The idea is to reduce the number of keywords, so the use of   is a must.

But like I suggested, alternatively we could simply replace enum manifests  
with the 'pure' keyword.
So 'pure' would have two meanings, depending on whether the symbol is a  
variable or a function.

-- 
Dil: http://code.google.com/p/dil/
Apr 27 2010
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tue, Apr 27, 2010 at 06:49:31PM +0200, Aziz K. wrote:

 The idea is to reduce the number of keywords, so the use of   is a must.


Why? A lot of people say reducing keywords is a good thing, but what's
the underlying reason for it?


 So 'pure' would have two meanings, depending on whether the symbol is a  
 variable or a function.


Gack, that's two uses that don't have anything to do with each other.

-- 
Adam D. Ruppe
http://arsdnet.net
Apr 27 2010
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Aziz K.:

 The idea is to reduce the number of keywords, so the use of   is a must.


I prefer to have a different keyword for each different concept. The situation
of the 'static' keyword is silly.

Bye,
bearophile
Apr 27 2010
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tue, Apr 27, 2010 at 01:12:13PM -0400, bearophile wrote:

 The situation of the 'static' keyword is silly.


Static isn't bad - it always means the same thing: "this won't change
across instances."

class A {
	static void f(); // f does the same across all instances of A
	static int a; // same variable across all instances of A
}

void f() {
	static int a; // same across all calls of function f()
}

The compile time ones also apply in the same way, if you think of the
program as being like a class, and instances of the program at runtime as
being objects.

static if(a) { } // doesn't change across instances of the program
static assert(a) // same as static if


The only place I can think of where it doesn't fit perfectly is static
import, and even then it fits loosely: calls to that module will always
be the same (fully qualified).


I'm ok with keyword reuse when it all fits under one main definition, which
static does. If you are giving multiple definitions to one word though, that's
less ideal.

enum works fine by me too by the way: it is any compile time value, which
also applies to manifest constants.

-- 
Adam D. Ruppe
http://arsdnet.net
Apr 27 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:mailman.82.1272389432.3522.digitalmars-d puremagic.com...

 On Tue, Apr 27, 2010 at 01:12:13PM -0400, bearophile wrote:

 The situation of the 'static' keyword is silly.


 Static isn't bad - it always means the same thing: "this won't change
 across instances."

 class A {
 static void f(); // f does the same across all instances of A
 static int a; // same variable across all instances of A
 }

 void f() {
 static int a; // same across all calls of function f()
 }

 The compile time ones also apply in the same way, if you think of the
 program as being like a class, and instances of the program at runtime as
 being objects.

 static if(a) { } // doesn't change across instances of the program
 static assert(a) // same as static if


 The only place I can think of where it doesn't fit perfectly is static
 import, and even then it fits loosely: calls to that module will always
 be the same (fully qualified).


 I'm ok with keyword reuse when it all fits under one main definition, 
 which
 static does. If you are giving multiple definitions to one word though, 
 that's
 less ideal.

 enum works fine by me too by the way: it is any compile time value, which
 also applies to manifest constants.


pure: The same input always results in the same output, and with no side 
effects.

A variable can be thought of as a zero-argument function (particularly true 
if you think of properties as being variables), and likewise, a manifest 
constant can be thought of as a zero-argument pure function (although, so 
can immutable vars, for that matter).

-------------------------------
Not sent from an iPhone.
Apr 27 2010
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:mailman.82.1272389432.3522.digitalmars-d puremagic.com...

 enum works fine by me too by the way: it is any compile time value, which
 also applies to manifest constants.


It's fine by the "fitting under the same definition" rule, but "enum" is 
still short for "enumeration", and ordinary manifest constants have nothing 
to do with enumerating anything.

-------------------------------
Not sent from an iPhone.
Apr 27 2010
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tue, Apr 27, 2010 at 02:05:34PM -0400, Nick Sabalausky wrote:

 It's fine by the "fitting under the same definition" rule, but "enum" is 
 still short for "enumeration", and ordinary manifest constants have nothing 
 to do with enumerating anything.


True. If it changed, I'd be ok with it. I'm ok with it the way it is now
too; really, I can go both ways and not care about it.
Apr 27 2010
prev sibling next sibling parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
bearophile <bearophileHUGS lycos.com> wrote:

 Recently I have also suggested to replace the keyword "immutable" with  
 something shorter, because I am writing it often in the code, something  
 like "val", as used in Scala. But this has not gotten lot of interest  
 from people.


That's because 'val' says absolutely nothing about the variable's
constancy. Immutable may be a mouthful, but at least it conveys some
useful information even for those who have not read the manual.

-- 
Simen
Apr 27 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Simen kjaeraas:

 That's because 'val' says absolutely nothing about the variable's
 constancy. Immutable may be a mouthful, but at least it conveys some
 useful information even for those who have not read the manual.


Identifiers and keywords like "$", "int" and "bool" are not words, yet they are
used instead of "length", "integer" and "boolean" (boolean is used in Java). So
in the end it's a matter of compromises between readability and length
(according to Zipf law too) (and convention too, "bool" is used by many
languages, so it's not hard to know what it is for). If something is used quite
often, then even an abbreviation can be acceptable (this was especially true
for languages like C designed before the current age of IDEs).

"val" is not an English word  and it means nothing, but it's an abbreviation of
"value" that is a word and from a mathematical point of view you can see it as
an immutable, as opposed to variable (named "var" in Scala).

I have proposed "val" because it's short, it has a precedent in Scala and
mathematics, it's easy to write (unlike "length"), and because I've seen in my
functions I now often annotate values with "immutable".

Bye,
bearophile
Apr 27 2010
prev sibling parent Norbert Nemec <Norbert Nemec-online.de> writes:
On 27/04/10 16:57, bearophile wrote:

  manifest int x = 2010; // we use this. :-) :D




 I don't like that a lot :-) It's almost worse than "enum". Try again.


I have seen other languages use "param" for compile time constants. This 
follows the ancient Fortran tradition where "parameter" has always been 
used for exactly this purpose.
Apr 27 2010
prev sibling parent reply Don <nospam nospam.com> writes:
Aziz K. wrote:

 On a related note, I would like to suggest to get rid of the ugly enum 
 manifest syntax.



 The current enum manifest syntax really hurts my eyes and my feelings as 
 a compiler writer. Please, reconsider.


That ship has long since sailed. Please don't waste any more thought on 
it. (It's just a hack to get around OPTLINK limitations, actually).
Apr 27 2010
parent reply "Aziz K." <aziz.koeksal gmail.com> writes:
Don wrote:

 That ship has long since sailed. Please don't waste any more thought on  
 it. (It's just a hack to get around OPTLINK limitations, actually).


I don't see what it has to do with OPTLINK. This is about syntax and the  
parser in the front-end.

-- 
Dil: http://code.google.com/p/dil/
Apr 27 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Aziz K.:

 I don't see what it has to do with OPTLINK.


With a smart compiler+linker there is no need to tell apart the two cases:

enum int x = 10;
immutable int y = 20;

If the linker is smart it can replace the references to y with 20 and then
remove all the y name from the binary, just like for the x case. With LTO the
LDC compiler is able to do this (but it's a D1 compiler, so there is only
const, that equals to D2 enum).

On the other hand in a case like this dmd evaluates foo() only for the x case,
so currently the enum semantics can not be fully replaced by immutable:

import std.c.stdio: printf;
int foo(int n) {
    int tot;
    foreach (i; 0 .. n)
        tot += i;
    return tot;
}
void main() {
    enum int x = foo(10);
    printf("%d\n", x);
    immutable int y = foo(20);
    printf("%d\n", y);
}

Bye,
bearophile
Apr 27 2010
next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-04-27 20:10:59 -0400, bearophile <bearophileHUGS lycos.com> said:


 With a smart compiler+linker there is no need to tell apart the two cases:
 
 enum int x = 10;
 immutable int y = 20;


Except when building a dynamic library.

Personally, I find it comforting to know for sure an enum value will 
never waste any space, optimization or not. But the semantic difference 
is quite subtle, its like a third kind of const, which makes the 
language harder to understand.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Apr 27 2010
prev sibling parent reply Pelle <pelle.mansson gmail.com> writes:
On 04/28/2010 02:10 AM, bearophile wrote:

 With a smart compiler+linker there is no need to tell apart the two cases:

 enum int x = 10;
 immutable int y = 20;

 If the linker is smart it can replace the references to y with 20 and then
remove all the y name from the binary, just like for the x case. With LTO the
LDC compiler is able to do this (but it's a D1 compiler, so there is only
const, that equals to D2 enum).


auto p = &y;

Can't do that with an enum!
Apr 29 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Pelle:

 auto p = &y;
 Can't do that with an enum!


Right. But if no address of y is ever taken, and other conditions are met, a
smart compiler can think of y as a manifest constant and remove it.

Bye,
bearophile
Apr 29 2010