View mode: basic / threaded / horizontal-split · Log in · Help
July 10, 2012
Re: Why is std.algorithm so complicated to use?
"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message 
news:jthr4a$3f3$1@digitalmars.com...
>
> I swear I'd just call it "range".
>
> Andrei
>

Sure, why not.  http://d.puremagic.com/issues/show_bug.cgi?id=8371
July 10, 2012
Re: Why is std.algorithm so complicated to use?
>
> Given:
>
> @property int delegate() foo(){ ... }
> @property int bar(){ ... }
> int baz(){ ... }
>
> foo(); // calls the delegate.
> bar(); // illegal
> baz;   // ok, call baz
>
> dmd -property gets every single one of these wrong. -property 
> does _not_
> enforce @property semantics. It only adds a silly rule that was 
> never
> part of the @property design. I am astonished that it made it 
> into the
> compiler.

+1
July 10, 2012
Re: Why is std.algorithm so complicated to use?
On Tuesday, July 10, 2012 22:04:17 Timon Gehr wrote:
> @property int delegate() foo(){ ... }
> @property int bar(){ ... }
> int baz(){ ... }
> 
> foo(); // calls the delegate.
> bar(); // illegal
> baz; // ok, call baz
> 
> dmd -property gets every single one of these wrong. -property does _not_
> enforce @property semantics.

The current implementation of -property is horribly broken:

http://d.puremagic.com/issues/show_bug.cgi?id=4183
http://d.puremagic.com/issues/show_bug.cgi?id=8162

It's not actually enforcing what it's supposed to enforce, and it needs to be 
fixed.

- Jonathan M Davis
July 10, 2012
Re: Why is std.algorithm so complicated to use?
On Tuesday, July 10, 2012 21:07:51 Jacob Carlborg wrote:
> Second, it would be much easier if it would be possible to better name
> these ranges, something like interfaces but without polymorphism. This
> as been mentioned several times before.

They're templated types. They have to be templated types. And since they're 
templated types, better names do you no good whatsoever as far as declaring a 
variable goes. You'll _never_ be able to do something like

NiceName range;

NiceName will always be templated. The _closest_ that you get is with 
Voldemort types. Since they're templated as part of the function that they're 
in rather than separately, they end up with names such as Result or 
FilteredRange, but you couldn't do

FilteredRange range;

because that type depends on its outer scope (in this case, filter). You'd 
_still_ have to use typeof or ReturnType if you need to declare such a 
variable without directly assigning it (in which case, you can use auto). And 
if you have a separate range type rather than a Voldemort Type, you end up 
with stuff like Until!("a == b", string, dchar). The templated nature of ranges 
makes it impossible to have friendly names which you can use to simply declare 
variables of a particular range type. auto, ReturnType, and typeof are 
required tools for dealing with templated types like this.

- Jonathan M Davis
July 10, 2012
Re: Why is std.algorithm so complicated to use?
Jacob Carlborg , dans le message (digitalmars.D:171725), a écrit :
>> To make the best implementation would require to know how the String
>> context works.
>>
> String is a wrapper around str.array.Appender.

Then, if the purpose is to make the code efficient, I would use the loop 
and append everything to the result without creating the params array, 
and even without creating the string p. Appender is made to append 
everything directly to it efficiently.
July 10, 2012
Re: Why is std.algorithm so complicated to use?
"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message 
news:mailman.249.1341951069.31962.digitalmars-d@puremagic.com...
> On Tuesday, July 10, 2012 21:07:51 Jacob Carlborg wrote:
>> Second, it would be much easier if it would be possible to better name
>> these ranges, something like interfaces but without polymorphism. This
>> as been mentioned several times before.
>
> They're templated types. They have to be templated types. And since 
> they're
> templated types, better names do you no good whatsoever as far as 
> declaring a
> variable goes. You'll _never_ be able to do something like
>
> NiceName range;
>

This isn't really true.  You can still in some cases  the type relative to 
some other type. (warning: old code, may not compile any more)
Sure, you can use auto and typeof, but that doesn't make it clearer.

struct SubSequences(R)
{
   R r;
   R s;
   Take!R c;
   int n;
   this(R r)
   {
       this.r = r;
       s = r;
       n = 0;
       c = take(r, 1);
       popFront();
   }
   void popFront()
   {
       c.popFront();
       if (c.empty)
       {
           c = take(r, ++n);
           s.popFront();
       }
   }
   Take!R front() { return c; }
   bool empty() { return s.empty; }
   typeof(this) save() { return this; }
};
SubSequences!R subSequences(R)(R r) { return SubSequences!R(r); }
July 10, 2012
Re: Why is std.algorithm so complicated to use?
Jacob Carlborg , dans le message (digitalmars.D:171769), a écrit :
> On 2012-07-10 20:04, Andrei Alexandrescu wrote:
> 
>> Then store an array. "No one's put a gun to yer head."
>> http://youtu.be/CB1Pij54gTw?t=2m29s
> 
> That's what I'm doing.
> 

And that's what you should do. Algorithm are not made to be stored in 
struct or class instance. You could use InputRange(E) and friends 
to do that, but that's often not optimal. Algorithm are here to do 
their job and output non-lazy result in the end.
July 10, 2012
Re: Why is std.algorithm so complicated to use?
On 11-Jul-12 00:07, Tobias Pankrath wrote:
>>
>> Given:
>>
>> @property int delegate() foo(){ ... }
>> @property int bar(){ ... }
>> int baz(){ ... }
>>
>> foo(); // calls the delegate.
>> bar(); // illegal
>> baz;   // ok, call baz
>>
>> dmd -property gets every single one of these wrong. -property does _not_
>> enforce @property semantics. It only adds a silly rule that was never
>> part of the @property design. I am astonished that it made it into the
>> compiler.
>
> +1

Same here. Still no idea what they were smoking at the time.

-- 
Dmitry Olshansky
July 10, 2012
Re: Why is std.algorithm so complicated to use?
On 2012-07-10 22:13, Christophe Travert wrote:

> Then, if the purpose is to make the code efficient, I would use the loop
> and append everything to the result without creating the params array,
> and even without creating the string p. Appender is made to append
> everything directly to it efficiently.

Yeah, I've been thinking about doing that more.

-- 
/Jacob Carlborg
July 11, 2012
Re: Why is std.algorithm so complicated to use?
On 07/10/2012 10:48 AM, Simen Kjaeraas wrote:
> On Tue, 10 Jul 2012 16:15:09 +0200, Jacob Carlborg <doob@me.com> wrote:

>> How do you store your ranges in a struct or class? Most of them are
>> voldemort types.
>
> Well, there is std.range.inputRangeObject, but as the name indicates

As the name "misleads"... :)

>, it's
> only an input range.

... it can be used as any one of the non-OutputRanges:

import std.algorithm;
import std.range;
import std.stdio;

void main() {
     int[] a1 = [1, 2, 3];

     ForwardRange!int r1 = inputRangeObject(map!"2 * a"(a1));
     ForwardRange!int r2 = inputRangeObject(map!"a ^^ 2"(a1));

     auto a2 = [r1, r2];

     writeln(a2);
}

Replace ForwardRange!int above with any other non-OutputRange, and as 
long as the input to inputRangeObject() is compatible, it will work. 
(static if magic).

Ali
8 9 10 11 12 13 14
Top | Discussion index | About this forum | D home