www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Import proposals

reply "Regan Heath" <regan netwin.co.nz> writes:
After reading the entire "Re: import concerns (was Re: Historical language  
survey)" thread and hearing all the different opinions I thought "we need  
a single place to put complete ideas" and "people should show support for  
the idea they like best"

So.. I'd like this thread to be that place. I'm going to post my own idea  
(in response to this post) and I'd like it if people to post their own  
ideas (or the ideas of others as they understand them) in complete form.  
Then I'd like people to show support for an idea that takes their fancy.

This is to give Walter an idea what ideas have community support.

If people want to discuss the ideas, I suggest we start a new thread, or a  
sub thread of this port specifically for discussion, as opposed to  
commenting in response to the ideas themselves.

This is generally just an attempt to get the discussion organised and to  
provide a reference we can refer back to at a later date. I have a  
threaded news group reader and this'll probably only look organised if you  
use one too, as opposed to the web interface. If you all think it's a  
terrible idea, I won't feel too hurt ;)

Regan
Jul 09 2006
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
Sub-thread for discussions
Jul 09 2006
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
Something that has just occured to me WRT "Part-C" of my idea.. the  
restriction of allowing only one module is probably un-necessary if we  
assume a rule;

* If a module is a single word i.e. "mylib" it comes at the start of an  
import statement, eg.

   import mylib;

or

   import mylib,my.other.lib.copyFile;

etc.. and never after a "," eg.

   import my.other.lib.copyFile,mylib;

(where "copyFile" is a symbol in "my.other.lib" and "mylib" is not)

So, this allows multiple modules in the same import statement even  
allowing you to import them into the same named scope, some examples:

   import my.other.lib.copyFile,deleteFile,your.lib.moveFile;

imports "copyFile" and "deleteFile" from "my.other.lib" and "moveFile"  
 from "your.lib".

   import my.other.lib.copyFile,deleteFile,your.lib.moveFile as file;

imports "copyFile" and "deleteFile" from "my.other.lib" and "moveFile"  
 from "your.lib" into named scope "file".

Thoughts?

Regan
Jul 09 2006
next sibling parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Regan Heath wrote:

 Something that has just occured to me WRT "Part-C" of my idea.. the 
 restriction of allowing only one module is probably un-necessary if we 
 assume a rule;
 
 * If a module is a single word i.e. "mylib" it comes at the start of an 
 import statement, eg.
 
   import mylib;
 
 or
 
   import mylib,my.other.lib.copyFile;
 
 etc.. and never after a "," eg.
 
   import my.other.lib.copyFile,mylib;
 
 (where "copyFile" is a symbol in "my.other.lib" and "mylib" is not)
 
 So, this allows multiple modules in the same import statement even 
 allowing you to import them into the same named scope, some examples:
 
   import my.other.lib.copyFile,deleteFile,your.lib.moveFile;
 
 imports "copyFile" and "deleteFile" from "my.other.lib" and "moveFile" 
 from "your.lib".
 
   import my.other.lib.copyFile,deleteFile,your.lib.moveFile as file;
 
 imports "copyFile" and "deleteFile" from "my.other.lib" and "moveFile" 
 from "your.lib" into named scope "file".
 
 Thoughts?


Sorry, but I don't like it. I bet that every second coder new to the 
language would get totally confused by it.


-- 
Tomasz Stachowiak  /+ a.k.a. h3r3tic +/
Jul 09 2006
parent reply John Reimer <John_member pathlink.com> writes:
In article <e8s9fk$2e3f$1 digitaldaemon.com>, Tom S says...

Regan Heath wrote:

 Something that has just occured to me WRT "Part-C" of my idea.. the 
 restriction of allowing only one module is probably un-necessary if we 
 assume a rule;
 
 * If a module is a single word i.e. "mylib" it comes at the start of an 
 import statement, eg.
 
   import mylib;
 
 or
 
   import mylib,my.other.lib.copyFile;
 
 etc.. and never after a "," eg.
 
   import my.other.lib.copyFile,mylib;
 
 (where "copyFile" is a symbol in "my.other.lib" and "mylib" is not)
 
 So, this allows multiple modules in the same import statement even 
 allowing you to import them into the same named scope, some examples:
 
   import my.other.lib.copyFile,deleteFile,your.lib.moveFile;
 
 imports "copyFile" and "deleteFile" from "my.other.lib" and "moveFile" 
 from "your.lib".
 
   import my.other.lib.copyFile,deleteFile,your.lib.moveFile as file;
 
 imports "copyFile" and "deleteFile" from "my.other.lib" and "moveFile" 
 from "your.lib" into named scope "file".
 
 Thoughts?


Sorry, but I don't like it. I bet that every second coder new to the 
language would get totally confused by it.



I agree with, Tom.  Too confusing.
Jul 09 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Mon, 10 Jul 2006 02:01:31 +0000 (UTC), John Reimer  
<John_member pathlink.com> wrote:

 In article <e8s9fk$2e3f$1 digitaldaemon.com>, Tom S says...

 Regan Heath wrote:

 Something that has just occured to me WRT "Part-C" of my idea.. the
 restriction of allowing only one module is probably un-necessary if we
 assume a rule;

 * If a module is a single word i.e. "mylib" it comes at the start of an
 import statement, eg.

   import mylib;

 or

   import mylib,my.other.lib.copyFile;

 etc.. and never after a "," eg.

   import my.other.lib.copyFile,mylib;

 (where "copyFile" is a symbol in "my.other.lib" and "mylib" is not)

 So, this allows multiple modules in the same import statement even
 allowing you to import them into the same named scope, some examples:

   import my.other.lib.copyFile,deleteFile,your.lib.moveFile;

 imports "copyFile" and "deleteFile" from "my.other.lib" and "moveFile"
 from "your.lib".

   import my.other.lib.copyFile,deleteFile,your.lib.moveFile as file;

 imports "copyFile" and "deleteFile" from "my.other.lib" and "moveFile"
 from "your.lib" into named scope "file".

 Thoughts?


 Sorry, but I don't like it. I bet that every second coder new to the
 language would get totally confused by it.


 I agree with, Tom.  Too confusing.


