This is a question for Walter.  I'm curious about the reason why you have to import a file before using its functions and types.  Why can't you do this:
  int main() {
    std.stdio.printf("Hello world!\n");
    return 0;
  }

I'm thinking here is that the compiler could do this:
  * Search the current namespaces for 'std'
  * Not finding std, look for a directory std/ or a
    file std.d
  * Finding std/ but not std.d, look for a directory
    std/stdio/ or a file std/stdio.d
  * Finding std/stdio.d, it creates an implicit
    import, like this:

  /* implicit */ import std.stdio;
  int main() {
    std.stdio.printf("Hello world!\n");
    return 0;
  }

I'm guessing that there is some good reason for not doing this, but I'm curious what it is?

In article <cfdp94$146p$1@digitaldaemon.com>, Russ Lewis says...
>
>This is a question for Walter.  I'm curious about the reason why you have to import a file before using its functions and types.  Why can't you do this:
>   int main() {
>     std.stdio.printf("Hello world!\n");
>     return 0;
>   }
>
>I'm thinking here is that the compiler could do this:
>   * Search the current namespaces for 'std'
>   * Not finding std, look for a directory std/ or a
>     file std.d
>   * Finding std/ but not std.d, look for a directory
>     std/stdio/ or a file std/stdio.d
>   * Finding std/stdio.d, it creates an implicit
>     import, like this:
>
>   /* implicit */ import std.stdio;
>   int main() {
>     std.stdio.printf("Hello world!\n");
>     return 0;
>   }
>
>I'm guessing that there is some good reason for not doing this, but I'm curious what it is?
>
I'm curious about that myself. If I'm not mistaken, that's how C# does it. In C#, you use imports so that you don't have to write "System.console.print" (I think that's it...), and can just write "print". I'd like to call functions without importing the modules, too, if that can be done.

In article <cfdp94$146p$1@digitaldaemon.com>, Russ Lewis says...
>
>This is a question for Walter.  I'm curious about the reason why you have to import a file before using its functions and types.  Why can't you do this:
>   int main() {
>     std.stdio.printf("Hello world!\n");
>     return 0;
>   }
>
>I'm thinking here is that the compiler could do this:
>   * Search the current namespaces for 'std'
>   * Not finding std, look for a directory std/ or a
>     file std.d
>   * Finding std/ but not std.d, look for a directory
>     std/stdio/ or a file std/stdio.d
>   * Finding std/stdio.d, it creates an implicit
>     import, like this:
>
>   /* implicit */ import std.stdio;
>   int main() {
>     std.stdio.printf("Hello world!\n");
>     return 0;
>   }
>
>I'm guessing that there is some good reason for not doing this, but I'm curious what it is?

That's an interesting idea.

I don't know how difficult it would be for the compiler. It might be trickier than it seems. Even if it's easy for the compiler, I think there are reasons why the compiler shouldn't allow it.


With auto-importing, we might run into a problem where we get more than we expected when we make a silly mistake.

struct aStruct { int b; }
aStruct moc;
void main() { mod.b = 5; }

It's a contrived example, but if you thought "mod" was an aStruct declared in that module (like moc), but there was a module with a variable called "b" in the same directory called "mod.d", you'd would get much different results than you expected. Sounds like things could get messy really quick if you re-use identifiers a lot.

That reasoning is similar to why this isn't allowed:
import std.c.*;


Also, if you have the imports grouped near the top of the file it's easy to determine the dependencies of a particular module.

jcc7

>std.stdio.printf("Hello world!\n");

java allows this too, cause if you have the same class name in two different
imported modules,
how does the compiler resolve that today?

Filip

"J C Calvarese" <jcc7@cox.net> wrote in message news:cfdtrl$16mn$1@digitaldaemon.com...
> In article <cfdp94$146p$1@digitaldaemon.com>, Russ Lewis says...
> >
> >This is a question for Walter.  I'm curious about the reason why you have to import a file before using its functions and types.  Why can't you do this:
> >   int main() {
> >     std.stdio.printf("Hello world!\n");
> >     return 0;
> >   }
> >
> >I'm thinking here is that the compiler could do this:
> >   * Search the current namespaces for 'std'
> >   * Not finding std, look for a directory std/ or a
> >     file std.d
> >   * Finding std/ but not std.d, look for a directory
> >     std/stdio/ or a file std/stdio.d
> >   * Finding std/stdio.d, it creates an implicit
> >     import, like this:
> >
> >   /* implicit */ import std.stdio;
> >   int main() {
> >     std.stdio.printf("Hello world!\n");
> >     return 0;
> >   }
> >
> >I'm guessing that there is some good reason for not doing this, but I'm curious what it is?
>
> That's an interesting idea.
>
> I don't know how difficult it would be for the compiler. It might be
trickier
> than it seems. Even if it's easy for the compiler, I think there are
reasons why
> the compiler shouldn't allow it.
>
>
> With auto-importing, we might run into a problem where we get more than we expected when we make a silly mistake.
>
> struct aStruct { int b; }
> aStruct moc;
> void main() { mod.b = 5; }
>
> It's a contrived example, but if you thought "mod" was an aStruct declared
in
> that module (like moc), but there was a module with a variable called "b"
in the
> same directory called "mod.d", you'd would get much different results than
you
> expected. Sounds like things could get messy really quick if you re-use identifiers a lot.
>
> That reasoning is similar to why this isn't allowed:
> import std.c.*;
>
>
> Also, if you have the imports grouped near the top of the file it's easy
to
> determine the dependencies of a particular module.
>
> jcc7

Russ Lewis wrote:
> This is a question for Walter.  I'm curious about the reason why you have to import a file before using its functions and types.  Why can't you do this:
>   int main() {
>     std.stdio.printf("Hello world!\n");
>     return 0;
>   }
> 
> I'm thinking here is that the compiler could do this:
>   * Search the current namespaces for 'std'
>   * Not finding std, look for a directory std/ or a
>     file std.d
>   * Finding std/ but not std.d, look for a directory
>     std/stdio/ or a file std/stdio.d
>   * Finding std/stdio.d, it creates an implicit
>     import, like this:
> 
>   /* implicit */ import std.stdio;
>   int main() {
>     std.stdio.printf("Hello world!\n");
>     return 0;
>   }
> 
> I'm guessing that there is some good reason for not doing this, but I'm curious what it is?

This is more or less an artifact of the build system.

In the C# world, everything is conceptually in one gigantic namespace, so all public symbols are available all the time.

This is possible because the .NET build system completely internalizes the link phase.  When the compiler is started, every source file and every external DLL is always specified on the spot.  There is no way to do a partial rebuild. (nor is there much need for one: The C# compiler is almost as fast as DMD)

DMD, being built to use the older OMF object format, is able to perform partial builds, but it doesn't necessarily have everything handed to it on the commandline.  Therefore, it needs explicit directions to other source files.

 -- andy

Filip Hanik - Dev wrote:
>>std.stdio.printf("Hello world!\n");
> 
> 
> java allows this too, cause if you have the same class name in two different
> imported modules,
> how does the compiler resolve that today?

In D, you explicitly import both modules and append the module name when you use the function or class.

For example...

import std.string;
import std.date;

d_time d;
int i;

char[] dateStr;
char[] intStr;

void main()
{
    dateStr = std.date.toString(d);
    intStr = std.string.toString(i);
}

The suggestion is that we should be able to leave out the explicit import statements at the top and have it still work.

Does importing in Java work without explicit imports?

> 
> Filip
> 
> "J C Calvarese" <jcc7@cox.net> wrote in message
> news:cfdtrl$16mn$1@digitaldaemon.com...
> 
>>In article <cfdp94$146p$1@digitaldaemon.com>, Russ Lewis says...
>>
>>>This is a question for Walter.  I'm curious about the reason why you
>>>have to import a file before using its functions and types.  Why can't
>>>you do this:
>>>  int main() {
>>>    std.stdio.printf("Hello world!\n");
>>>    return 0;
>>>  }
>>>
>>>I'm thinking here is that the compiler could do this:
>>>  * Search the current namespaces for 'std'
>>>  * Not finding std, look for a directory std/ or a
>>>    file std.d
>>>  * Finding std/ but not std.d, look for a directory
>>>    std/stdio/ or a file std/stdio.d
>>>  * Finding std/stdio.d, it creates an implicit
>>>    import, like this:
>>>
>>>  /* implicit */ import std.stdio;
>>>  int main() {
>>>    std.stdio.printf("Hello world!\n");
>>>    return 0;
>>>  }
>>>
>>>I'm guessing that there is some good reason for not doing this, but I'm
>>>curious what it is?
>>
>>That's an interesting idea.
>>
>>I don't know how difficult it would be for the compiler. It might be
> 
> trickier
> 
>>than it seems. Even if it's easy for the compiler, I think there are
> 
> reasons why
> 
>>the compiler shouldn't allow it.
>>
>>
>>With auto-importing, we might run into a problem where we get more than we
>>expected when we make a silly mistake.
>>
>>struct aStruct { int b; }
>>aStruct moc;
>>void main() { mod.b = 5; }
>>
>>It's a contrived example, but if you thought "mod" was an aStruct declared
> 
> in
> 
>>that module (like moc), but there was a module with a variable called "b"
> 
> in the
> 
>>same directory called "mod.d", you'd would get much different results than
> 
> you
> 
>>expected. Sounds like things could get messy really quick if you re-use
>>identifiers a lot.
>>
>>That reasoning is similar to why this isn't allowed:
>>import std.c.*;
>>
>>
>>Also, if you have the imports grouped near the top of the file it's easy
> 
> to
> 
>>determine the dependencies of a particular module.
>>
>>jcc7
> 
> 
> 


-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

> I'm curious about that myself. If I'm not mistaken, that's how C# does it.
In
> C#, you use imports so that you don't have to write "System.console.print"
(I
> think that's it...), and can just write "print". I'd like to call
functions
> without importing the modules, too, if that can be done.

That's not quite right I think (please correct me if I'm wrong)...

If you're talking about the "using namespace"s that's exactly how they work... however, you can't use a class/namespace if you don't have the assembly reference (and adding assembly references is just about what D's import does)

Once you have the assembly reference, you can either type the full name "System.Console.print" or you can do type "using namespace System;" and from there on just type "Console.print"

BTW, you can check out your .csproj file, and you'll see a <References> node in it, that's where the referred to assemblies are listed...

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:cfdp94$146p$1@digitaldaemon.com...
> This is a question for Walter.  I'm curious about the reason why you
> have to import a file before using its functions and types.  Why can't
> you do this:
>    int main() {
>      std.stdio.printf("Hello world!\n");
>      return 0;
>    }
>
> I'm thinking here is that the compiler could do this:
>    * Search the current namespaces for 'std'
>    * Not finding std, look for a directory std/ or a
>      file std.d
>    * Finding std/ but not std.d, look for a directory
>      std/stdio/ or a file std/stdio.d
>    * Finding std/stdio.d, it creates an implicit
>      import, like this:
>
>    /* implicit */ import std.stdio;
>    int main() {
>      std.stdio.printf("Hello world!\n");
>      return 0;
>    }
>
> I'm guessing that there is some good reason for not doing this, but I'm curious what it is?

Pretty much for the same reason the compiler doesn't automatically declare variables for you:

    int test(int hello)
    {
        return he11o + 1;
    }

i.e. it makes for some really hard to find bugs.

On Wed, 11 Aug 2004 17:48:24 -0500, J C Calvarese <jcc7@cox.net> wrote:

> Filip Hanik - Dev wrote:
>>> std.stdio.printf("Hello world!\n");
>>   java allows this too, cause if you have the same class name in two different
>> imported modules,
>> how does the compiler resolve that today?
>
> In D, you explicitly import both modules and append the module name when you use the function or class.
>
> For example...
>
> import std.string;
> import std.date;
>
> d_time d;
> int i;
>
> char[] dateStr;
> char[] intStr;
>
> void main()
> {
>      dateStr = std.date.toString(d);
>      intStr = std.string.toString(i);
> }
>
> The suggestion is that we should be able to leave out the explicit import statements at the top and have it still work.
>
> Does importing in Java work without explicit imports?

Yes it does.

I was wondering this same feature too.

For example, in Java you can write something like:

float x = my.pkg.Math.PI;

without importing the Math class explicitely. The compiler uses same technique to solve the imports as the qualified names.

When there is ambiquity, the compiler produces an error. In your example the std.date and std.string are necessary in front of the toString, because they have
both same name. But in java you wouldn't need to import the date and string modules, since the qualified name already includes the package (implicit import).

Actually, in Java you don't need to use imports at all, if you don't want to.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

> Actually, in Java you don't need to use imports at all, if you don't want to.

But you do! :-)