"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:jthr4a$3f3$1@digitalmars.com...
> On 7/10/12 2:08 PM, Jonathan M Davis wrote:
>>> That does seem good to have. What would be a better name than makeRange?
>>
>> I see no problem with makeRange. It seems like a sensible name to me.
>> You're
>> taking a sequence of elements and making a range out of them.
>
> I swear I'd just call it "range".
>
> Andrei
>

tuple(1, 2, 3).rangeOf

On Tue, Jul 10, 2012 at 3:35 AM, Jacob Carlborg <doob@me.com> wrote:

> On 2012-07-10 08:59, Dmitry Olshansky wrote:
>
>  Can you do it in other languages?
>>
>
> Sure, in Ruby, but that only works on arrays:
>
> p [5, 3, 5, 6, 8].uniq.map{ |e| e.to_s }.sort
>
> Prints:
>
> ["3", "5", "6", "8"]
>
> --
> /Jacob Carlborg
>

For what it's worth:

    e = 10_000_000
    a = ((1..e).to_a + (1..e).to_a).sort.uniq.map{ |e| e }

Runs in 21,320 ms on my machine with Ruby 1.9.3 whereas:

    auto end = 10_000_000;
    auto a = chain(iota(1, end), iota(1, end)).array()
                .sort()
                .uniq()
                .map!(n=>n).array();

Runs in 3,057ms with DMD 2.059.  I believe they are largely equivalent but there is probably room for improvement on both.  I removed to_s/to!string because I didn't want it allocation bound since we are talking about algorithm and not the GC or string conversion (with string conversion the numbers are 28,646ms for Ruby and 14,113ms for D).

Regards,
Brad Anderson

On 2012-07-10 19:23, Daniel Murphy wrote:

> writeln([1, 2, 3].map!"a"()[2]);
>
> Sort is in place, and therefore requires more than random access, you need
> to be able to modify the data you're operating on.
>
> Something like [3, 4].map!func().selectionSort() could work lazily without
> needing to modify the original range, but urrgh.

Ok, I think I get it now.

-- 
/Jacob Carlborg

On 2012-07-10 19:55, Andrei Alexandrescu wrote:

> Clearly this and any documentation can be improved, but I'd say if it
> says "range" there there's no assumption "sorted range" there. I think
> the main thing that could be expressed better is "unique consecutive".

Fair enough.

>
> I think it would be onerous to mention for each algorithm, although
> clearly they all are generic, that they can handle ranges with any
> element type.
>
>> You see how stupid that is.
>
> That being what?

I was trying to point out that one cannot assume how a function behaves just by looking at one example. Specially not a template function.

-- 
/Jacob Carlborg

On 2012-07-10 19:30, Jonathan M Davis wrote:

