On 4/12/13, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> On Fri, 12 Apr 2013 15:16:09 -0400, Kagamin <spam@here.lot> wrote:
>
>> On Friday, 12 April 2013 at 17:27:58 UTC, Steven Schveighoffer wrote:
>>> 1. Add std.exp.module with the API as it will be WITHOUT warnings
>>
>> exp.module?
>
> Right.

I'd rather we keep it under "std" to avoiding stealing a name that an external library might already use (it's not stealing per se but it might introduce conflicts).

On Fri, 12 Apr 2013 16:15:33 -0400, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> On 4/12/13, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>> On Fri, 12 Apr 2013 15:16:09 -0400, Kagamin <spam@here.lot> wrote:
>>
>>> On Friday, 12 April 2013 at 17:27:58 UTC, Steven Schveighoffer wrote:
>>>> 1. Add std.exp.module with the API as it will be WITHOUT warnings
>>>
>>> exp.module?
>>
>> Right.
>
> I'd rather we keep it under "std" to avoiding stealing a name that an
> external library might already use (it's not stealing per se but it
> might introduce conflicts).

I'd like to take this opportunity to say I don't care what the name is :)  That wasn't any part of my suggestion.  Whatever was decided as the "place to put experimental modules" is what I meant.

-Steve

A)
what has been described so far doesn't take into account revamped
modules, only new modules. However revamping modules also needs to be
taken into consideration (there was a discussion before on whether we
should have std.process2, which was agreed to be bad).

Here's a suggestion that would work for both new and revamped modules:

put experimental/revamped modules during staging period under (to take
std.process example):

./phobos/std/process.d //current one
./phobos/experimental/std/process.d //new one, still called module std.process

now instead of having to modify D source files to change 'import exp.process' into 'import std.process' as has been suggested by some, here we would only need to change compiler flags:

rdmd $DFLAGS -I$phobos_root/experimental main.d  => uses experimental/std/process.d if import std.process is mentioned

rdmd $DFLAGS main.d  => uses std/process.d if import std.process is mentioned

B)
To handle fine grained selection of the experimental new/revamped
modules, we can refine the preceding scheme with per-module
identifiers:

rdmd $DFLAGS -I$phobos_root/experimental -J$phobos_root

experimental/std/process.d:

module std.process;
version(experimental_std_process_version_latest)
  mixin(import("experimental/std/experimental_std_process_version_3.d"));
//latest revision
else version(...) //maybe some intermediate revision given by a number
else
  mixin(import("std/process.d").removeFirstLineContainingImportDecl);
//default one

C)
Furthermore, instead of version(AllowExperimental){} else pragma(msg,
"RED FLAG"); that was suggested, we can leverage UDA for more
flexibility:
the logic would enable behavior such as controlling whether to print
warnings depending on whether user code or library depends on
experimental feature.





On Fri, Apr 12, 2013 at 1:25 PM, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> On Fri, 12 Apr 2013 16:15:33 -0400, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
>
>> On 4/12/13, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>>>
>>> On Fri, 12 Apr 2013 15:16:09 -0400, Kagamin <spam@here.lot> wrote:
>>>
>>>> On Friday, 12 April 2013 at 17:27:58 UTC, Steven Schveighoffer wrote:
>>>>>
>>>>> 1. Add std.exp.module with the API as it will be WITHOUT warnings
>>>>
>>>>
>>>> exp.module?
>>>
>>>
>>> Right.
>>
>>
>> I'd rather we keep it under "std" to avoiding stealing a name that an external library might already use (it's not stealing per se but it might introduce conflicts).
>
>
> I'd like to take this opportunity to say I don't care what the name is :) That wasn't any part of my suggestion.  Whatever was decided as the "place to put experimental modules" is what I meant.
>
> -Steve

On Sat, 13 Apr 2013 11:19:50 -0400, Timothee Cour <thelastmammoth@gmail.com> wrote:

> A)
> what has been described so far doesn't take into account revamped
> modules, only new modules. However revamping modules also needs to be
> taken into consideration (there was a discussion before on whether we
> should have std.process2, which was agreed to be bad).
>
> Here's a suggestion that would work for both new and revamped modules:
>
> put experimental/revamped modules during staging period under (to take
> std.process example):
>
> ./phobos/std/process.d //current one
> ./phobos/experimental/std/process.d //new one, still called module std.process
>
> now instead of having to modify D source files to change 'import
> exp.process' into 'import std.process' as has been suggested by some,
> here we would only need to change compiler flags:
>
> rdmd $DFLAGS -I$phobos_root/experimental main.d  => uses
> experimental/std/process.d if import std.process is mentioned
>
> rdmd $DFLAGS main.d  => uses std/process.d if import std.process is mentioned