Really? :(

I mean, I don't see importing specific symbols as something a 'new' coder  
would do.. For example 'in my imaginary world' I see mr new coder...

1. starting with hello world, eg.

--[helloworld.d]--
import std.stdio;
void main()
{
   writefln("Hello World");
}

2. Moving on to import his own module eg.

--[mymod.d]--
void sayHello() { writefln("Hello World"); }

--[helloworld.d]--
import std.stdio,mymod;
void main()
{
   sayHello();
}

which will all work fine, no problems.

3. It's when he starts to think.. "I just need writefln why not code it  
like this" ..

--[mymod.d]--
void sayHello() { writefln("Hello World"); }

--[helloworld.d]--
import std.stdio.writefln,mymod;
void main()
{
   sayHello();
}

that he'll get an error.

In short, it's only a problem if you import a specific symbol in the same  
statement as a module which has no package (no "." in the module  
name/path/whatever)

Regan
Jul 09 2006
parent =?ISO-8859-15?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Regan Heath wrote:

 1. starting with hello world, eg.
 
 --[helloworld.d]--
 import std.stdio;
 void main()
 {
   writefln("Hello World");
 }
 
 2. Moving on to import his own module eg.
 
 --[mymod.d]--
 void sayHello() { writefln("Hello World"); }
 
 --[helloworld.d]--
 import std.stdio,mymod;
 void main()
 {
   sayHello();
 }
 
 which will all work fine, no problems.
 
 3. It's when he starts to think.. "I just need writefln why not code it
 like this" ..
 
 --[mymod.d]--
 void sayHello() { writefln("Hello World"); }
 
 --[helloworld.d]--
 import std.stdio.writefln,mymod;
 void main()
 {
   sayHello();
 }
 
 that he'll get an error.


Of course he gets an error. How are you supposed to compile these
modules separately (ie. dmd -c mymod.d). It should be:

[mymod.d]
import std.stdio.writefln;
void sayHello() { writefln("Hello World"); }

[helloworld.d]
import mymod;
// or even: import mymod.sayHello;

void main()
{
  sayHello();
}

If you think of mymod.d as a library, how can it depend on an import
statement on a "client" module that is not possibly even implemented yet?

-- 
Jari-Matti
Jul 11 2006
prev sibling parent "Ameer Armaly" <ameer_armaly hotmail.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message 
news:optcf7kzem23k2f5 nrage...

 Something that has just occured to me WRT "Part-C" of my idea.. the 
 restriction of allowing only one module is probably un-necessary if we 
 assume a rule;

 * If a module is a single word i.e. "mylib" it comes at the start of an 
 import statement, eg.

   import mylib;

 or

   import mylib,my.other.lib.copyFile;

 etc.. and never after a "," eg.

   import my.other.lib.copyFile,mylib;

 (where "copyFile" is a symbol in "my.other.lib" and "mylib" is not)

 So, this allows multiple modules in the same import statement even 
 allowing you to import them into the same named scope, some examples:

   import my.other.lib.copyFile,deleteFile,your.lib.moveFile;

 imports "copyFile" and "deleteFile" from "my.other.lib" and "moveFile" 
 from "your.lib".

   import my.other.lib.copyFile,deleteFile,your.lib.moveFile as file;

 imports "copyFile" and "deleteFile" from "my.other.lib" and "moveFile" 
 from "your.lib" into named scope "file".

 Thoughts?


IMO it's a bit confusing, and I can't see very many cases where it's 
particularly useful, but that could just be me.

 Regan
Jul 09 2006
prev sibling next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
More random musings.. if we have a syntax that reads:

import std.stdio as foo;

which imports the symbols in std.stdio into a namespace called 'foo',  
preventing access as just "writefln" requiring "foo.writefln" then what  
happens in a case like this:

--[a.d]--
import std.stdio;
template foo { writefln("Hello World"); }

--[b.d]--
import std.stdio as foo;

void main() {
   mixin foo;
}

?

Regan
Jul 09 2006
parent reply Tyro <Tyro_member pathlink.com> writes:
In article <optcgd2ruo23k2f5 nrage>, Regan Heath says...

More random musings.. if we have a syntax that reads:

import std.stdio as foo;

which imports the symbols in std.stdio into a namespace called 'foo',  
preventing access as just "writefln" requiring "foo.writefln" then what  
happens in a case like this:

--[a.d]--
import std.stdio;
template foo { writefln("Hello World"); }

--[b.d]--
import std.stdio as foo;

void main() {
   mixin foo;
}

?

Regan



Well, as far as I can see you should get an error telling you that foo is not a
template. Now if you meant for the first line in [b.d] to read:

import a as foo;

Then I think we have a different issue. But since the programmer when through
the trouble of importing into a named scope, this should be a no braner. In
order to access the foo template , he needs to code explicitly.

:--[b.d]--
:import a as foo;
:
:void main() {
:   mixin foo;     // Error, foo is not a template
:   mixin foo.foo; // Ok
:}

Andrew
Jul 09 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Mon, 10 Jul 2006 03:43:07 +0000 (UTC), Tyro <Tyro_member pathlink.com>  
wrote:

 In article <optcgd2ruo23k2f5 nrage>, Regan Heath says...

 More random musings.. if we have a syntax that reads:

 import std.stdio as foo;

 which imports the symbols in std.stdio into a namespace called 'foo',
 preventing access as just "writefln" requiring "foo.writefln" then what
 happens in a case like this:

 --[a.d]--
 import std.stdio;
 template foo { writefln("Hello World"); }

 --[b.d]--
 import std.stdio as foo;

 void main() {
   mixin foo;
 }

 ?

 Regan



 Well, as far as I can see you should get an error telling you that foo  
 is not a
 template. Now if you meant for the first line in [b.d] to read:

 import a as foo;

 Then I think we have a different issue. But since the programmer when  
 through
 the trouble of importing into a named scope, this should be a no braner.  
 In
 order to access the foo template , he needs to code explicitly.

 :--[b.d]--
 :import a as foo;
 :
 :void main() {
 :   mixin foo;     // Error, foo is not a template
 :   mixin foo.foo; // Ok
 :}


Ooops, my bad example, what I meant was:

--[a.d]--
import std.stdio;
template foo { writefln("Hello World"); }

--[b.d]--
import std.stdio as bar;
import a;

void main() {
   mixin foo;
}

I accidently called the template and import named scope the same thing.

Regan
Jul 09 2006
parent reply Tyro <Tyro_member pathlink.com> writes:
In article <optcgh6iaa23k2f5 nrage>, Regan Heath says...

On Mon, 10 Jul 2006 03:43:07 +0000 (UTC), Tyro <Tyro_member pathlink.com>  
wrote:

 In article <optcgd2ruo23k2f5 nrage>, Regan Heath says...

 More random musings.. if we have a syntax that reads:

 import std.stdio as foo;

 which imports the symbols in std.stdio into a namespace called 'foo',
 preventing access as just "writefln" requiring "foo.writefln" then what
 happens in a case like this:

 --[a.d]--
 import std.stdio;
 template foo { writefln("Hello World"); }

 --[b.d]--
 import std.stdio as foo;

 void main() {
   mixin foo;
 }

 ?

 Regan



 Well, as far as I can see you should get an error telling you that foo  
 is not a
 template. Now if you meant for the first line in [b.d] to read:

 import a as foo;

 Then I think we have a different issue. But since the programmer when  
 through
 the trouble of importing into a named scope, this should be a no braner.  
 In
 order to access the foo template , he needs to code explicitly.

 :--[b.d]--
 :import a as foo;
 :
 :void main() {
 :   mixin foo;     // Error, foo is not a template
 :   mixin foo.foo; // Ok
 :}


Ooops, my bad example, what I meant was:

--[a.d]--
import std.stdio;
template foo { writefln("Hello World"); }

--[b.d]--
import std.stdio as bar;
import a;

void main() {
   mixin foo;
}

I accidently called the template and import named scope the same thing.

Regan


In this case I assume that you are concerned with conflicts that may be
generated between both imports of std.stdio in [a.d] and [b.d]. I don't see much
of a problem with this either.

Since [a.b] imports std.stdio publicly and into a global scope (or is that file
level scope?) anything that imports [a.b] will be able to access std.stdio
methods directly.

[b.d] however, imports std.stdio into a named scope. Thus all access to methods
identified in that particular scope should be prefexed accordinly. There should
be no conflicts.

:--[b.d]--
:import std.stdio as bar;
:import a;
:
:void main() {
:   mixin foo;
:   writefln("something"); // Accesses method imported in [a.d]
:   bar.writefln("somethingElse"); // Accesses method imported in [b.d]
:}

Unless of course I have completely missed the intent of importing into named
scopes.

Andrew
Jul 09 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Mon, 10 Jul 2006 05:37:41 +0000 (UTC), Tyro <Tyro_member pathlink.com>  
wrote:

 In article <optcgh6iaa23k2f5 nrage>, Regan Heath says...

 On Mon, 10 Jul 2006 03:43:07 +0000 (UTC), Tyro  
 <Tyro_member pathlink.com>
 wrote:

 In article <optcgd2ruo23k2f5 nrage>, Regan Heath says...

 More random musings.. if we have a syntax that reads:

 import std.stdio as foo;

 which imports the symbols in std.stdio into a namespace called 'foo',
 preventing access as just "writefln" requiring "foo.writefln" then  
 what
 happens in a case like this:

 --[a.d]--
 import std.stdio;
 template foo { writefln("Hello World"); }

 --[b.d]--
 import std.stdio as foo;

 void main() {
   mixin foo;
 }

 ?

 Regan



 Well, as far as I can see you should get an error telling you that foo
 is not a
 template. Now if you meant for the first line in [b.d] to read:

 import a as foo;

 Then I think we have a different issue. But since the programmer when
 through
 the trouble of importing into a named scope, this should be a no  
 braner.
 In
 order to access the foo template , he needs to code explicitly.

 :--[b.d]--
 :import a as foo;
 :
 :void main() {
 :   mixin foo;     // Error, foo is not a template
 :   mixin foo.foo; // Ok
 :}


 Ooops, my bad example, what I meant was:

 --[a.d]--
 import std.stdio;
 template foo { writefln("Hello World"); }

 --[b.d]--
 import std.stdio as bar;
 import a;

 void main() {
   mixin foo;
 }

 I accidently called the template and import named scope the same thing.

 Regan


 In this case I assume that you are concerned with conflicts that may be
 generated between both imports of std.stdio in [a.d] and [b.d].


Nope. In a.d you can call "writefln" but in b.d you must call  
"bar.writefln", plain old writefln will fail, right?
So, what does this mean for mixins?

Regan
Jul 10 2006
parent reply =?ISO-8859-15?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Regan Heath wrote:

 On Mon, 10 Jul 2006 05:37:41 +0000 (UTC), Tyro <Tyro_member pathlink.com>
wrote:

 In article <optcgh6iaa23k2f5 nrage>, Regan Heath says...

 --[a.d]--
 import std.stdio;
 template foo { writefln("Hello World"); }

 --[b.d]--
 import std.stdio as bar;
 import a;

 void main() {
   mixin foo;
 }

 I accidently called the template and import named scope the same thing.

 Regan


 In this case I assume that you are concerned with conflicts that may be
 generated between both imports of std.stdio in [a.d] and [b.d].


 
 Nope. In a.d you can call "writefln" but in b.d you must call
 "bar.writefln", plain old writefln will fail, right?
 So, what does this mean for mixins?


Are you referring to the existing functionality (sans implementation
bugs) or some specific proposal here. IMO Tyro is right and plain old
writefln definitely shouldn't fail here. It should only fail when
std.stdio has been imported privately in file a.d. But if import were
private by default, then the compiler would say 'b.d(5): undefined
identifier writefln'.

-- 
Jari-Matti
Jul 11 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 11 Jul 2006 23:46:03 +0300, Jari-Matti Mäkelä  
<jmjmak utu.fi.invalid> wrote:

 Regan Heath wrote:

 On Mon, 10 Jul 2006 05:37:41 +0000 (UTC), Tyro  
 <Tyro_member pathlink.com> wrote:

 In article <optcgh6iaa23k2f5 nrage>, Regan Heath says...

 --[a.d]--
 import std.stdio;
 template foo { writefln("Hello World"); }

 --[b.d]--
 import std.stdio as bar;
 import a;

 void main() {
   mixin foo;
 }

 I accidently called the template and import named scope the same  
 thing.

 Regan


 In this case I assume that you are concerned with conflicts that may be
 generated between both imports of std.stdio in [a.d] and [b.d].


 Nope. In a.d you can call "writefln" but in b.d you must call
 "bar.writefln", plain old writefln will fail, right?
 So, what does this mean for mixins?


 Are you referring to the existing functionality (sans implementation
 bugs) or some specific proposal here.


The proposal to import a module into a namespace. In this case "std.stdio"  
into "bar", meaning "writefln" does not exist but "bar.writefln" does.


 IMO Tyro is right and plain old
 writefln definitely shouldn't fail here. It should only fail when
 std.stdio has been imported privately in file a.d. But if import were
 private by default, then the compiler would say 'b.d(5): undefined
 identifier writefln'.


All I was really asking was...

If module a.d imports "std.stdio" into the current namespace, then calls  
"writefln" in a template which is then mixed into another source file b.d,  
which imports "std.stdio" into a named namespace "bar", can that template  
call "writefln"?

I suspect the answer would have to be "no". After all the mixin is mixed  
into the scope of b.d, it doesn't exist in the scope of a.d where  
"writefln" is valid.

All I was really trying to do was raise this as an issue which would occur  
(and need a solution) if we had import into namespace 'x'.

Regan
Jul 11 2006
next sibling parent reply =?ISO-8859-15?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Regan Heath wrote:

 On Tue, 11 Jul 2006 23:46:03 +0300, Jari-Matti Mäkelä
 <jmjmak utu.fi.invalid> wrote:

 Regan Heath wrote:

 On Mon, 10 Jul 2006 05:37:41 +0000 (UTC), Tyro
 <Tyro_member pathlink.com> wrote:

 In article <optcgh6iaa23k2f5 nrage>, Regan Heath says...

 --[a.d]--
 import std.stdio;
 template foo { writefln("Hello World"); }

 --[b.d]--
 import std.stdio as bar;
 import a;

 void main() {
   mixin foo;
 }

 I accidently called the template and import named scope the same
 thing.

 Regan


 In this case I assume that you are concerned with conflicts that may be
 generated between both imports of std.stdio in [a.d] and [b.d].


 Nope. In a.d you can call "writefln" but in b.d you must call
 "bar.writefln", plain old writefln will fail, right?
 So, what does this mean for mixins?


 Are you referring to the existing functionality (sans implementation
 bugs) or some specific proposal here.


 
 The proposal to import a module into a namespace. In this case
 "std.stdio" into "bar", meaning "writefln" does not exist but
 "bar.writefln" does.


But if you import both:
 import std.stdio as bar;
 import std.stdio; (it's a public import, isn't it)

which (AFAIK) is exactly the same as

module a:
 import std.stdio;
module b:
 import a;
 import std.stdio as bar;

Doesn't that mean that you can use both:
[1]  writefln(...);
and
[2]  bar.writefln(...);
?

Which one of the proposals makes it illegal to call [1] in module b?


 All I was really asking was...
 
 If module a.d imports "std.stdio" into the current namespace, then calls
 "writefln" in a template which is then mixed into another source file
 b.d, which imports "std.stdio" into a named namespace "bar", can that
 template call "writefln"?
 
 I suspect the answer would have to be "no".


Um, I don't think so. The only thing that could make it illegal is that
 template foo { writefln("Hello World"); }
isn't valid D. Maybe it should be
 template foo { void hello() { writefln("Hello World"); } }
?


 After all the mixin is mixed
 into the scope of b.d, it doesn't exist in the scope of a.d where
 "writefln" is valid.


Correct. From http://www.digitalmars.com/d/mixin.html: "Unlike a
template instantiation, a template mixin's body is evaluated within the
scope where the mixin appears, not where the template declaration is
defined. It is analogous to cutting and pasting the body of the template
into the location of the mixin."


 All I was really trying to do was raise this as an issue which would
 occur (and need a solution) if we had import into namespace 'x'.


I think a more interesting use case would be to use real templates
(they're instantiated in module a) instead of mixins and module a that
is using a import statement that only imports some of the std.stdio
members. That might even cause some trouble?

-- 
Jari-Matti
Jul 11 2006
parent "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 12 Jul 2006 02:20:06 +0300, Jari-Matti Mäkelä  
<jmjmak utu.fi.invalid> wrote:

 Regan Heath wrote:

 On Tue, 11 Jul 2006 23:46:03 +0300, Jari-Matti Mäkelä
 <jmjmak utu.fi.invalid> wrote:

 Regan Heath wrote:

 On Mon, 10 Jul 2006 05:37:41 +0000 (UTC), Tyro
 <Tyro_member pathlink.com> wrote:

 In article <optcgh6iaa23k2f5 nrage>, Regan Heath says...

 --[a.d]--
 import std.stdio;
 template foo { writefln("Hello World"); }

 --[b.d]--
 import std.stdio as bar;
 import a;

 void main() {
   mixin foo;
 }

 I accidently called the template and import named scope the same
 thing.

 Regan


 In this case I assume that you are concerned with conflicts that may  
 be
 generated between both imports of std.stdio in [a.d] and [b.d].


 Nope. In a.d you can call "writefln" but in b.d you must call
 "bar.writefln", plain old writefln will fail, right?
 So, what does this mean for mixins?


 Are you referring to the existing functionality (sans implementation
 bugs) or some specific proposal here.


 The proposal to import a module into a namespace. In this case
 "std.stdio" into "bar", meaning "writefln" does not exist but
 "bar.writefln" does.


 But if you import both:
  import std.stdio as bar;
  import std.stdio; (it's a public import, isn't it)

 which (AFAIK) is exactly the same as

 module a:
  import std.stdio;
 module b:
  import a;
  import std.stdio as bar;

 Doesn't that mean that you can use both:
 [1]  writefln(...);
 and
 [2]  bar.writefln(...);
 ?

 Which one of the proposals makes it illegal to call [1] in module b?


Ahh, I've done it again. That'll teach me for not at least coding my  
little example up. I was assuming the import was private.. again.. (which  
I think they should be, by default)


 All I was really asking was...

 If module a.d imports "std.stdio" into the current namespace, then calls
 "writefln" in a template which is then mixed into another source file
 b.d, which imports "std.stdio" into a named namespace "bar", can that
 template call "writefln"?

 I suspect the answer would have to be "no".


 Um, I don't think so. The only thing that could make it illegal is that
  template foo { writefln("Hello World"); }
 isn't valid D. Maybe it should be
  template foo { void hello() { writefln("Hello World"); } }
 ?


No.. I was mistakenly assuming I could put _anything_ into a template,  
including calls to writefln into 'main' .. turns out you can only put  
stuff you could declare at the global scope in there. variables,  
functions, etc. not calls to function. My bad.


 After all the mixin is mixed
 into the scope of b.d, it doesn't exist in the scope of a.d where
 "writefln" is valid.


 Correct. From http://www.digitalmars.com/d/mixin.html: "Unlike a
 template instantiation, a template mixin's body is evaluated within the
 scope where the mixin appears, not where the template declaration is
 defined. It is analogous to cutting and pasting the body of the template
 into the location of the mixin."


 All I was really trying to do was raise this as an issue which would
 occur (and need a solution) if we had import into namespace 'x'.


 I think a more interesting use case would be to use real templates
 (they're instantiated in module a) instead of mixins and module a that
 is using a import statement that only imports some of the std.stdio
 members. That might even cause some trouble?


Example?

Regan
Jul 11 2006
prev sibling parent reply Tyro <Tyro_member pathlink.com> writes:
In article <optcjo9wna23k2f5 nrage>, Regan Heath says...

On Tue, 11 Jul 2006 23:46:03 +0300, Jari-Matti MäkelE 
<jmjmak utu.fi.invalid> wrote:

 Regan Heath wrote:

 On Mon, 10 Jul 2006 05:37:41 +0000 (UTC), Tyro  
 <Tyro_member pathlink.com> wrote:

 In article <optcgh6iaa23k2f5 nrage>, Regan Heath says...

 --[a.d]--
 import std.stdio;
 template foo { writefln("Hello World"); }

 --[b.d]--
 import std.stdio as bar;
 import a;

 void main() {
   mixin foo;
 }

 I accidently called the template and import named scope the same  
 thing.

 Regan


 In this case I assume that you are concerned with conflicts that may be
 generated between both imports of std.stdio in [a.d] and [b.d].


 Nope. In a.d you can call "writefln" but in b.d you must call
 "bar.writefln", plain old writefln will fail, right?
 So, what does this mean for mixins?


 Are you referring to the existing functionality (sans implementation
 bugs) or some specific proposal here.


The proposal to import a module into a namespace. In this case "std.stdio"  
into "bar", meaning "writefln" does not exist but "bar.writefln" does.


 IMO Tyro is right and plain old
 writefln definitely shouldn't fail here. It should only fail when
 std.stdio has been imported privately in file a.d. But if import were
 private by default, then the compiler would say 'b.d(5): undefined
 identifier writefln'.


All I was really asking was...

If module a.d imports "std.stdio" into the current namespace, then calls  
"writefln" in a template which is then mixed into another source file b.d,  
which imports "std.stdio" into a named namespace "bar", can that template  
call "writefln"?

I suspect the answer would have to be "no". After all the mixin is mixed  
into the scope of b.d, it doesn't exist in the scope of a.d where  
"writefln" is valid.

All I was really trying to do was raise this as an issue which would occur  
(and need a solution) if we had import into namespace 'x'.

Regan


As I understand it, anything imported into the global scope (public import) of
[a.d] will be available in any other module that imports it. Unless of course,
Walter has finally decided to do the right thing and make imports private by
default! In the event he has, then the correct and desired result (for me

undefine".

Just in case that doesn't make any sense, let me try it a another way: By
importing [a.d] into [b.d] and by virtue of std.stdio being publicly imported
into [a.d], you have also imported std.stdio into [b.d]. If imports are made
private by default or if explicitly imported privately, then an error message
similar to the one suggested earlier is expected.

I hope that makes sense!

Andrew C. Edwards
Jul 11 2006
next sibling parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Tyro wrote:

 Just in case that doesn't make any sense, let me try it a another way: By
 importing [a.d] into [b.d] and by virtue of std.stdio being publicly imported
 into [a.d], you have also imported std.stdio into [b.d]. If imports are made
 private by default or if explicitly imported privately, then an error message
 similar to the one suggested earlier is expected.


Exactly.

As a side note: I just installed dmd 0.162 and it seems imports have
been finally fixed. Now private imports and private members really are
private, yay! This means that private members are not accessible, but
they are visible to the unprivileged modules. Private imports are not
visible nor accessible. Yes, this is how it really should work. Even
diamond shaped import constructions work according to my simple test
suite. Simply excellent! Thank you Walter!

-- 
Jari-Matti
Jul 11 2006
parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Wed, 12 Jul 2006 02:37:00 +0300, Jari-Matti Mäkelä wrote:


 Tyro wrote:

 Just in case that doesn't make any sense, let me try it a another way: By
 importing [a.d] into [b.d] and by virtue of std.stdio being publicly imported
 into [a.d], you have also imported std.stdio into [b.d]. If imports are made
 private by default or if explicitly imported privately, then an error message
 similar to the one suggested earlier is expected.


 Exactly.
 
 As a side note: I just installed dmd 0.162 and it seems imports have
 been finally fixed. Now private imports and private members really are
 private, yay! This means that private members are not accessible, but
 they are visible to the unprivileged modules. Private imports are not
 visible nor accessible. Yes, this is how it really should work. Even
 diamond shaped import constructions work according to my simple test
 suite. Simply excellent! Thank you Walter!


Almost anyway... 
(1) FQN usage incorrectly overrides 'private'.

Consider these five files ...

 // ---- aaa.d -----
 private int foo() { return 1; }

 // ---- bbb.d ----
 private import aaa;
 private int bar() { return 2; }

 // ---- ccc.d ----
 private int foo() { return 3; }

 // ---- ddd.d ----
 private import ccc;
 private int bar() { return 4; }

 // ---- eee.d ----
 import bbb;
 import ddd;
 import std.stdio;
 void main()
 {
    writefln("aaa.foo %s", aaa.foo());
    writefln("bbb.bar %s", bbb.bar());
    writefln("ccc.foo %s", ccc.foo());
    writefln("ddd.bar %s", ddd.bar());
 }

This compiles fine and when run I get ...

 aaa.foo 1
 bbb.bar 2
 ccc.foo 3
 ddd.bar 4

(2) The error message given when not using FQN is not very helpful.

Change the eee.d file to ...
 // ---- eee.d ----
 import bbb;
 import ddd;
 import std.stdio;
 void main()
 {
    writefln("bar %s", bar());
 }

And the compiler gives this message ...

 bbb.d(3): function bbb.bar conflicts with ddd.bar at ddd.d(3)
 eee.d: module eee bbb.bar is private

The problems with this message are that it doesn't give the line number in
eee.d that triggered the message, and that it exposes 'private' stuff to
the coder. A better message might be along the lines of ...

 eee.d(6): No accessible function 'bar' was found.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
12/07/2006 10:02:30 AM
Jul 11 2006
parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Derek Parnell wrote:

 On Wed, 12 Jul 2006 02:37:00 +0300, Jari-Matti Mäkelä wrote:

 As a side note: I just installed dmd 0.162 and it seems imports have
 been finally fixed. Now private imports and private members really are
 private, yay! This means that private members are not accessible, but
 they are visible to the unprivileged modules. Private imports are not
 visible nor accessible. Yes, this is how it really should work. Even
 diamond shaped import constructions work according to my simple test
 suite. Simply excellent! Thank you Walter!


 
 Almost anyway... 
 (1) FQN usage incorrectly overrides 'private'.
 


Yeah, I noticed it after playing with imports for a while.

 
 (2) The error message given when not using FQN is not very helpful.


No, but it finally works. A step in the right direction. ;)


 
 Change the eee.d file to ...
  // ---- eee.d ----
  import bbb;
  import ddd;
  import std.stdio;
  void main()
  {
     writefln("bar %s", bar());
  }
 
 And the compiler gives this message ...
 
  bbb.d(3): function bbb.bar conflicts with ddd.bar at ddd.d(3)
  eee.d: module eee bbb.bar is private
 
 The problems with this message are that it doesn't give the line number in
 eee.d that triggered the message, and that it exposes 'private' stuff to
 the coder.


Yeah, this is a bit funny one. :)


 A better message might be along the lines of ...
 
  eee.d(6): No accessible function 'bar' was found.


Yes. Personally I would also like to know possible matches to the
function call. Usually I start with everything as private as possible
and widen the visibility, when problems like this occur.

-- 
Jari-Matti
Jul 11 2006
prev sibling parent "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 11 Jul 2006 23:10:38 +0000 (UTC), Tyro <Tyro_member pathlink.com>  
wrote:

 In article <optcjo9wna23k2f5 nrage>, Regan Heath says...

 On Tue, 11 Jul 2006 23:46:03 +0300, Jari-Matti Mäkel�E
 <jmjmak utu.fi.invalid> wrote:

 Regan Heath wrote:

 On Mon, 10 Jul 2006 05:37:41 +0000 (UTC), Tyro
 <Tyro_member pathlink.com> wrote:

 In article <optcgh6iaa23k2f5 nrage>, Regan Heath says...

 --[a.d]--
 import std.stdio;
 template foo { writefln("Hello World"); }

 --[b.d]--
 import std.stdio as bar;
 import a;

 void main() {
   mixin foo;
 }

 I accidently called the template and import named scope the same
 thing.

 Regan


 In this case I assume that you are concerned with conflicts that may  
 be
 generated between both imports of std.stdio in [a.d] and [b.d].


 Nope. In a.d you can call "writefln" but in b.d you must call
 "bar.writefln", plain old writefln will fail, right?
 So, what does this mean for mixins?


 Are you referring to the existing functionality (sans implementation
 bugs) or some specific proposal here.


 The proposal to import a module into a namespace. In this case  
 "std.stdio"
 into "bar", meaning "writefln" does not exist but "bar.writefln" does.


 IMO Tyro is right and plain old
 writefln definitely shouldn't fail here. It should only fail when
 std.stdio has been imported privately in file a.d. But if import were
 private by default, then the compiler would say 'b.d(5): undefined
 identifier writefln'.


 All I was really asking was...

 If module a.d imports "std.stdio" into the current namespace, then calls
 "writefln" in a template which is then mixed into another source file  
 b.d,
 which imports "std.stdio" into a named namespace "bar", can that  
 template
 call "writefln"?

 I suspect the answer would have to be "no". After all the mixin is mixed
 into the scope of b.d, it doesn't exist in the scope of a.d where
 "writefln" is valid.

 All I was really trying to do was raise this as an issue which would  
 occur
 (and need a solution) if we had import into namespace 'x'.

 Regan


 As I understand it, anything imported into the global scope (public  
 import) of
 [a.d] will be available in any other module that imports it. Unless of  
 course,
 Walter has finally decided to do the right thing and make imports  
 private by
 default! In the event he has, then the correct and desired result (for me
 anyway) would be to get an error message stating: "writefln, mixed in on  

 undefine".

 Just in case that doesn't make any sense, let me try it a another way: By
 importing [a.d] into [b.d] and by virtue of std.stdio being publicly  
 imported
 into [a.d], you have also imported std.stdio into [b.d]. If imports are  
 made
 private by default or if explicitly imported privately, then an error  
 message
 similar to the one suggested earlier is expected.

 I hope that makes sense!


Yeah, I was assuming imports were private .. again .. I really wish they  
were.

Regan
Jul 11 2006
prev sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Mon, 10 Jul 2006 11:04:39 +1200, Regan Heath wrote:


 Sub-thread for discussions


What are the problems that this discussion is trying to solve?

I submit these problems:

Problem A: How does one write code to tell readers of source code (people
and IDEs) which module a referred to member exists in?

  Example:
      import aaa;
      import bbb;
      ...
      funcA(); // Is this in aaa, bbb, or the current module?

Problem B: How does one disambiguate identically named accessible members
that happen to be in the same scope and whose signatures match?

      import aaa;
      import bbb;
      ...
      funcB(); // Is this calling the funcB in aaa, or the one in bbb?

Problem C: How does one force the use of Fully Qualified Name references?

There exists in the current D, techniques to solve problems A and B, but
not C. 

One can use a simple Fully Qualified Name syntax or the alias syntax to
resolve (A) and (B).

      import aaa;
      import bbb;
      aaa.funcA();
      bbb.funcB();

or

      import aaa;
      import bbb;
      alias aaa.funcA funcA;
      alias bbb.funcB funcBb;
      alias aaa.funcB funcBa;
      ...
      funcA;
      funcBb();

But why would these solutions need improving?

I think it is because they are not efficient from a code writer and
reader's point of view. If one is forced to always use FQN, it increases
the burden on coders and readers because there are more characters to
process and much of those are redundant. The alias technique is a partial
solution as it significantly reduces clutter, but it is still not optimal
because it causes a redundant typing and reading to be done, and has the
potential to increase maintenance costs if the alias and import statements
are separated in the source code.

A better syntax would remove redundancy and localize the declarations for
easier maintenance. Additional constraints would be to minimize the
introduction of new keywords so as to avoid clashing with existing source
code, and to permit backward compatibility for existing programs.

      import in std.string 
              split, 
              find alias find_str;
      import in bbb 
              find alias find_re;
      ...
      split(. . .);
      find_re(. . .);

The "in" keyword would signal to the compiler that restricts imported names
to only the list of members named after the module, and thus all other
public members in the module are not allowed to be accessed. The "alias"
keyword gives the imported member a new identity within the current module.

In order to force the use of FQN, an additional qualifier, or form of the
import statement, is required because this is independent of the restricted
importing concept. 

 static import std.string; // All references must use FQN.
 static import in std.regexp find; // Only 'find' is imported and needs a
FQN.
 static import in std.stdio writefln alias print; 

 . . .
 std.string.find( . . . );  // okay
 std.regexp.find( . . . );  // okay
 std.regexp.replace(. . .); // not okay (name not imported).
 std.stdio.print(. . .);  // okay
 print(. . .) // not okay as static import requested.


The "static" keyword (yes I know ... another overloading ... sigh) tells
the compiler that the names (and any aliases) in the imported module are
fixed (static) and must be referenced via a FQN.

A possible further optimization to support FQN would be to allow an alias
for the *package.module* name as a whole to allow easier maintenance.

 static import std.string alias s;
 import std.regexp alias r;

 s.replace( . . . );
 r.replace( . . . );


All these forms could be used in conjunction with each other and with
existing code.

IMPORT :: [static] import MODULENAMELIST;
MODULENAMELIST :: IMPORTMODULE [, MODULENAMELIST]
IMPORTMODULE :: [in] MODULENAME [alias ID] [MEMBERLIST]
MEMBERLIST :: IMPORTMEMBER [, MEMBERLIST]
IMPORTMEMBER:: ID [alias ID]


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
10/07/2006 12:33:51 PM
Jul 09 2006
parent Rémy Mouëza <ray.jay.ay.moueza DoNtSpAm.gmail.com> writes:
In article <iq7sr366x54o$.11elk5mgt7qt0$.dlg 40tude.net>, Derek Parnell says...

On Mon, 10 Jul 2006 11:04:39 +1200, Regan Heath wrote:


 Sub-thread for discussions


What are the problems that this discussion is trying to solve?

I submit these problems:

Problem A: How does one write code to tell readers of source code (people
and IDEs) which module a referred to member exists in?

  Example:
      import aaa;
      import bbb;
      ...
      funcA(); // Is this in aaa, bbb, or the current module?

Problem B: How does one disambiguate identically named accessible members
that happen to be in the same scope and whose signatures match?

      import aaa;
      import bbb;
      ...
      funcB(); // Is this calling the funcB in aaa, or the one in bbb?

Problem C: How does one force the use of Fully Qualified Name references?

There exists in the current D, techniques to solve problems A and B, but
not C. 

One can use a simple Fully Qualified Name syntax or the alias syntax to
resolve (A) and (B).

      import aaa;
      import bbb;
      aaa.funcA();
      bbb.funcB();

or

      import aaa;
      import bbb;
      alias aaa.funcA funcA;
      alias bbb.funcB funcBb;
      alias aaa.funcB funcBa;
      ...
      funcA;
      funcBb();

But why would these solutions need improving?

I think it is because they are not efficient from a code writer and
reader's point of view. If one is forced to always use FQN, it increases
the burden on coders and readers because there are more characters to
process and much of those are redundant. The alias technique is a partial
solution as it significantly reduces clutter, but it is still not optimal
because it causes a redundant typing and reading to be done, and has the
potential to increase maintenance costs if the alias and import statements
are separated in the source code.

A better syntax would remove redundancy and localize the declarations for
easier maintenance. Additional constraints would be to minimize the
introduction of new keywords so as to avoid clashing with existing source
code, and to permit backward compatibility for existing programs.

      import in std.string 
              split, 
              find alias find_str;
      import in bbb 
              find alias find_re;
      ...
      split(. . .);
      find_re(. . .);

The "in" keyword would signal to the compiler that restricts imported names
to only the list of members named after the module, and thus all other
public members in the module are not allowed to be accessed. The "alias"
keyword gives the imported member a new identity within the current module.

In order to force the use of FQN, an additional qualifier, or form of the
import statement, is required because this is independent of the restricted
importing concept. 

 static import std.string; // All references must use FQN.
 static import in std.regexp find; // Only 'find' is imported and needs a
FQN.
 static import in std.stdio writefln alias print; 

 . . .
 std.string.find( . . . );  // okay
 std.regexp.find( . . . );  // okay
 std.regexp.replace(. . .); // not okay (name not imported).
 std.stdio.print(. . .);  // okay
 print(. . .) // not okay as static import requested.


The "static" keyword (yes I know ... another overloading ... sigh) tells
the compiler that the names (and any aliases) in the imported module are
fixed (static) and must be referenced via a FQN.

A possible further optimization to support FQN would be to allow an alias
for the *package.module* name as a whole to allow easier maintenance.

 static import std.string alias s;
 import std.regexp alias r;

 s.replace( . . . );
 r.replace( . . . );


All these forms could be used in conjunction with each other and with
existing code.

IMPORT :: [static] import MODULENAMELIST;
MODULENAMELIST :: IMPORTMODULE [, MODULENAMELIST]
IMPORTMODULE :: [in] MODULENAME [alias ID] [MEMBERLIST]
MEMBERLIST :: IMPORTMEMBER [, MEMBERLIST]
IMPORTMEMBER:: ID [alias ID]


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
10/07/2006 12:33:51 PM


This idea is very close to what Python do. I like it. It seems readable,
understandable and looks like D code. 

      import in std.string 
              split, 
              find alias find_str;
      import in bbb 
              find alias find_re;


In Python one would write :
from std.string import split, find as find_str
from bbb import find as find_re

Fully qualified name is the default in Python. If one want to import all the
symbols of a module :
from a.module import *
That is not considered as a best practice. 

Derek's proposal would make FQN as optional. If we prefer to make FQN mandatory,
we will have to find something to express the import of all the symbol of a
module, a kind of shortcut.
Justin (jcc7) idea of replacing alias with = is also interesting. 
There was also a proposal to use the 'with' keyword...

Ok. So here is my new mix of ideas : 
1) Fully Qualified Name is the default. 
2) Change the keywords a little bit :
import my.package.module ; // The symbols of this package have to be fully
qualified.
import with std.string  split, find = find_str ; // Nothing new,
import with std.regexp find = find_re ; // keyword have just changed.
Or we can keep the alias keyword :
import with std.string  split, find alias find_str ;
import with std.regexp find alias find_re ;
3) Allow the import of all the symbol of a module in the current namespace.
import with std.stdio in this ; 

