On Wednesday, 5 June 2013 at 18:36:34 UTC, David Nadlinger wrote:
> It also doesn't utilize template constraints, reinvents isRandomAccessRange && hasSlicing under a poor name, uses C printf (!) in the examples, has random 2-3 letter variable names (dis, dip, di, si) all over the place, …
>
> David

Walter explained that calling printf allowed him not to import half of std. I think it's a good practice to limit dependencies to a reasonable minimum. Of course, it's hard to come up with a general rule as to what "reasonable" means here.

05-Jun-2013 22:42, H. S. Teoh пишет:
> On Wed, Jun 05, 2013 at 08:29:51PM +0200, Brad Anderson wrote:
>> On Wednesday, 5 June 2013 at 18:25:45 UTC, w0rp wrote:
>>> An the subject of std.algorithm being very large, I realised
>>> something. Once the import change is in that makes it possible to
>>> import sub-modules all at once, there will be some nice potential
>>> for splitting up std.algorithm a bit into sub-modules, while
>>> making 'import std.algorithm' work exactly like it does now.
>
> Is that even necessary? We could just do this:
>
> ----std/algorithm.d----
> module std.algorithm;
> public import std.algorithm.search;
> public import std.algorithm.compare;
> public import std.algorithm.iteration;
> public import std.algorithm.sort;
> public import std.algorithm.set;
> public import std.algorithm.mutation;
> ----snip----
>
> Newer code, of course, would use the more specific imports.
>

Fully qualified imports!

>
>> You could probably just use the categories the documentation already
>> defines.
>>
>> std\algorithm\searching.d
>> std\algorithm\comparison.d
>> std\algorithm\iteration.d
>> std\algorithm\sorting.d
>> std\algorithm\set.d
>> std\algorithm\mutation.d
>
> Good idea!

Yeah, and I'd like to "packagize" std.regex. Then we'd need to re-think hierarchy though.


-- 
Dmitry Olshansky

On 6/5/13 2:11 PM, Brad Anderson wrote:
> I like them. How would itemize differ from joiner though?

Looks like joiner with one argument already itemizes.

> (apart from hopefully not converting narrow strings to wide strings
> like joiner currently seems to).

Hrm, I figure you'd need either way depending on situation.


Andrei

On 6/5/13 2:26 PM, Brad Anderson wrote:
> On Wednesday, 5 June 2013 at 17:36:05 UTC, Andrei Alexandrescu wrote:
>> Right now we have joiner(), which given several ranges of T, offers a
>> range of T. Developing along that idea, we should have two opposite
>> functions: itemize() and collect().
>
> collect() is sometimes used as the name for map() in some languages
> (e.g., Ruby, Smalltalk). I don't think it's a problem but maybe a note
> in the documentation would be warranted to point people to map.
> Alternatively it could be called something like bundle or parcel.

Love bundle/parcel! Probably bundle more because it's more obvious it's a verb.

Andrei

On 6/5/13 2:36 PM, David Nadlinger wrote:
> On Wednesday, 5 June 2013 at 17:36:05 UTC, Andrei Alexandrescu wrote:
>> itemize() takes a range of ranges of T and offers a range of T. For
>> example, given a range of T[], offers a range of T.
> joiner?
>
>> collect() takes a range of T and offers a range of T[]. The number of
>> items in each chunk can be a parameter.
> chunk? (or rather chunk(…).map!(a => a.array)).

I prefer to avoid the name chunk because (a) it's both a noun and a verb, and (b) it's already alluded to in File.byChunk which is a related but different functionality.

>> I salute this code. It is concise, well engineered, well written, just
>> as general as it needs, uses the right features in the right places,
>> and does real work. A perfect example to follow. The only thing I'd
>> add is this convenience function:
>
> It also doesn't utilize template constraints, reinvents
> isRandomAccessRange && hasSlicing under a poor name, uses C printf (!)
> in the examples, has random 2-3 letter variable names (dis, dip, di, si)
> all over the place, …

Nobody's perfect!


Andrei

On 6/5/13 2:42 PM, H. S. Teoh wrote:
> Is that even necessary? We could just do this:
>
> ----std/algorithm.d----
> module std.algorithm;
> public import std.algorithm.search;
> public import std.algorithm.compare;
> public import std.algorithm.iteration;
> public import std.algorithm.sort;
> public import std.algorithm.set;
> public import std.algorithm.mutation;
> ----snip----

For perfect 100% undetectable backwards compatibility:

module std.algorithm;
private import std.algorithm.search;
alias balancedParens = std.algorithm.search.balancedParens;
alias boyerMooreFinder = std.algorithm.search.boyerMooreFinder;
...


