www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: ch-ch-changes

reply Jason House <jason.james.house gmail.com> writes:
Andrei Alexandrescu Wrote:


 I've worked valiantly on defining the range infrastructure and making 
 std.algorithm work with it. I have to say that I'm even more pleased 
 with the result than I'd ever expected when I started. Ranges and 
 concepts really make for beautiful code, and I am sure pretty darn 
 efficient too.
 
 There's a lot to sink one's teeth in, but unfortunately the code hinges 
 on a compiler fix that Walter was kind enough to send me privately. I 
 did document the work, but the documentation doesn't really make justice 
 to the extraordinary possibilities that lay ahead of us. Anyhow, here's 
 a sneak preview into the up-and-coming ranges and their algorithms.
 
 http://ssli.ee.washington.edu/~aalexand/d/web/phobos/std_range.html
 http://ssli.ee.washington.edu/~aalexand/d/web/phobos/std_algorithm.html
 
 Ranges are easy to define and compose efficiently. It was, however, a 
 pig to get a zip(r1, r2, ...) working that can mutate back the ranges it 
 iterates on. With that, it's very easy to e.g. sort multiple arrays in 
 parallel. Similarly, chain(r1, r2, ...) is able to offer e.g. random 
 iteration if all components offer it, which means that you can do crazy 
 things like sorting data that sits partially in one array and partially 
 in another.
 
 Singly-linked list ranges are in, and to my soothing I found an answer 
 to the container/range dichotomy in the form of a topology policy. A 
 range may or may not be able to modify the topology of the data it's 
 iterating over; if it can, it's a free-standing range, much like 
 built-in arrays are. If it can't, it's a limited range tied to a 
 container (of which I defined none so far, but give me time) and it's 
 only the container that can mess with the topology in controlled ways. 
 More on that later.
 
 Feedback welcome.
 
 
 Andrei



I think algorithm signatures should not be made unnecessarily complex, and
instead rely on other utilities for complex behavior.  For example
map!("a*a")(r1,r2) can be implemented as map!("a*a")(chain(r1,r2))

I also see in the docs that the structs returned are documented, complete with
all the functions that they include.  I'd hope that we could somehow document
this stuff simpler... 

Maybe the following?
outputRangeType!(r) map!(fun)(r)

note also how accepting only one range also makes documenting the return type
easier ;)
Jan 28 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jason House wrote:

 I think algorithm signatures should not be made unnecessarily
 complex, and instead rely on other utilities for complex behavior.
 For example map!("a*a")(r1,r2) can be implemented as
 map!("a*a")(chain(r1,r2))



Yah, good point. I'm ambivalent about that. On one hand composition is 
nice, on the other hand map is likely to be used very often so a 
shortcut is welcome. What do others think?


 I also see in the docs that the structs returned are documented,
 complete with all the functions that they include.  I'd hope that we
 could somehow document this stuff simpler...
 
 Maybe the following? outputRangeType!(r) map!(fun)(r)
 
 note also how accepting only one range also makes documenting the
 return type easier ;)



I'm waiting for that "auto" return feature to work with ddoc...


Andrei
Jan 28 2009
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Andrei Alexandrescu Wrote:


 Jason House wrote:

 I think algorithm signatures should not be made unnecessarily
 complex, and instead rely on other utilities for complex behavior.
 For example map!("a*a")(r1,r2) can be implemented as
 map!("a*a")(chain(r1,r2))



 Yah, good point. I'm ambivalent about that. On one hand composition is 
 nice, on the other hand map is likely to be used very often so a 
 shortcut is welcome. What do others think?



Very often with multiple ranges? I wonder how well dmd will inline/optimize
when composing simple things like that.

 


 I also see in the docs that the structs returned are documented,
 complete with all the functions that they include.  I'd hope that we
 could somehow document this stuff simpler...
 
 Maybe the following? outputRangeType!(r) map!(fun)(r)
 
 note also how accepting only one range also makes documenting the
 return type easier ;)



 I'm waiting for that "auto" return feature to work with ddoc...