In brief, nothing new except the FQN is mandatory. One have to import all the
symbols of a module in the current namespace to get the import behaviour we
currently have.
Jul 10 2006
prev sibling next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
Sub-thread for ideas.
Jul 09 2006
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
This idea is broken into parts, other people might like to reference these  
parts in discussion or in their own ideas i.e. "using Regan's Part-A and  
.." etc.

--

Part-A:
import this.is.the.lib;

This imports all symbols from this.is.the.lib into the current scope. No  
changes to current import behaviour here. I have an alternate idea, not  
sure what people might think of this as it breaks all/most existing code  
but..

--

Alt-A:
import this.is.the.lib;
import this.is.the.lib as .;

So, import defaults to FQN and 'as' (properly introduced in Part-B below)  
must be used to import into the current scope (which is named '.')

--

Part-B:
import this.is.the.lib as x;

This imports all symbols from this.is.the.lib into named scope 'x'

--

Part-C:
import this.is.the.lib.copyFile,saveFile,deleteFile;

This imports the named symbols copyFile, saveFile, and deleteFile from  
this.is.the.lib into the current scope. The lib name is mentioned only  
once and therefore only one lib may be present in the import statement.

This idea may conflict with the current statement:
   import this.is.a.lib,this.is.another.lib;

which I've notice people use (but don't use personally).