Andrei

On 6/5/13 3:38 PM, Andrei Alexandrescu wrote:
> On 6/5/13 2:42 PM, H. S. Teoh wrote:
>> Is that even necessary? We could just do this:
>>
>> ----std/algorithm.d----
>> module std.algorithm;
>> public import std.algorithm.search;
>> public import std.algorithm.compare;
>> public import std.algorithm.iteration;
>> public import std.algorithm.sort;
>> public import std.algorithm.set;
>> public import std.algorithm.mutation;
>> ----snip----
>
> For perfect 100% undetectable backwards compatibility:
>
> module std.algorithm;
> private import std.algorithm.search;
> alias balancedParens = std.algorithm.search.balancedParens;
> alias boyerMooreFinder = std.algorithm.search.boyerMooreFinder;
> ...
>
>
> Andrei

Wait, that all doesn't work - there's confusion between the file std/algorithm.d file and the std/algorithm/ directory.


Andrei

On Wed, Jun 05, 2013 at 03:38:56PM -0400, Andrei Alexandrescu wrote:
> On 6/5/13 2:42 PM, H. S. Teoh wrote:
> >Is that even necessary? We could just do this:
> >
> >----std/algorithm.d----
> >module std.algorithm;
> >public import std.algorithm.search;
> >public import std.algorithm.compare;
> >public import std.algorithm.iteration;
> >public import std.algorithm.sort;
> >public import std.algorithm.set;
> >public import std.algorithm.mutation;
> >----snip----
> 
> For perfect 100% undetectable backwards compatibility:
> 
> module std.algorithm;
> private import std.algorithm.search;
> alias balancedParens = std.algorithm.search.balancedParens;
> alias boyerMooreFinder = std.algorithm.search.boyerMooreFinder;
> ...
[...]

This is a maintenance nightmare, though. I'd vote against it unless doing otherwise causes major breakage of existing code.

Unless... hmm, is it possible to use runtime introspection to automatically generate these aliases via a mixin? That would be very cool, and a bit scary at the same time. :-P


T

-- 
Notwithstanding the eloquent discontent that you have just respectfully expressed at length against my verbal capabilities, I am afraid that I must unfortunately bring it to your attention that I am, in fact, NOT verbose.

On 6/5/13 12:34 PM, Andrei Alexandrescu wrote:
> On 6/5/13 2:26 PM, Brad Anderson wrote:
>> On Wednesday, 5 June 2013 at 17:36:05 UTC, Andrei Alexandrescu wrote:
>>> Right now we have joiner(), which given several ranges of T, offers a
>>> range of T. Developing along that idea, we should have two opposite
>>> functions: itemize() and collect().
>>
>> collect() is sometimes used as the name for map() in some languages
>> (e.g., Ruby, Smalltalk). I don't think it's a problem but maybe a note
>> in the documentation would be warranted to point people to map.
>> Alternatively it could be called something like bundle or parcel.
>
> Love bundle/parcel! Probably bundle more because it's more obvious it's a verb.
>
> Andrei

Well, both bundle and parcel can be both nouns and verbs.

On Wed, Jun 05, 2013 at 03:44:30PM -0400, Andrei Alexandrescu wrote:
> On 6/5/13 3:38 PM, Andrei Alexandrescu wrote:
> >On 6/5/13 2:42 PM, H. S. Teoh wrote:
> >>Is that even necessary? We could just do this:
> >>
> >>----std/algorithm.d----
> >>module std.algorithm;
> >>public import std.algorithm.search;
> >>public import std.algorithm.compare;
> >>public import std.algorithm.iteration;
> >>public import std.algorithm.sort;
> >>public import std.algorithm.set;
> >>public import std.algorithm.mutation;
> >>----snip----
> >
> >For perfect 100% undetectable backwards compatibility:
> >
> >module std.algorithm;
> >private import std.algorithm.search;
> >alias balancedParens = std.algorithm.search.balancedParens;
> >alias boyerMooreFinder = std.algorithm.search.boyerMooreFinder;
> >...
> >
> >
> >Andrei
> 
> Wait, that all doesn't work - there's confusion between the file std/algorithm.d file and the std/algorithm/ directory.
[...]

Oh? I thought the compiler would be smart enough to look for "std/algorithm.d" when you say "import std.algorithm", and to look for std/algorithm/*.d when there's trailing stuff following "std.algorithm".

Or is this why somebody was suggesting some time ago about importing a directory being implicitly translated to importing "_.d" in the directory?


T

-- 
Do not reason with the unreasonable; you lose by definition.