How does that work if both modules are std.process?  Wouldn't there be a link error?

-Steve

On 4/15/13, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> How does that work if both modules are std.process?  Wouldn't there be a link error?

Also someone might want to use both modules (e.g. to use some kind of a transition process). That technique would make this impossible.

> How does that work if both modules are std.process?  Wouldn't there be a link error?

There won't be a 'duplicate symbol definition', instead, dmd will find the first file on the import path that defines a module std.process. Actually, in the above example, I need to use '-I$phobos_root/experimental' _before_  $DFLAGS, as  $DFLAGS already defines -I$phobos_root.

On 4/15/13, Timothee Cour <thelastmammoth@gmail.com> wrote:
>> How does that work if both modules are std.process?  Wouldn't there be a link error?
>
> There won't be a 'duplicate symbol definition', instead, dmd will find the first file on the import path that defines a module std.process.

Phobos comes as a prebuilt static library, which DMD uses. But Phobos can't be built entirely as a static library if there are two modules with the same name.

On Mon, 15 Apr 2013 13:03:07 -0400, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> On 4/15/13, Timothee Cour <thelastmammoth@gmail.com> wrote:
>>> How does that work if both modules are std.process?  Wouldn't there be a
>>> link error?
>>
>> There won't be a 'duplicate symbol definition', instead, dmd will find
>> the first file on the import path that defines a module std.process.
>
> Phobos comes as a prebuilt static library, which DMD uses. But Phobos
> can't be built entirely as a static library if there are two modules
> with the same name.

Yes, that was my question, the library will define two std.process.  What would happen?

-Steve

ok I was talking about user code. To also make it work with phobos, it would also have to be recompiled (recompiling just phobos is fast anyways); the simplest would be the following:

A) user defines an environment variable PHOBOS_INC (which defaults to -I$phobos_root but can be overridden for example by -I$phobos_root/experimental -I$phobos_root).

B) $phobos_root/posix.mak (+ windows makefiles) is improved to support
reading in $PHOBOS_INC
currently we have:
STD_MODULES = $(addprefix std/, algorithm array process ...)
we should instead use $PHOBOS_INC to follow the same logic as dmd
would, ie use the first module that comes on the import path and avoid
duplication. Actually I suggested somewhere else to rewrite phobos's
makefile by a simpler makefile written in D. That would make this
easy.



On Mon, Apr 15, 2013 at 10:13 AM, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> On Mon, 15 Apr 2013 13:03:07 -0400, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
>
>> On 4/15/13, Timothee Cour <thelastmammoth@gmail.com> wrote:
>>>>
>>>> How does that work if both modules are std.process?  Wouldn't there be a link error?
>>>
>>>
>>> There won't be a 'duplicate symbol definition', instead, dmd will find the first file on the import path that defines a module std.process.
>>
>>
>> Phobos comes as a prebuilt static library, which DMD uses. But Phobos can't be built entirely as a static library if there are two modules with the same name.
>
>
> Yes, that was my question, the library will define two std.process.  What would happen?
>
> -Steve

> Also someone might want to use both modules (e.g. to use some kind of a transition process). That technique would make this impossible.

If you call it another module name (say exp.process), then:

A) you would not be able to test how the rest of phobos interacts with the new std.process unless you also temporarily changed the source files in phobos to include exp.process instead of std.process (messy).

B) That could also lead to duplicate extern(C) symbols being defined
in both modules.

C) you would end up with the same situation that led to javax described above by others: significant amounts of code may start importing exp.process to the point where it's too late to change it back to std.process.

----
In what I proposed, the source never needs to change, only compile flags to specify order of imports.

But to answer your concern, if you really want to temporarily import 2 versions of process.d to coexist and be co-importable, you can simply mixin-string-import experimental/std/experimental_std_process_version_3.d from a differently named module (say, std.process2), see my point B in proposal, although that shouldn't be the common use case.

note: I just forgot to mention in the proposal that the 'module std.process;' declaration should be commented out from the implementation file experimental/std/experimental_std_process_version_3.d (which makes this module swapping possible).