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