> typeof(bar()) x;
>
> works. But regardless, given that you're dealing with a return type which is
> auto, there's really no other choice. Even if we weren't using voldemort types
> for stuff like map, the return type would still be templated and depend on the
> actual arguments to map, making writing the type a pain - especially if it's
> complicated; until (which _doesn't_ use a voldemort type) is a prime example
> of this. You end up with something like Until!("a == b",int[],int) for a basic
> call to until, and it gets really nasty if you start chaining function calls
> so that the range passed to Until is far more complicated than int[]. Using
> ReturnType and typeof becames the sane thing to do (and much more maintainable
> too, since you don't have to change it if/when you change the call to map
> enough that it's return type changes). It does take some getting used to, but
> it works very well. You just have to realize that if you're operating on
> ranges, you're generally _not_ caring what they exact type is, and you use
> auto and templates a lot. Sometimes converting the result to an array is
> exactly what you want to do, but the less you do that, the more efficient your
> code will be.

First, both using typeof and ReturnType forces me to have the instance variable below the method due to otherwise forward reference errors. Which I really, really don't like.

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.

-- 
/Jacob Carlborg

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.

-- 
/Jacob Carlborg

On 2012-07-10 20:53, Brad Anderson wrote:

> For what it's worth:
>
>      e = 10_000_000
>      a = ((1..e).to_a + (1..e).to_a).sort.uniq.map{ |e| e }
>
> Runs in 21,320 ms on my machine with Ruby 1.9.3 whereas:
>
>      auto end = 10_000_000;
>      auto a = chain(iota(1, end), iota(1, end)).array()
>                  .sort()
>                  .uniq()
>                  .map!(n=>n).array();
>
> Runs in 3,057ms with DMD 2.059.  I believe they are largely equivalent
> but there is probably room for improvement on both.  I removed
> to_s/to!string because I didn't want it allocation bound since we are
> talking about algorithm and not the GC or string conversion (with string
> conversion the numbers are 28,646ms for Ruby and 14,113ms for D).
>

For me, using Ruby 1.9.2 and DMD 2.059, D is only just under 10 seconds faster.

-- 
/Jacob Carlborg

On Tuesday, 10 July 2012 at 00:17:12 UTC, Timon Gehr wrote:
> I have heard that rumour, but TDPL wisely specifies the behaviour of
> the @property attribute as follows:
>
> 'In particular "property" is recognized by the the compiler
> and signals the fact that the function bearing such an attribute must be called without the trailing ().'
>
> That is exactly the behaviour I described.
>
> Note that this sentence includes the notion of _calling a function_
> without the trailing () and it even seems to express that the trailing
> () is usually optional.

No it doesn't. It does have emphasis with 'must' and this likely comes from D having such a long history of the optional (),  but that does not make this statement include such a notion.

> So TDPL actually describes a subset of what I have in mind. (it seems
> to leave out the function = argument case completely.) We should
> therefore change where we are headed.

The -property is an implementation of what is to come. I was never greatly for property but since we have it it should be fully enforced, otherwise we may as well just drop it.

On Tue, Jul 10, 2012 at 1:22 PM, Jacob Carlborg <doob@me.com> wrote:

> On 2012-07-10 20:53, Brad Anderson wrote:
>
>  For what it's worth:
>>
>>      e = 10_000_000
>>      a = ((1..e).to_a + (1..e).to_a).sort.uniq.map{ |e| e }
>>
>> Runs in 21,320 ms on my machine with Ruby 1.9.3 whereas:
>>
>>      auto end = 10_000_000;
>>      auto a = chain(iota(1, end), iota(1, end)).array()
>>                  .sort()
>>                  .uniq()
>>                  .map!(n=>n).array();
>>
>> Runs in 3,057ms with DMD 2.059.  I believe they are largely equivalent but there is probably room for improvement on both.  I removed to_s/to!string because I didn't want it allocation bound since we are talking about algorithm and not the GC or string conversion (with string conversion the numbers are 28,646ms for Ruby and 14,113ms for D).
>>
>>
> For me, using Ruby 1.9.2 and DMD 2.059, D is only just under 10 seconds faster.
>
> --
> /Jacob Carlborg
>
>
>
I used -O -inline -noboundscheck -release -d to build.

Regards,
Brad Anderson

On 07/10/2012 09:36 PM, Jesse Phillips wrote:
> On Tuesday, 10 July 2012 at 00:17:12 UTC, Timon Gehr wrote:
>> I have heard that rumour, but TDPL wisely specifies the behaviour of
>> the @property attribute as follows:
>>
>> 'In particular "property" is recognized by the the compiler
>> and signals the fact that the function bearing such an attribute must
>> be called without the trailing ().'
>>
>> That is exactly the behaviour I described.
>>
>> Note that this sentence includes the notion of _calling a function_
>> without the trailing () and it even seems to express that the trailing
>> () is usually optional.
>
> No it doesn't. It does have emphasis with 'must' and this likely comes
> from D having such a long history of the optional (), but that does not
> make this statement include such a notion.
>

I'm sure a lawyer could make a good case out of it. Anyway, TDPL
clearly does not document the broken -property behaviour.

>> So TDPL actually describes a subset of what I have in mind. (it seems
>> to leave out the function = argument case completely.) We should
>> therefore change where we are headed.
>
> The -property is an implementation of what is to come. I was never
> greatly for property but since we have it it should be fully enforced,
> otherwise we may as well just drop it.

I think you may be misunderstanding what @property is about.

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.