On Sun, Nov 8, 2009 at 22:43, dsimcha <dsimcha@yahoo.com> wrote:

>
> Hot off the press and VERY prototype-ish:
>
> Code:
> http://pastebin.com/m2087e524
>
> Docs: http://cis.jhu.edu/~dsimcha/unpackEnumerate.html<http://cis.jhu.edu/%7Edsimcha/unpackEnumerate.html>
>
> Cool! Thanks a lot.

I looked at opApply for D1 maybe two years ago, but never used it myself. I'll go and read this part of the docs.

*test it*

Hmm, I can get enumerate to work, but the Unpack part doesn't compile. It complains elem.at!(0) is not an lvalue.

You know, the Proxy part of std.range.zip is really annoying. I'd prefer zip to return std.typecons.Tuples, even if that means stopping at the shortest range. That's what other languages do and it seems enough for most uses.


Does this look like a good addition to std.range?  The elegance of it is it
> solves
> the problem of providing syntactic sugar to ranges w/ zero ripple effects
> either
> in the compiler or in the rest of Phobos.  I'll file it somewhere more
> official
> after people review it a little and refine the idea, but I definitely think
> something similar to this has a legit place in std.range.
>
> If you're wondering how unpack works and don't want to grovel through all
> the
> code, it's tons of string mixin magic.  That's about the only way I was
> able to
> make it work.
>

I'll read it with pleasure(!). I'm there to learn anyway.Heck, I can't read my own string mixins a week after writing them, so it'll be a good exercise.

As to making it an addition to std.range, I'm all for it. If people don't want to use it because they are leery of using opApply, too bad for them. Your small benchmark was interesting: overhead exists, but it's not awful.

  Philippe

== Quote from Philippe Sigaud (philippe.sigaud@gmail.com)'s article
> --0016e6d99ba70494130478196284
> Content-Type: text/plain; charset=ISO-8859-1
> On Sun, Nov 8, 2009 at 22:43, dsimcha <dsimcha@yahoo.com> wrote:
> >
> > Hot off the press and VERY prototype-ish:
> >
> > Code:
> > http://pastebin.com/m2087e524
> >
> > Docs:
> >
http://cis.jhu.edu/~dsimcha/unpackEnumerate.html<http://cis.jhu.edu/%7Edsimcha/unpackEnumerate.html>
> >
> > Cool! Thanks a lot.
> I looked at opApply for D1 maybe two years ago, but never used it myself.
> I'll go and read this part of the docs.
> *test it*
> Hmm, I can get enumerate to work, but the Unpack part doesn't compile. It
> complains elem.at!(0) is not an lvalue.

Argh.  That's because I was hacking around with Zip in my copy of Phobos right before I wrote this lib and forgot to change some stuff back to stock when testing.  If you uncomment a /*ref*/ in there somewhere, which was leftover from a compiler bug a long time ago, it seems to work.  The real problem is that that bit of cruft hasn't been removed from Phobos yet.

On Wed, Nov 11, 2009 at 16:48, dsimcha <dsimcha@yahoo.com> wrote:


> > *test it*
> > Hmm, I can get enumerate to work, but the Unpack part doesn't compile. It
> > complains elem.at!(0) is not an lvalue.
>
> Argh.  That's because I was hacking around with Zip in my copy of Phobos
> right
> before I wrote this lib and forgot to change some stuff back to stock when
> testing.


How do you deal with successive version of DMD? Do you have parallel installations? I know I hacked around Zip, Chain and such a few times, forgot about it, only to have it crushed by my next download :-(


>  If you uncomment a /*ref*/ in there somewhere, which was leftover from a
> compiler bug a long time ago, it seems to work.  The real problem is that
> that bit
> of cruft hasn't been removed from Phobos yet.
>

OK, thanks.
I get the impression that ref is viral... Either you have it everywhere or
it'll block some compositions (chain(map() ...) . I'm wrong?

Thanks again for your code, I'll test it and tell you how it went.

  Philippe

On Wed, Nov 11, 2009 at 17:44, Philippe Sigaud <philippe.sigaud@gmail.com>wrote:

> On Wed, Nov 11, 2009 at 16:48, dsimcha <dsimcha@yahoo.com> wrote:
>
>>  If you uncomment a /*ref*/ in there somewhere, which was leftover from a
>> compiler bug a long time ago, it seems to work.  The real problem is that
>> that bit
>> of cruft hasn't been removed from Phobos yet.
>>
>
So, it works. Thanks!

Strangely, on my computer it's frequently faster to use your enumerate than
a raw range (re: your speed tests). Is there something I don't get? I
thought (ie: read here) that opApply was slower than other means of
iteration?
My own enumerate, which produces a tuple(uint, T) as a lazy range is thrice
as slow :(


And, I just discovered that I can simply unpack a tuple with .field or .expand.

auto t = tuple('a',1, 2.0);
int foo(char a, int b, double c) { return to!int(a) * b * to!int(c);}
foo(t.expand) ; // works.

Is that common knowledge? It'd be nice addition to the std.typecons docs.

 Gosh, when I think of the time I spent to find a way to extract this
information with template recursion, to map a n-ary function on
tuple-producing ranges. And all this time, I could have done tuple-mapping
as a simple map on "foo(a.expand)".
Time for some heavy refactoring...

  Philippe