The compiler can tell these apart by realising that the first part of the  
import denotes a symbol in a module, as opposed to a module itself. Then  
we have to ask ourselves, what if a module is later created by the name  
this.is.the.lib.copyFile .. I don't know, this is perhaps the most  
contrary part of my idea.

The advantage I see to this is that it only imports the symbols you want  
and to add a symbol you just add "," and the symbol name to the same line.  
So, it keeps the symbols from the same module together on one  
line/statement (which seems to me to be what people dislike about alias?)  
and does not involve needlessly repeating the module name.

--

Alt-C:
import this.is.the.lib.copyFile,saveFile,deleteFile;

This would import as FQN and not into the current scope (without use of  
'as .' as shown in Part-D below).

--

Part-D:
import this.is.the.lib.copyFile,saveFile,deleteFile as x;

This imports the named symbols copyFile, saveFile, and deleteFile from  
this.is.the.lib into the named scope 'x'.

--

Part-E: (extension of Part-B)
import this.is.the.lib as this.is.the.lib;

This imports all the symbols from this.is.the.lib into the named scope  
'this.is.the.lib' .. or in other words, this is an FQN import. My  
impression is that most people would rather not have FQN as the default,  
but do want it to be possible. My impression is that applying 'static' to  
import to achieve FQN import is disliked (I certainly dislike it). This  
seems a good compromise.