That really has very little to do with the point I was trying to make. The
return type will conform to a certain range type, which is all I will ever want
to know as a user.
Jan 28 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jason House wrote:

 Andrei Alexandrescu Wrote:
 

 Jason House wrote:

 I think algorithm signatures should not be made unnecessarily
 complex, and instead rely on other utilities for complex behavior.
 For example map!("a*a")(r1,r2) can be implemented as
 map!("a*a")(chain(r1,r2))



 nice, on the other hand map is likely to be used very often so a 
 shortcut is welcome. What do others think?



 Very often with multiple ranges? I wonder how well dmd will inline/optimize
when composing simple things like that.
 
  
 

 I also see in the docs that the structs returned are documented,
 complete with all the functions that they include.  I'd hope that we
 could somehow document this stuff simpler...

 Maybe the following? outputRangeType!(r) map!(fun)(r)

 note also how accepting only one range also makes documenting the
 return type easier ;)






 That really has very little to do with the point I was trying to make. The
return type will conform to a certain range type, which is all I will ever want
to know as a user.



Oh, I see now. Well, we don't have that in D today.

Andrei
Jan 28 2009
parent Jason House <jason.james.house gmail.com> writes:
Andrei Alexandrescu Wrote:


 Jason House wrote:

 Andrei Alexandrescu Wrote:
 

 Jason House wrote: 



 

 I also see in the docs that the structs returned are documented,
 complete with all the functions that they include.  I'd hope that we
 could somehow document this stuff simpler...

 Maybe the following? outputRangeType!(r) map!(fun)(r)

 note also how accepting only one range also makes documenting the
 return type easier ;)






 That really has very little to do with the point I was trying to make. The
return type will conform to a certain range type, which is all I will ever want
to know as a user.



 Oh, I see now. Well, we don't have that in D today.
 
 Andrei



When has that ever stopped the D community? :)
Jan 28 2009
prev sibling next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Andrei Alexandrescu wrote:

 Jason House wrote:

 I think algorithm signatures should not be made unnecessarily
 complex, and instead rely on other utilities for complex behavior.
 For example map!("a*a")(r1,r2) can be implemented as
 map!("a*a")(chain(r1,r2))



 Yah, good point. I'm ambivalent about that. On one hand composition is
 nice, on the other hand map is likely to be used very often so a
 shortcut is welcome. What do others think?



Actually, my first instinct looking at this is to assume that it should
be this:

map!("a*b")(r1,r2);

Every time I've used map, multiple sequences translated to multiple
arguments of the operation.

It's really a question of style, but I think in this case it might be
worth disallowing multiple arguments since it's not clear which
behaviour it has.

(That or change it to use the behaviour -I- expect, but that's just
being selfish :D )


 I also see in the docs that the structs returned are documented,
 complete with all the functions that they include.  I'd hope that we
 could somehow document this stuff simpler...

 Maybe the following? outputRangeType!(r) map!(fun)(r)

 note also how accepting only one range also makes documenting the
 return type easier ;)



 I'm waiting for that "auto" return feature to work with ddoc...



Me, I prefer cheating like a bastard...

version( DDoc )
{
    /// Stuff!  Information!  Cookies!
    RangeOf!(R) map!(Predicate)(RangeOf!(R));
}
else
{
    ReallyLongHorriblyComplex!(TemplateWithNested!(R,ThingsIn!(It))) ...
}

  -- Daniel
Jan 28 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Brian wrote:

 Actually, my first instinct looking at this is to assume that it should
 be this:

 map!("a*b")(r1,r2);



 same here, i would much prefer it to be explicit.



Alrighty then, I'll operate the change. I'll leave the ability to 
specify multiple functions though, that's rather verbose when expanded.

auto r = map!("a*b", "a/b")(chain(r1, r2));

returns a range of 2-tuples.


Andrei
Jan 29 2009
prev sibling parent Brian <digitalmars brianguertin.com> writes:
 Actually, my first instinct looking at this is to assume that it should
 be this:
 
 map!("a*b")(r1,r2);



same here, i would much prefer it to be explicit.
Jan 29 2009