Nice update!

Walter Bright wrote:
> 
> http://www.digitalmars.com/d/changelog.html
> 
> This has all the new import changes in it. That breaks a lot of existing code (like dmdscript), the fixes are simple (adding more import declarations) but tedious.
> 
> I couldn't find a better keyword choice than "static import".
> 
> The renaming uses '=' instead of 'as', 'from', or 'alias' for the reasons:
> 
> 1) didn't want to add new keywords, especially ones like 'as' as I use that as a variable name
> 

But would that require adding them as keywords? I mean, since the "as" (or whichever) appears in a specific and separate context, just as the "exit", "success" and "failure" of the scope statement, which are not keywords?

> 2) didn't need to add new keywords - adding them should be done only if using punctuation is completely unappealing
> 
> 3) using '=' and ':' is visually more distinct than embedded keywords.


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Andrei Khropov wrote:
>> If we can use FQN access a symbol directly, not need any importing, all
>> things going bo be consistent and natural.
>>
>> int main(void)
>> {
>>    std.stdio.writefln("Just do it"); // not need any importing
>>    ...
>> }
> 
> Well, it's how C# (and other .NET languages) does that. 
> 
> But I think explicit module declarations are more informative
> (you just look at the beginnig of the file to find out what it depends on)
>  and also aids tools like Build (no need to parse all the code to figure out
> dependencies)

I agree. There needs to be some 'anchor' that says where the names are coming from. Otherwise, the compiler can't tell the difference between an undefined identifier and a file not found. Even worse, a misspelled identifier can result in some odd module being imported, and all kinds of mischief.

Just like implicit declaration of variables is a bad idea, implicit importing is a bad idea.

Lionello Lunesu wrote:
> Walter, I'm glad you made these 'breaking changes'. Now is the right time to do this, and people won't mind 'fixing' their code. I think most people will actually be eager to adapt their code.

And actually, the fixes I made to DMDScript as a result of this did result in clearer code. So, it's all to the best.

Bruno Medeiros wrote:
> Nice update!
> 
> Walter Bright wrote:
>> 1) didn't want to add new keywords, especially ones like 'as' as I use that as a variable name
>>
> 
> But would that require adding them as keywords? I mean, since the "as" (or whichever) appears in a specific and separate context, just as the "exit", "success" and "failure" of the scope statement, which are not keywords?

Context dependent keywords are generally considered a bad idea. The scope words can never be confused with any identifiers, so I think that's not quite the same thing.

OK, I agree.

But, we need a fix for the redundancy, 'static import =' and 'import ='.

It's so ugly.


"Walter Bright" <newshound@digitalmars.com> ??????:e9mhnd$fmn$1@digitaldaemon.com...
> Andrei Khropov wrote:
>>> If we can use FQN access a symbol directly, not need any importing, all things going bo be consistent and natural.
>>>
>>> int main(void)
>>> {
>>>    std.stdio.writefln("Just do it"); // not need any importing
>>>    ...
>>> }
>>
>> Well, it's how C# (and other .NET languages) does that. But I think
>> explicit module declarations are more informative
>> (you just look at the beginnig of the file to find out what it depends
>> on)
>>  and also aids tools like Build (no need to parse all the code to figure
>> out
>> dependencies)
>
> I agree. There needs to be some 'anchor' that says where the names are coming from. Otherwise, the compiler can't tell the difference between an undefined identifier and a file not found. Even worse, a misspelled identifier can result in some odd module being imported, and all kinds of mischief.
>
> Just like implicit declaration of variables is a bad idea, implicit importing is a bad idea.
> 

Walter Bright wrote:
> Bruno Medeiros wrote:
> 
>> Nice update!
>>
>> Walter Bright wrote:
>>
>>> 1) didn't want to add new keywords, especially ones like 'as' as I use that as a variable name
>>>
>>
>> But would that require adding them as keywords? I mean, since the "as" (or whichever) appears in a specific and separate context, just as the "exit", "success" and "failure" of the scope statement, which are not keywords?
> 
> 
> Context dependent keywords are generally considered a bad idea. The scope words can never be confused with any identifiers, so I think that's not quite the same thing.

What's so bad about context dependent keywords?  They're great for disambiguating confusing syntax and making it more readable:

alias 'type' as 'identitifer'

Now you know the order of the alias statement; it reads left to right. You don't have to force 'as' to be a real keyword and effectively disallow its use as a variable.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O M--@ V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e h>--->++ r+++ y+++
------END GEEK CODE BLOCK------

James Dunne

James Dunne wrote:
> What's so bad about context dependent keywords?

Then the lexer cannot tokenize the source without doing a parse. This negatively impacts tools that need to do so like Ddoc.

Furthermore, it is confusing if one also has a typedef named 'as'. Having keywords be distinct, and always distinct, from identifiers means you can look at code and see what's an identifier and what's a keyword without confusion.

Walter Bright wrote:
> James Dunne wrote:
> 
>> What's so bad about context dependent keywords?
> 
> 
> Then the lexer cannot tokenize the source without doing a parse. This negatively impacts tools that need to do so like Ddoc.
> 

Sure it can.  Treat 'as' as an identifier everywhere.  It only has special meaning within the 'alias' statement syntax.  During parsing you treat it as an identifier and check that it equates to the string 'as'.

What does Ddoc need to know about keywords for?  It's a function of the DMD compiler and should thus know everything DMD knows.  'as' is not a keyword, anyway.  A tool designed to work with the language should implement a correct lexer and parser combination.

> Furthermore, it is confusing if one also has a typedef named 'as'. Having keywords be distinct, and always distinct, from identifiers means you can look at code and see what's an identifier and what's a keyword without confusion.

Perfectly legal:

alias int as as;

int main(char[][] args) {
	as	b;
	b = 2;
}

'as' means nothing to the compiler outside the 'alias' statement.  It goes back to the same argument as "IF THEN THEN ELSE ELSE END"

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O M--@ V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e h>--->++ r+++ y+++
------END GEEK CODE BLOCK------

James Dunne

James Dunne wrote:
> What does Ddoc need to know about keywords for?

For the color syntax highlighting of D source code.

Walter Bright wrote:
> 
> http://www.digitalmars.com/d/changelog.html
> 
> This has all the new import changes in it. That breaks a lot of existing code (like dmdscript), the fixes are simple (adding more import declarations) but tedious.
> 
> I couldn't find a better keyword choice than "static import".
> 
> The renaming uses '=' instead of 'as', 'from', or 'alias' for the reasons:
> 
> 1) didn't want to add new keywords, especially ones like 'as' as I use that as a variable name
> 
> 2) didn't need to add new keywords - adding them should be done only if using punctuation is completely unappealing
> 
> 3) using '=' and ':' is visually more distinct than embedded keywords.

Thanks - great release!