--

The complete idea/system combines all these parts. The "Alt" parts break  
existing code, the others shouldn't. The reasons for not simply using  
alias have been well hashed out already, from what I can see it's a  
maintenance and aesthetic request, as opposed to a truly functional  
improvement but that's reason enough for me to desire a change.

Regan
Jul 09 2006
parent "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
Regan Heath wrote:


 Part-E
 import this.is.the.lib as this.is.the.lib;


I don't like this syntax. Retyping the same things twice is not a good idea.
It's syntactic overhead.

FQN import is common and it should be simple, so previous proposals like
"static import" and "fqnimport" seem more appealing to me (though I would
personally prefer "using" keyword).


-- 
AKhropov
Jul 10 2006
prev sibling next sibling parent reply jcc7 <jcc7_member pathlink.com> writes:
In article <optcf2eoqc23k2f5 nrage>, Regan Heath says...

Sub-thread for ideas.


I'm not thrilled about the prospect of reusing static for yet another purpose,
but I don't think that we need to add "from" or "as" to the keyword list either.

Instead of 
"import fooTooLong.reallyTooLong as fooShort;"

we could re-use an operator:
"import fooTooLong.reallyTooLong = fooShort;"

I like it, but it could just be me.

I think someone else suggested this already, but I like it, too:
"import fooTooLong.reallyTooLong alias fooShort;"

