www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - New ranges and algorithms

reply Philippe Sigaud <philippe.sigaud gmail.com> writes:
Hello,

I posted to digitalmars.D a month ago to present some modules on ranges and
algorithms but I didn't have a repository at the time. Here it is now:

http://www.dsource.org/projects/dranges/

Dranges is a small project to bring some new ranges and algorithms to D. Its
main source of inspiration is

    * D2 std.range and std.algorithm
    * functions/actions on sequences found in other languages, like Haskell,
Clojure, Python and Scala. 

Mainly, it's a way for me to understand ranges, algorithms on sequences and (a
part of) the functional programming paradigm. It's really a 'learn as you go'
project, so if you're interested in looking at the code, don't hesitate to tell
me how it can be improved. I'm pretty sure it can!

As of this writing, dranges is divided into eight modules:

The first three are the main modules:
    * range2.d, which contains new higher order ranges (drop, dropWhile,
takeWhile, knit...)
    * algorithm2.d, containing extensions on map/filter/reduce and some other
algorithm like list comprehensions, unfold, iterate, etc.
    * phobos_extension.d, which proposes modification of std.range and
std.algorithm functions: map (adding back/popBack/opIndex/length), filter
(back/popBack) and some bug corrections to take and other functions (bugs
declaration on puremagic will follow.) 

The five other modules are just there to help.
    * traits2.d,  some traits used by the first two modules (acting on type
tuples)
    * functional2.d, also bringing some support for range2 and algorithm2:
mainly transforming strings into n-ary functions (a generalization of unaryFun
and binaryFun)
    * tuple2.d, functions on tuples (reversing, extracting, glueing, appending,
etc.)
    * predicate.d, to bring together all predicates (boolean-returning
functions)
    * tree.d a small module, just for me to understand how to iterate on binary
trees.


  Philippe
Dec 21 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Philippe Sigaud:
 http://www.dsource.org/projects/dranges/

This can improve Phobos2 some. But it's really important that functions written by Andrei, you and other people are tested inside real code (even better is when real code asks for their creation, so they are born from practical necessity). Because it's easy to invent functions that are not easy to remember, not useful enough, that are not flexible enough, that are too much flexible, etc. The "API" must be small otherwise it's hard to remember the functions and their names, but it has to be flexible enough, etc. Bye, bearophile
Dec 21 2009
parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
bearophile Wrote:

 Philippe Sigaud:
 http://www.dsource.org/projects/dranges/

This can improve Phobos2 some. But it's really important that functions written by Andrei, you and other people are tested inside real code (even better is when real code asks for their creation, so they are born from practical necessity).

Well,it's born from my own needs indeed, if that's reassuring. As far as possible, when I found something useful, I tried to factor it into different generic parts and put them there. Now, my needs are strictly personal (at one times, that was to do the Euler Project problems) and my job is quite far away from these considerations. I don't consider this to be 'real life' indeed. But I regularly find myself in need of mapping n ranges in lockstep or filtering them, or extracting n-elements subranges from a range, so I gather some functions there could be useful. And you can find equivalent functions in nearly all PL that have a concept of sequence/range. So I found it interesting to write them in D, to get some feeling as to how it could be done.
Because it's easy to invent functions that are not easy to remember, not useful
enough, 
that are not flexible enough, that are too much flexible, etc. 
The "API" must be small otherwise it's hard to remember the functions and their
names, 
but it has to be flexible enough, etc.

Hmm, yes? Can you tell me if you think the 'API' is OK? API is a big word for simple 1-2 parameters functions. I guess that, if people understand take(2, range) they will understand merge(range1, range2) or combinations(range1, range2, range3)... I think we already had this discussion. For me, it's a three-steps process 1- get the code to do what I need right now 2- come back later, see the common patterns, factor them away and make them generic 3- then, when common uses come again and again, write a function that associate the generic function in a useful, practical, commonly-used way. But, you know, I'm still learning while doing this project, so I'm pretty sure there still much room for improvements. Philippe
Dec 22 2009