<div class="gmail_quote">On Mon, Nov 2, 2009 at 10:14, bearophile <span dir="ltr"><<a href="mailto:bearophileHUGS@lycos.com">bearophileHUGS@lycos.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Philippe Sigaud:<br>
<br>
Hello, it seems you have re-done with ranges for D2 a good amount of things I did for D1:<br>
<a href="http://www.fantascienza.net/leonardo/so/libs_d.zip" target="_blank">http://www.fantascienza.net/leonardo/so/libs_d.zip</a><br>
<br></blockquote><div>Ah yes, I meant to look at your libraries, but forgot to do it. I'll have a look right now, to see how you solved some problems. <br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
- bimap/nmap/map: having a single map able to do all that is better. The same for filters.<br></blockquote><div><br>Well, yes and no. It has grown organically, from the simple structs (mapping and filtering with binary functions) to the more complex ones. I have a few other ranges I want to do and then will begin the cutting down and refactoring. I coded a range segmentation as delays on a zip-range tonight (thanks Andrei for the idea!) and it seems to work. That will allow me to factor some things away.<br>
<br>Also, I like having generic and adaptative functions as much as the next guy, but when I tried to put every functionality inside one struct, it became some kind of godzilla of static ifs. So right now, I prefer having some specialised functions to do a more precise work, sometimes even more efficiently, that I can (theoritically) plug one into another.<br>
<br>And, right now, I'm limited by the fact that templates can only have one variadic type, for self-evident reasons. So you cannot have both <br><br>* map!(fun1, fun2, fun3...)(r) behavior (mapping one range with a tuple of functions) that is, std.algo.map behavior, and,<br>
* map!(fun, R...)(R manyRanges) (mapping one function on many ranges in parallel).<br><br> because the ... part in the template can exist only once. <br>map(fun..., R ...)(R ranges) cannot exist. Well it can, but that means separating the funs from the ranges by filtering on the variadic arguments at compile time and I'm a bit leery of doing this, for not that much functionality added.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
- setComprehension: better to have a set(range).<br></blockquote><div><br>I'm afraid I disagree. I would expect set(range) to create a Set collection or to transform a range into a set (I called that asSet!R)<br>And anyway, I guess I'll just provide an asSet!R wrapper on one hand and comprehension on the other hand.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
- comprehension: see select() in my dlibs.<br></blockquote><div><br>I will and gladly, because I'd like to know how you've tackled some problems. <br><br>Right now, the comprehension range I propose can do all the computations you'll see everywhere on blogs and wikipedia:<br>
<br>// python<br>S = (2*x for x in count() if x**2 > 3)<br>// D<br>auto S = comprehension!("2*a", "a*a>3")(numbers());<br><br>But not the rebindings:<br>// Scala<br>for (p <- persons; if !p.isMale; c <- p.children) yield (<a href="http://c.name">c.name</a>, <a href="http://p.name">p.name</a>)<br>
<br>There, c comes from p.children, which is a list created anew for each p. It means that inside the for expression, p can be used to create new ranges.<br><br>Obviously, I can nest the standard comprehensions (first generating the p's, then the c's from the p and creating the tuples(p,c) from there). But I gather I can have it done internally, with a combinations of flatMap and such.<br>
<br><br> Philippe<br></div></div>