Now, I'm really brainstorming...

Or one of these might work:
"import fooTooLong.reallyTooLong fooShort;" (no keyword needed at all)
"import fooTooLong.reallyTooLong for fooShort;"
"import fooTooLong.reallyTooLong out fooShort;"
"import fooTooLong.reallyTooLong in fooShort;"


Or maybe even use one of these to force FQN (static is already used for enough
different things):
"import final fooTooLong.reallyTooLong;"
"import do fooTooLong.reallyTooLong;"
"import void fooTooLong.reallyTooLong;"


Just throwing out ideas...

jcc7
Jul 10 2006
parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
jcc7 wrote:

 In article <optcf2eoqc23k2f5 nrage>, Regan Heath says...
 

Sub-thread for ideas.


 
 
 I'm not thrilled about the prospect of reusing static for yet another purpose,
 but I don't think that we need to add "from" or "as" to the keyword list
either.
 
 Instead of 
 "import fooTooLong.reallyTooLong as fooShort;"
 
 we could re-use an operator:
 "import fooTooLong.reallyTooLong = fooShort;"
 
 I like it, but it could just be me.


I think its a pretty neat idea, actually.  Although, maybe it should be the
colon instead?




 I think someone else suggested this already, but I like it, too:
 "import fooTooLong.reallyTooLong alias fooShort;"


The placement of the 'alias' keyword throws me off pretty bad...  I can't help
thinking it 
should be somewhere at the beginning, but then I don't like whitespace in my
'import' 
statement either.  I'm too picky!


 Now, I'm really brainstorming...
 
 Or one of these might work:
 "import fooTooLong.reallyTooLong fooShort;" (no keyword needed at all)
 "import fooTooLong.reallyTooLong for fooShort;"
 "import fooTooLong.reallyTooLong out fooShort;"
 "import fooTooLong.reallyTooLong in fooShort;"


The 'in' case makes some sense, but the other ones... erm...


 
 Or maybe even use one of these to force FQN (static is already used for enough
 different things):
 "import final fooTooLong.reallyTooLong;"
 "import do fooTooLong.reallyTooLong;"
 "import void fooTooLong.reallyTooLong;"


Do? Do?? Do?!  ;)  Why not 'default'?  Or 'typedef'?  (Actually, that'd be
cute.)

I still think we need something like an 'fqn' keyword to accomplish this.  Or
possibly the 
elsewhere-proposed 'fqnimport' statement.

-- Chris Nicholson-Sauls
Jul 10 2006
parent reply jcc7 <jcc7_member pathlink.com> writes:
In article <e8u2s1$1li1$1 digitaldaemon.com>, Chris Nicholson-Sauls says...

jcc7 wrote:

 In article <optcf2eoqc23k2f5 nrage>, Regan Heath says...
 

Sub-thread for ideas.


 
 
 I'm not thrilled about the prospect of reusing static for yet another purpose,
 but I don't think that we need to add "from" or "as" to the keyword list
either.
 
 Instead of 
 "import fooTooLong.reallyTooLong as fooShort;"
 
 we could re-use an operator:
 "import fooTooLong.reallyTooLong = fooShort;"
 
 I like it, but it could just be me.


I think its a pretty neat idea, actually.  Although, maybe it should be the
colon instead?


I thought about colon, but people will probably want to do things like this and
I think the colon meaning could get confusing:

With equal symbol...

public:
import fooTooLong.reallyTooLong = fooShort;
import fooTooLong.reallyTooLong2 = fooShort2;


With colon symbol...

public:
import fooTooLong.reallyTooLong : fooShort;
import fooTooLong.reallyTooLong2 : fooShort2;


Okay, now that I look at it, I think it'd work fine.

..

 "import final fooTooLong.reallyTooLong;"
 "import do fooTooLong.reallyTooLong;"
 "import void fooTooLong.reallyTooLong;"


Do? Do?? Do?!  ;)  Why not 'default'?  Or 'typedef'?  (Actually, that'd be
cute.)


I know I'm grasping at straws. At this point, D has plenty of keywords, so I'm
trying to encourage recycling. ;)



I still think we need something like an 'fqn' keyword to accomplish this.  Or
possibly the 
elsewhere-proposed 'fqnimport' statement.


We could do that, but "fqn" and "fqnimport" look very ugly to me. I'm sure we
can find something more elegant than that that makes more sense than "switch
import".

jcc7
Jul 10 2006
parent reply Anders Runesson <anders runesson.info> writes:
m=C3=A5n 2006-07-10 klockan 18:26 +0000 skrev jcc7:

 In article <e8u2s1$1li1$1 digitaldaemon.com>, Chris Nicholson-Sauls says.=


..

jcc7 wrote:

 In article <optcf2eoqc23k2f5 nrage>, Regan Heath says...
=20

Sub-thread for ideas.


=20
=20
 I'm not thrilled about the prospect of reusing static for yet another =






