December 20, 2013
On 2013-12-20 19:36:28 +0000, "Meta" <jared771@gmail.com> said:

> On Friday, 20 December 2013 at 19:34:10 UTC, Patrick Down wrote:
>> On Friday, 20 December 2013 at 17:40:08 UTC, H. S. Teoh wrote:
>>> in the current import path, then implicitly try to import x.y and lookup
>>> z in that module. Then you could just write:
>>> 
>>> 	void f(T)(T t) if (std.range.isInputRange!T) ...
>>> 
>>> and the compiler will automatically import std.range within that scope.
>> 
>> How about:
>> 
>> scope import std.range;
>> // lazy import std.range; ?
>> 
>> void f(T)(T t) if (std.range.isInputRange!T) ...
> 
> I think the best keyword to use in this situation would be stati... Oh, dammit, not again.

Actually, "static import" already exists. And semantically it's pretty much the same thing as the above: you have to use the symbol's full name. But currently the compiler will import eagerly. I doubt there'd be any breakage if "static" changed to mean "lazily imported".

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

December 20, 2013
On Fri, Dec 20, 2013 at 02:40:22PM -0500, Michel Fortin wrote:
> On 2013-12-20 19:36:28 +0000, "Meta" <jared771@gmail.com> said:
> 
> >On Friday, 20 December 2013 at 19:34:10 UTC, Patrick Down wrote:
> >>On Friday, 20 December 2013 at 17:40:08 UTC, H. S. Teoh wrote:
> >>>in the current import path, then implicitly try to import x.y and lookup z in that module. Then you could just write:
> >>>
> >>>	void f(T)(T t) if (std.range.isInputRange!T) ...
> >>>
> >>>and the compiler will automatically import std.range within that scope.
> >>
> >>How about:
> >>
> >>scope import std.range;
> >>// lazy import std.range; ?
> >>
> >>void f(T)(T t) if (std.range.isInputRange!T) ...
> >
> >I think the best keyword to use in this situation would be stati... Oh, dammit, not again.
> 
> Actually, "static import" already exists. And semantically it's pretty much the same thing as the above: you have to use the symbol's full name. But currently the compiler will import eagerly. I doubt there'd be any breakage if "static" changed to mean "lazily imported".
[...]

Hmm. In that case, looks like we already have the solution. :)


T

-- 
"Real programmers can write assembly code in any language. :-)" -- Larry Wall
December 20, 2013
On Friday, 20 December 2013 at 19:51:03 UTC, H. S. Teoh wrote:
> On Fri, Dec 20, 2013 at 02:40:22PM -0500, Michel Fortin wrote:
>> On 2013-12-20 19:36:28 +0000, "Meta" <jared771@gmail.com> said:
>> 
>> >On Friday, 20 December 2013 at 19:34:10 UTC, Patrick Down wrote:
>> >>On Friday, 20 December 2013 at 17:40:08 UTC, H. S. Teoh wrote:
>> >>>in the current import path, then implicitly try to import x.y and
>> >>>lookup z in that module. Then you could just write:
>> >>>
>> >>>	void f(T)(T t) if (std.range.isInputRange!T) ...
>> >>>
>> >>>and the compiler will automatically import std.range within that
>> >>>scope.
>> >>
>> >>How about:
>> >>
>> >>scope import std.range;
>> >>// lazy import std.range; ?
>> >>
>> >>void f(T)(T t) if (std.range.isInputRange!T) ...
>> >
>> >I think the best keyword to use in this situation would be
>> >stati... Oh, dammit, not again.
>> 
>> Actually, "static import" already exists. And semantically it's
>> pretty much the same thing as the above: you have to use the
>> symbol's full name. But currently the compiler will import eagerly.
>> I doubt there'd be any breakage if "static" changed to mean "lazily
>> imported".
> [...]
>
> Hmm. In that case, looks like we already have the solution. :)
>
>
> T

