We plan to add a set of numeric packages and this would be real pain if they would be one-by-one moved from experimental to stable std. So sci.* should be considered as experimental during few years.


https://github.com/dlang/phobos/pull/4207

On Sunday, 17 April 2016 at 06:10:34 UTC, Ilya Yaroshenko wrote:
> We plan to add a set of numeric packages and this would be real pain if they would be one-by-one moved from experimental to stable std. So sci.* should be considered as experimental during few years.
>
>
> https://github.com/dlang/phobos/pull/4207

I'm not sure this is a good idea.

1. std.experimental is self documenting, you know right away that the modules are not stable
2. std, core, and etc are all reserved for Phobos, adding in others is an unnecessary breaking change

I really don't see why ndslice and other numerical libraries should have special treatment.

On Sunday, 17 April 2016 at 06:10:34 UTC, Ilya Yaroshenko wrote:
> We plan to add a set of numeric packages and this would be real pain if they would be one-by-one moved from experimental to stable std. So sci.* should be considered as experimental during few years.
>
>
> https://github.com/dlang/phobos/pull/4207

As I wrote on the PR --

Introducing a new top-level package is a HUGE DEAL. For one thing, it will break build tools such as rdmd, which know which top-level packages to exclude from linking (as they'll be in phobos.lib). For another, it might conflict with users' packages.

We need a very strong reason to do this.

--

Also, what precedent does this set? If we start throwing image-processing code into Phobos, does that mean we should introduce another top-level package? Where do you draw the line?

On Sunday, 17 April 2016 at 07:02:25 UTC, Jack Stouffer wrote:
> On Sunday, 17 April 2016 at 06:10:34 UTC, Ilya Yaroshenko wrote:
>> We plan to add a set of numeric packages and this would be real pain if they would be one-by-one moved from experimental to stable std. So sci.* should be considered as experimental during few years.
>>
>>
>> https://github.com/dlang/phobos/pull/4207
>
> I'm not sure this is a good idea.
>
> 1. std.experimental is self documenting, you know right away that the modules are not stable
> 2. std, core, and etc are all reserved for Phobos, adding in others is an unnecessary breaking change

1. The same would be for all sci
2. requires only few changes in configs

> I really don't see why ndslice and other numerical libraries should have special treatment.

Because synchronization between different numeric parts. sci part of phobos would be _very_ integrated each other. So it would be headache to move any package from ndslice from experimental because all other packages and Mir would require changes. Note, that we also have other compiler that should be supported without breaking code.

So the reason is introduce the small breaking change now instead of dozens breaking changes in the future.

On Sunday, 17 April 2016 at 07:11:17 UTC, Vladimir Panteleev wrote:
> On Sunday, 17 April 2016 at 06:10:34 UTC, Ilya Yaroshenko wrote:
>> We plan to add a set of numeric packages and this would be real pain if they would be one-by-one moved from experimental to stable std. So sci.* should be considered as experimental during few years.
>>
>>
>> https://github.com/dlang/phobos/pull/4207
>
> As I wrote on the PR --
>
> Introducing a new top-level package is a HUGE DEAL. For one thing, it will break build tools such as rdmd, which know which top-level packages to exclude from linking (as they'll be in phobos.lib).For another, it might conflict with users' packages.

sci name was reserved for future use: http://code.dlang.org/packages/sci

> We need a very strong reason to do this.
>
> --
>
> Also, what precedent does this set? If we start throwing image-processing code into Phobos, does that mean we should introduce another top-level package? Where do you draw the line?

The goal is to include only good consistent basic functionality for data/numeric/math/sci users:

1. Tensors - ndslice
2. Sparse tensors - future ndslice.sparse
3. FFT - fast & multidimensional & vectorized & pure D
4. BLAS - fast & multidimensional & vectorized & pure D

On Sunday, 17 April 2016 at 07:25:55 UTC, Ilya Yaroshenko wrote:
> sci name was reserved for future use: http://code.dlang.org/packages/sci

What does a Dub package have to do with D module system packages?

> The goal is to include only good consistent basic functionality for data/numeric/math/sci users:
>
> 1. Tensors - ndslice
> 2. Sparse tensors - future ndslice.sparse
> 3. FFT - fast & multidimensional & vectorized & pure D
> 4. BLAS - fast & multidimensional & vectorized & pure D

I don't understand, what's wrong with std.sci or etc.sci?

On Sunday, 17 April 2016 at 07:30:38 UTC, Vladimir Panteleev wrote:
> On Sunday, 17 April 2016 at 07:25:55 UTC, Ilya Yaroshenko wrote:
>> sci name was reserved for future use: http://code.dlang.org/packages/sci
>
> What does a Dub package have to do with D module system packages?
>
>> The goal is to include only good consistent basic functionality for data/numeric/math/sci users:
>>
>> 1. Tensors - ndslice
>> 2. Sparse tensors - future ndslice.sparse
>> 3. FFT - fast & multidimensional & vectorized & pure D
>> 4. BLAS - fast & multidimensional & vectorized & pure D
>
> I don't understand, what's wrong with std.sci or etc.sci?

I am ok with std.sci for example. I just want to exclude dances with transaction between stable <->`experimental`. So, if all `std.sci` would be marked as experimental during few years this would what i want.

On Sunday, 17 April 2016 at 07:35:19 UTC, Ilya Yaroshenko wrote:
> On Sunday, 17 April 2016 at 07:30:38 UTC, Vladimir Panteleev wrote:
>> On Sunday, 17 April 2016 at 07:25:55 UTC, Ilya Yaroshenko wrote:
>>> sci name was reserved for future use: http://code.dlang.org/packages/sci
>>
>> What does a Dub package have to do with D module system packages?
>>
>>> The goal is to include only good consistent basic functionality for data/numeric/math/sci users:
>>>
>>> 1. Tensors - ndslice
>>> 2. Sparse tensors - future ndslice.sparse
>>> 3. FFT - fast & multidimensional & vectorized & pure D
>>> 4. BLAS - fast & multidimensional & vectorized & pure D
>>
>> I don't understand, what's wrong with std.sci or etc.sci?
>
> I am ok with std.sci for example. I just want to exclude dances with transaction between stable <->`experimental`. So, if all `std.sci` would be marked as experimental during few years this would what i want.

I can only agree with Ilya. It's currently a huge pain to develop something with mir or submit a bug fix, as Ilya has to manually diff and then send it Phobos.
I think the same should be said about other packages that are in experimental, but for now mir is the only one with active development.
If there would be a language solution to this problem - e.g.
1) that it is possible to overwrite modules from the standard library
2) it is possible to exclude experimental from the standard library
3) your ideas..

Then we would be even happier :)
It's really a huge deal to us, because it currently wastes a lot of development time.

Another idea would be to go with std.experimental.sci.*, if that has a higher consensus.

On Sunday, 17 April 2016 at 08:49:53 UTC, Seb wrote:
> On Sunday, 17 April 2016 at 07:35:19 UTC, Ilya Yaroshenko wrote:
>> On Sunday, 17 April 2016 at 07:30:38 UTC, Vladimir Panteleev
>>> I don't understand, what's wrong with std.sci or etc.sci?
>>
>> I am ok with std.sci for example. I just want to exclude dances with transaction between stable <->`experimental`. So, if all `std.sci` would be marked as experimental during few years this would what i want.
>>
> Another idea would be to go with std.experimental.sci.*, if that has a higher consensus.

Just with std.sci.* without `experimental`. Otherwise this would be the same problem.

On Sunday, 17 April 2016 at 09:09:52 UTC, Ilya Yaroshenko wrote:
>
> Just with std.sci.* without `experimental`. Otherwise this would be the same problem.

What's wrong with std.experimental.sci.*? experimental is where experimental modules/packages should go.