purpose,

 but I don't think that we need to add "from" or "as" to the keyword li=






st either.

=20
 Instead of=20
 "import fooTooLong.reallyTooLong as fooShort;"
=20
 we could re-use an operator:
 "import fooTooLong.reallyTooLong =3D fooShort;"
=20
 I like it, but it could just be me.


I think its a pretty neat idea, actually.  Although, maybe it should be =




the colon instead?

=20
 I thought about colon, but people will probably want to do things like th=


is and

 I think the colon meaning could get confusing:
=20
 With equal symbol...
=20
 public:
 import fooTooLong.reallyTooLong =3D fooShort;
 import fooTooLong.reallyTooLong2 =3D fooShort2;
=20
=20
 With colon symbol...
=20
 public:
 import fooTooLong.reallyTooLong : fooShort;
 import fooTooLong.reallyTooLong2 : fooShort2;


perhaps something like this:=20

import fooTooLong {
	reallyTooLong: tooShort,    /* alias */
	reallyTooLong2: tooShort2,  /* alias 2
	notReallyTooLongAtAll       /* No alias */
}

to make several aliases from the same module? My 2c.

/Anders
Jul 12 2006
parent reply BCS <BCS pathlink.com> writes:
Anders Runesson wrote:

 mån 2006-07-10 klockan 18:26 +0000 skrev jcc7:
 

In article <e8u2s1$1li1$1 digitaldaemon.com>, Chris Nicholson-Sauls says...


jcc7 wrote:


In article <optcf2eoqc23k2f5 nrage>, Regan Heath says...



Sub-thread for ideas.



I'm not thrilled about the prospect of reusing static for yet another purpose,
but I don't think that we need to add "from" or "as" to the keyword list either.

Instead of 
"import fooTooLong.reallyTooLong as fooShort;"

we could re-use an operator:
"import fooTooLong.reallyTooLong = fooShort;"

I like it, but it could just be me.


I think its a pretty neat idea, actually.  Although, maybe it should be the
colon instead?


I thought about colon, but people will probably want to do things like this and
I think the colon meaning could get confusing:

With equal symbol...

public:
import fooTooLong.reallyTooLong = fooShort;
import fooTooLong.reallyTooLong2 = fooShort2;


With colon symbol...

public:
import fooTooLong.reallyTooLong : fooShort;
import fooTooLong.reallyTooLong2 : fooShort2;


 
 
 perhaps something like this: 
 
 import fooTooLong {
 	reallyTooLong: tooShort,    /* alias */
 	reallyTooLong2: tooShort2,  /* alias 2
 	notReallyTooLongAtAll       /* No alias */
 }
 
 to make several aliases from the same module? My 2c.
 
 /Anders
 


I was thinking about that kind of thing my self. Seems logical. Some 
variations might be considered.

drop the import all together, (we aren't really importing "fooTooLong" 
after all, just some stuff in it):

with(fooTooLong)
{
    alias reallyTooLong tooShort;    /* alias */
    alias reallyTooLong2 tooShort2;  /* alias 2 */
    alias notReallyTooLongAtAll notReallyTooLongAtAll; /* No alias */
}

(only "with" at global scope so should parse)

Some hybrid of the two might look nice also.
Jul 12 2006
parent reply jcc7 <jcc7_member pathlink.com> writes:
In article <e938po$1cn1$1 digitaldaemon.com>, BCS says...

Anders Runesson wrote:

 mån 2006-07-10 klockan 18:26 +0000 skrev jcc7:
 

In article <e8u2s1$1li1$1 digitaldaemon.com>, Chris Nicholson-Sauls says...


jcc7 wrote:


In article <optcf2eoqc23k2f5 nrage>, Regan Heath says...



Sub-thread for ideas.



I'm not thrilled about the prospect of reusing static for yet another purpose,
but I don't think that we need to add "from" or "as" to the keyword list either.

Instead of 
"import fooTooLong.reallyTooLong as fooShort;"

we could re-use an operator:
"import fooTooLong.reallyTooLong = fooShort;"

I like it, but it could just be me.


I think its a pretty neat idea, actually.  Although, maybe it should be the
colon instead?


I thought about colon, but people will probably want to do things like this and
I think the colon meaning could get confusing:

With equal symbol...

public:
import fooTooLong.reallyTooLong = fooShort;
import fooTooLong.reallyTooLong2 = fooShort2;


With colon symbol...

public:
import fooTooLong.reallyTooLong : fooShort;
import fooTooLong.reallyTooLong2 : fooShort2;


 
 
 perhaps something like this: 
 
 import fooTooLong {
 	reallyTooLong: tooShort,    /* alias */
 	reallyTooLong2: tooShort2,  /* alias 2
 	notReallyTooLongAtAll       /* No alias */
 }
 
 to make several aliases from the same module? My 2c.
 
 /Anders
 


I was thinking about that kind of thing my self. Seems logical. Some 
variations might be considered.

drop the import all together, (we aren't really importing "fooTooLong" 
after all, just some stuff in it):

with(fooTooLong)
{
    alias reallyTooLong tooShort;    /* alias */
    alias reallyTooLong2 tooShort2;  /* alias 2 */
    alias notReallyTooLongAtAll notReallyTooLongAtAll; /* No alias */
}

(only "with" at global scope so should parse)

Some hybrid of the two might look nice also.


I'm just not a big fan of using with for this since it seems like importing to
me.

"with(module fooTooLong)" would be somewhat better, but I think "import" should
be there. How about this?








or if you just want to import one it'd be something like this:

import select std.string.replace alias replace;

or maybe even this if it's not being renamed...

import select std.string.replace;

I think there's a really good syntax in here somewhere. I'm just not sure what
it is yet...

jcc7
Jul 12 2006
parent reply BCS <BCS pathlink.com> writes:
jcc7 wrote:

 
 
 I'm just not a big fan of using with for this since it seems like importing to
 me.
 
 "with(module fooTooLong)" would be somewhat better, but I think "import" should
 be there. How about this?
 






 
 or if you just want to import one it'd be something like this:
 
 import select std.string.replace alias replace;
 
 or maybe even this if it's not being renamed...
 
 import select std.string.replace;
 
 I think there's a really good syntax in here somewhere. I'm just not sure what
 it is yet...
 
 jcc7


Yeah, that "with" doesn't look to good. OTOH that "select" looks kind of 
funny also. I think just switching to the "alias <name> [<name>];" 
syntax would be best. IIRC all {} block use ";" as a separator, so it 
would be more consistent than a comma separated list.
Jul 12 2006
parent reply Anders Runesson <anders runesson.info> writes:
ons 2006-07-12 klockan 10:25 -0700 skrev BCS:

 jcc7 wrote:

 
 
 I'm just not a big fan of using with for this since it seems like importing to
 me.
 
 "with(module fooTooLong)" would be somewhat better, but I think "import" should
 be there. How about this?
 









Seems redundant to have to type "notReallyTooLongAtAll" twice though.
Just declaring which symbols you are interested in should be enough,
with the option of declaring aliases at the same time for convenience.

Also, I don't see the point of adding a keyword like "select" in all of
it. I think it is pretty clear whats going on if import is followed by a
block as opposed to just a module path and name:
import mypackage.mymodule;
where the whole module is imported.



 
 or if you just want to import one it'd be something like this:
 
 import select std.string.replace alias replace;
 
 or maybe even this if it's not being renamed...
 
 import select std.string.replace;
 
 I think there's a really good syntax in here somewhere. I'm just not sure what
 it is yet...
 
 jcc7


 
 Yeah, that "with" doesn't look to good. OTOH that "select" looks kind of 
 funny also. I think just switching to the "alias <name> [<name>];" 
 syntax would be best. IIRC all {} block use ";" as a separator, so it 
 would be more consistent than a comma separated list.


Well, enums use commas. I think an import block somehow seems more
related to an enum than, say, a struct. It is just a declaration of
names/symbols, not types.

/Anders
Jul 12 2006
parent jcc7 <jcc7_member pathlink.com> writes:
In article <1152731324.8336.9.camel localhost>, Anders Runesson says...

ons 2006-07-12 klockan 10:25 -0700 skrev BCS:

 jcc7 wrote:

 
 
 I'm just not a big fan of using with for this since it seems like importing to
 me.
 
 "with(module fooTooLong)" would be somewhat better, but I think "import" should
 be there. How about this?
 









Seems redundant to have to type "notReallyTooLongAtAll" twice though.
Just declaring which symbols you are interested in should be enough,
with the option of declaring aliases at the same time for convenience.

Also, I don't see the point of adding a keyword like "select" in all of
it. 


Oops. I've been looking at too much Visual Basic code. I was thinking that
"select" was already a keyword in D. And "switch" doesn't sound right at all.
Oh, well. I guess we don't need a keyword there.

jcc7
Jul 12 2006
prev sibling next sibling parent Dave <Dave_member pathlink.com> writes:
Regan Heath wrote:

 Sub-thread for ideas.


My preference for syntax and semantics would be:

// regular import w/ optional alias (*, ***)
import std.stdio, std.c.stdlib as stdlib, std.date;

// symbol specific import w/ optional alias (**, ***)
import from std.stdio writef, writefln as print, readf;

// combined (***)
import std.stdio, from std.thread wait as wait, pause, std.date as date;

* Importing an entire module as an alias would then require a FQN to 
access any of the members, for example given the above:
malloc(...); // error
std.c.stdlib.malloc(...); // error
stdlib.malloc(...); // Ok

** A specific symbol that was not aliased would require a FQN to access. 
For example from above:
std.stdio.writef(...);

*** In any case, 'private import' would function as it does now.

This is all heavily based on the ideas of others and a summation of my 
understanding of the relevant threads.

Thanks,

- Dave
Jul 10 2006
prev sibling parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
2 comments:

Dave skrev:

 Regan Heath wrote:

 Sub-thread for ideas.


 
 My preference for syntax and semantics would be:
 
 // regular import w/ optional alias (*)
 import std.stdio, std.c.stdlib as stdlib, std.date;
 
 // symbol specific lookup w/ optional alias (**)
 import from std.stdio writef, writefln as print, readf;


How would the parser disambiguate the import of the module readf from 
the symbol readf in std.stdio?


 // combined
 import std.stdio, from std.thread wait as wait, pause, std.date as date;
 
 * Importing an entire module as an alias would then require a FQN to 
 access any of the members, for example given the above:
 malloc(...); // error
 std.c.stdlib.malloc(...); // error
 stdlib.malloc(...); // Ok
 
 ** A specific symbol that was not aliased would require a FQN to access. 
 For example from above:
 std.stdio.writef(...);


Just to clarify, does this mean that to import std.c.stdlib as FQN only, 
you would have to do:

import std.c.stdlib as std.c.stdlib; //(1)

Or, indirectly:

import from std.c.stdlib a_symbol_I_will_never_use;

?

1) When you import something as fqn-only, you must be ok with typing out 
the full name quite a lot, so once more will not make much of a 
difference I guess...

/Oskar
Jul 10 2006
parent Dave <Dave_member pathlink.com> writes:
Oskar Linde wrote:

 2 comments:
 
 Dave skrev:

 Regan Heath wrote:

 Sub-thread for ideas.


 My preference for syntax and semantics would be:

 // regular import w/ optional alias (*)
 import std.stdio, std.c.stdlib as stdlib, std.date;

 // symbol specific lookup w/ optional alias (**)
 import from std.stdio writef, writefln as print, readf;


 
 How would the parser disambiguate the import of the module readf from 
 the symbol readf in std.stdio?


Great questions <g>

Assuming just the import from above, it wouldn't have to. Assuming 
std.stdio was imported in toto somwhere else, I would say that the 
specific import would then take precedence.

For example,

import std.stdio;
import std.mystdio; // also contains implements writefln
import from std.stdio writefln;
void main()
{
writefln("Always uses writefln from the 3rd import statement.");
std.mystdio.writefln("Unless an FQN is used.");
std.stdio.writefln("Same here.");
}

Because the whole point is to specifically disambiguate the writefln 
from the third import statement.

If the writefln from the 3rd statement was then considered part of the 
current namespace (module) as I believe was mentioned in the original 
threads, then this should not be a problem for the current compiler 
implementation either, because the innermost namespace takes precedence 
for lookup when an FQN is not used and there is a 'conflict'.


 

 // combined
 import std.stdio, from std.thread wait as wait, pause, std.date as date;

 * Importing an entire module as an alias would then require a FQN to 
 access any of the members, for example given the above:
 malloc(...); // error
 std.c.stdlib.malloc(...); // error
 stdlib.malloc(...); // Ok

 ** A specific symbol that was not aliased would require a FQN to 
 access. For example from above:
 std.stdio.writef(...);


 
 Just to clarify, does this mean that to import std.c.stdlib as FQN only, 
 you would have to do:
 
 import std.c.stdlib as std.c.stdlib; //(1)
 


No, that would cause a conflict with the way alias works already because 
you can't:

alias std.c.stdlib std.c.stdlib;

I would say then that the coder would just FQN everything themselves 
(even though it's not required by the compiler) or come up with an alias 
like:

import std.c.stdlib as std_c_stdlib;

I'm trying to make this all implementable with what's aleady in the 
compiler except for how the new import syntax is processed, and be 
backward compatible with the current import statement.


 Or, indirectly:
 
 import from std.c.stdlib a_symbol_I_will_never_use;
 


That would limit the imports from std.c.stdlib to 
'a_symbol_I_will_never_use' (unless other import statements imported 
other symbols from std.c.stdlib of course). So, if the specific symbol 
'a_symbol_I_will_never_use' wasn't ever used, the import statement would 
be superfluous.


 ?
 
 1) When you import something as fqn-only, you must be ok with typing out 
 the full name quite a lot, so once more will not make much of a 
 difference I guess...
 
 /Oskar
Jul 10 2006
prev sibling next sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Regan Heath wrote:

 After reading the entire "Re: import concerns (was Re: Historical 
 language survey)" thread and hearing all the different opinions I 
 thought "we need a single place to put complete ideas" and "people 
 should show support for the idea they like best"
 
 So.. I'd like this thread to be that place. I'm going to post my own 
 idea (in response to this post) and I'd like it if people to post their 
 own ideas (or the ideas of others as they understand them) in complete 
 form. Then I'd like people to show support for an idea that takes their 
 fancy.
 
 This is to give Walter an idea what ideas have community support.
 
 If people want to discuss the ideas, I suggest we start a new thread, or 
 a sub thread of this port specifically for discussion, as opposed to 
 commenting in response to the ideas themselves.
 
 This is generally just an attempt to get the discussion organised and to 
 provide a reference we can refer back to at a later date. I have a 
 threaded news group reader and this'll probably only look organised if 
 you use one too, as opposed to the web interface. If you all think it's 
 a terrible idea, I won't feel too hurt ;)
 
 Regan
 


I agree starting to migrate to a new thread might be useful (if everyone 
adheres to it), since the other is getting way nested! The most nested 
I've ever seen, some of the post are so far to right that no part of the 
title displays already Xp .
But I'm not so sure about dividing this thread into "discuss" and 
"ideas", people want to discuss ideas and proposals, it won't work well 
to divide them I think.

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 09 2006
parent "Regan Heath" <regan netwin.co.nz> writes:
On Mon, 10 Jul 2006 01:53:16 +0100, Bruno Medeiros  
<brunodomedeirosATgmail SPAM.com> wrote:

 Regan Heath wrote:

 After reading the entire "Re: import concerns (was Re: Historical  
 language survey)" thread and hearing all the different opinions I  
 thought "we need a single place to put complete ideas" and "people  
 should show support for the idea they like best"
  So.. I'd like this thread to be that place. I'm going to post my own  
 idea (in response to this post) and I'd like it if people to post their  
 own ideas (or the ideas of others as they understand them) in complete  
 form. Then I'd like people to show support for an idea that takes their  
 fancy.
  This is to give Walter an idea what ideas have community support.
  If people want to discuss the ideas, I suggest we start a new thread,  
 or a sub thread of this port specifically for discussion, as opposed to  
 commenting in response to the ideas themselves.
  This is generally just an attempt to get the discussion organised and  
 to provide a reference we can refer back to at a later date. I have a  
 threaded news group reader and this'll probably only look organised if  
 you use one too, as opposed to the web interface. If you all think it's  
 a terrible idea, I won't feel too hurt ;)
  Regan


 I agree starting to migrate to a new thread might be useful (if everyone  
 adheres to it), since the other is getting way nested! The most nested  
 I've ever seen, some of the post are so far to right that no part of the  
 title displays already Xp .
 But I'm not so sure about dividing this thread into "discuss" and  
 "ideas", people want to discuss ideas and proposals, it won't work well  
 to divide them I think.


My reasoning is that our ideas ideas evolve/change over time and it'd be  
nice if each evolution was right next to the previous evolution.  
Seperating the discussion allows me to post an idea, be conviced by a  
discussion to change some part of it, or even come up with something  
independantly and post my changes in response to my original idea. This  
allows anyone to see at any time my complete idea/picture, something that  
I think often gets lost/confused in the course of a discussion.

That said, I'm happy to do whatever the community wants.. I've already  
posted and idea and opened a discussion on what I think is a contrary  
point in my idea .. we could see how it works and decide then perhaps?

Regan
Jul 09 2006
prev sibling parent "Regan Heath" <regan netwin.co.nz> writes:
I'd just like to make one more thing clear, when I say "my" idea I  
actually mean "your" ideas that I've stolen, thought about and combined  
into something I'm labelling "my" idea for ease of discussion :) So, it's  
only "my" idea in the sense that it's the idea (or bunch of ideas) I would  
use were it up to me.

Regan
Jul 09 2006