On Tuesday, 4 June 2013 at 19:00:35 UTC, John Colvin wrote:
> On Tuesday, 4 June 2013 at 18:46:49 UTC, Walter Bright wrote:
>> On 6/4/2013 11:43 AM, Timothee Cour wrote:
>>> writing generic code.
>>> same reason as why we prefer:
>>> auto y=to!double(x) over auto y=to_double(x);
>>
>> The situations aren't comparable. The to!double case is parameterizing with a type, the compress one is not. Secondly, compress(lzw) does ABSOLUTELY NOTHING but turn around and call lzw. It adds nothing.
>
>
> Currently. However, compress could become more feature-rich in the future. Perhaps there's some scope for automatic algorithm/parameter selection based on the type and length(if available) of what gets passed.

I think this is over-engineering. It's unlikely that an application will need to support multiple compression algorithms in the same piece of code, and even if it did, it would be trivial to implement this on top of the simple interface that Walter is using.

On 6/4/2013 11:55 AM, Jonathan M Davis wrote:
> Well, I'd expect it to be compress!lzw(), but in any case, what it buys you is
> that you can pass the algorithm around without caring what it is so that while
> code higher up on the stack may have to know that it's lzw, code deeper down
> doesn't have to care what type of algorithm it's using. Now, whether that
> flexibility is all that useful in this particular case, I don't know, but it
> _does_ help with generic code. It's like how a lot of std.algorithm takes its
> predicate as an alias.

There is zero utility in this:

auto compress(alias dg)
{
    return dg();
}

Not even for generic code.

On 6/4/2013 12:41 PM, Peter Alexander wrote:
> I think this is over-engineering. It's unlikely that an application will need to
> support multiple compression algorithms in the same piece of code, and even if
> it did, it would be trivial to implement this on top of the simple interface
> that Walter is using.

Yup. My experience with abstractions that have no use cases is all the wrong things get abstracted. And by my experience, I include every one I've seen other people write as well as my own.

My favorite is windows.h. It was originally written for 16 bit Windows, and had all kinds of abstractions to make it portable for a future 32 bit Windows. Unfortunately, apparently nobody working on windows.h had any experience with 32 bit code, and the abstractions turned out to be all wrong.

On Tuesday, June 04, 2013 13:15:07 Walter Bright wrote:
> On 6/4/2013 11:55 AM, Jonathan M Davis wrote:
> > Well, I'd expect it to be compress!lzw(), but in any case, what it buys you is that you can pass the algorithm around without caring what it is so that while code higher up on the stack may have to know that it's lzw, code deeper down doesn't have to care what type of algorithm it's using. Now, whether that flexibility is all that useful in this particular case, I don't know, but it _does_ help with generic code. It's like how a lot of std.algorithm takes its predicate as an alias.
> 
> There is zero utility in this:
> 
> auto compress(alias dg)
> {
> return dg();
> }
> 
> Not even for generic code.

If that's all it's doing, then no, it wouldn't be useful to pass it as an argument. I was just pointing out that there are plenty of cases where passing functions to generic algorithms is an improvement. I haven't looked at what you've done yet, so I can't really comment on the details of this particular case.

- Jonathan M Davis

On Tue, 04 Jun 2013 13:15:07 -0700, Walter Bright wrote:

> On 6/4/2013 11:55 AM, Jonathan M Davis wrote:
>> Well, I'd expect it to be compress!lzw(), but in any case, what it buys you is that you can pass the algorithm around without caring what it is so that while code higher up on the stack may have to know that it's lzw, code deeper down doesn't have to care what type of algorithm it's using. Now, whether that flexibility is all that useful in this particular case, I don't know, but it _does_ help with generic code. It's like how a lot of std.algorithm takes its predicate as an alias.
> 
> There is zero utility in this:
> 
> auto compress(alias dg)
> {
>      return dg();
> }
> 
> Not even for generic code.

but a compress interface would be nice:

interface Compress
{
    ubyte[] compress(ubyte[]);
    ubyte[] uncompress(ubyte[]);
}

that way you can use any compress algorithm
bool send(Compress)(Socket sock);

05-Jun-2013 00:30, Byron Heads пишет:
> On Tue, 04 Jun 2013 13:15:07 -0700, Walter Bright wrote:
>
>> On 6/4/2013 11:55 AM, Jonathan M Davis wrote:
>>> Well, I'd expect it to be compress!lzw(), but in any case, what it buys
>>> you is that you can pass the algorithm around without caring what it is
>>> so that while code higher up on the stack may have to know that it's
>>> lzw, code deeper down doesn't have to care what type of algorithm it's
>>> using. Now, whether that flexibility is all that useful in this
>>> particular case, I don't know, but it _does_ help with generic code.
>>> It's like how a lot of std.algorithm takes its predicate as an alias.
>>
>> There is zero utility in this:
>>
>> auto compress(alias dg)
>> {
>>       return dg();
>> }
>>
>> Not even for generic code.
>
> but a compress interface would be nice:
>
> interface Compress
> {
>      ubyte[] compress(ubyte[]);
>      ubyte[] uncompress(ubyte[]);
> }
>
> that way you can use any compress algorithm
> bool send(Compress)(Socket sock);
>

It's a range already thus composable. Ranged I/O though is something to come some time in near future (Steve?)

-- 
Dmitry Olshansky

On 6/4/13 2:43 PM, Timothee Cour wrote:
>     What is the improvement of typing:
>
>         compress(lzw)
>
>     over:
>
>         lzwCompress()
>
>     ?
>
>
> writing generic code.
> same reason as why we prefer:
> auto y=to!double(x) over auto y=to_double(x);
>

I think the application here is a bit more tenuous. It's natural to think of a type-parameterized algorithm that needs to!T. But it's more of a long shot to think of an algorithm statically parameterized on the compression method. That could definitely intervene, but it's not likely to be frequent; and if it's not, a mixin can always take care of it.

Andrei

On 6/4/13 2:46 PM, Walter Bright wrote:
> On 6/4/2013 11:43 AM, Timothee Cour wrote:
>> writing generic code.
>> same reason as why we prefer:
>> auto y=to!double(x) over auto y=to_double(x);
>
> The situations aren't comparable. The to!double case is parameterizing
> with a type, the compress one is not. Secondly, compress(lzw) does
> ABSOLUTELY NOTHING but turn around and call lzw. It adds nothing.

Not absolutely nothing. Almost nothing. The distinction is important.

Andrei

On 6/4/2013 1:30 PM, Byron Heads wrote:
> but a compress interface would be nice:
>
> interface Compress
> {
>      ubyte[] compress(ubyte[]);
>      ubyte[] uncompress(ubyte[]);
> }
>
> that way you can use any compress algorithm
> bool send(Compress)(Socket sock);

That isn't how ranges work. Ranges already define an input and an output interface. We don't need to invent another scheme.

Am Tue, 04 Jun 2013 09:06:22 -0700
schrieb Walter Bright <newshound2@digitalmars.com>:

> On 6/4/2013 5:17 AM, Adam D. Ruppe wrote:
> > I actually wish we could have multiple modules in a single file.
> 
> I don't see much point to that in modern file systems.

Probably seek time if the files are scattered and not in cache. That's hardly a show stopper unless you have 17.156 files like the Java Runtime. But they 'solved' it by zipping them up.

-- 
Marco