Yes, that's actually quite smart. I like it.
+1.
December 20, 2013
On 12/20/2013 06:27 PM, Andrei Alexandrescu wrote:
>
> I had this idea fot a while, and Walter is favorable of it as well -
> extend "import" for one-shot use. With that feature the example would
> become:
>
>      void topN(alias less = "a < b",
>              SwapStrategy ss = SwapStrategy.unstable,
>              Range, RandomGen)(Range r, size_t nth, ref RandomGen rng)
>          if (isRandomAccessRange!(Range) && hasLength!Range
>              && import.std.random.isUniformRNG!RandomGen)
>      { ... }
>
> In this case "import" would syntactically be placed at the beginning of
> a qualified name, meaning "import this module lazily and look up the
> symbol in it".
>
> This would simplify quite a lot of two-liners into one-liners in other
> places, too.

The fact that template constraints use the module scope is indeed a root cause for a lot of module dependencies, so we should tackle this problem specifically.

Couldn't static imports be made lazy without breaking any code?
The above example would read.

static import std.range.

void foo(R)(R range) if (std.range.isForwardRange!R)
{
}

December 20, 2013
On 12/20/2013 08:40 PM, Michel Fortin wrote:
> Actually, "static import" already exists. And semantically it's pretty
> much the same thing as the above: you have to use the symbol's full
> name. But currently the compiler will import eagerly. I doubt there'd be
> any breakage if "static" changed to mean "lazily imported".

Ah, same idea :).
December 20, 2013
On 12/20/13 12:43 PM, Martin Nowak wrote:
> Couldn't static imports be made lazy without breaking any code?

One simple idea is to make all imports lazy - no change in semantics.

Andrei

December 20, 2013
On Friday, 20 December 2013 at 21:36:15 UTC, Andrei Alexandrescu wrote:
> On 12/20/13 12:43 PM, Martin Nowak wrote:
>> Couldn't static imports be made lazy without breaking any code?
>
> One simple idea is to make all imports lazy - no change in semantics.
>
> Andrei

If the import is lazy, how do you know which import to load when you see an unknown symbol? lazy static import works, because they have to be fully qualified.
December 20, 2013
On Fri, Dec 20, 2013 at 10:51:13PM +0100, monarch_dodra wrote:
> On Friday, 20 December 2013 at 21:36:15 UTC, Andrei Alexandrescu wrote:
> >On 12/20/13 12:43 PM, Martin Nowak wrote:
> >>Couldn't static imports be made lazy without breaking any code?
> >
> >One simple idea is to make all imports lazy - no change in semantics.
> >
> >Andrei
> 
> If the import is lazy, how do you know which import to load when you see an unknown symbol? lazy static import works, because they have to be fully qualified.

Yeah, much as I like the idea of all imports being lazy by default, I see a lot of potential problems in the implementation. If you have 10 lazy imports and you reference an unknown symbol, will the compiler now go and import all 10 modules just so it can search them for the unknown symbol?  Sounds like recipe for disaster.


T

-- 
It only takes one twig to burn down a forest.
December 21, 2013
On 12/20/2013 06:27 PM, Andrei Alexandrescu wrote:
>
> I had this idea fot a while, and Walter is favorable of it as well -
> extend "import" for one-shot use. With that feature the example would
> become:
>
>      void topN(alias less = "a < b",
>              SwapStrategy ss = SwapStrategy.unstable,
>              Range, RandomGen)(Range r, size_t nth, ref RandomGen rng)
>          if (isRandomAccessRange!(Range) && hasLength!Range
>              && import.std.random.isUniformRNG!RandomGen)
>      { ... }
>
> In this case "import" would syntactically be placed at the beginning of
> a qualified name, meaning "import this module lazily and look up the
> symbol in it".
>
> This would simplify quite a lot of two-liners into one-liners in other
> places, too.
>
>
> Andrei

This is problematic for dependency generation à la rdmd.
The compiler won't know the import until the lazy symbol
is used, thereby making it impossible to build all dependencies
into a library using rdmd.
December 21, 2013
On 2013-12-20 21:36:15 +0000, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:

> On 12/20/13 12:43 PM, Martin Nowak wrote:
>> Couldn't static imports be made lazy without breaking any code?
> 
> One simple idea is to make all imports lazy - no change in semantics.

Sure, why not. Except that upon reaching the first non-fully-qualified symbol you'd have to load them all because they could all contain a symbol with that name. So in practice it'd change nothing, except for static imports.

Beside that, loading modules eagerly is more parallelizable.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca