www.digitalmars.com         C & C++   DMDScript  

D - implicit length/end now a must, well almost

reply "Matthew" <matthew stlsoft.org> writes:
A bit more DTL ranges, involving slices:

    foreach(int i; range(-10, 10, +1)[6 .. 12])
    {
        printf("%d ", i);
    }

This prints out

    -4 -3 -2 -1 0 1

To slice from the beginning, we would start with 0, as in:

    foreach(int i; range(-10, 10, +1)[0 .. 12])

This prints out

    -10 -9 -8 -7 -6 -5 -4 -3 -2 -1 0 1

But to go to the end from, say, the third element, what do we do?

    foreach(int i; range(-10, 10, +1)[3 .. ??])

Now of course we can calculate it by the following:

    foreach(int i; range(-10, 10, +1)[3 .. range(-10, 10, +1).length])

But it's not very succinct, is it? It's pretty confusing to look at for me,
so I'm guessing people who aren't familiar with it would have a hard time.

Maybe we can use "with", somehow, as in

    foreach(int i; with range(-10, 10, +1)[3 .. length])

or

    foreach(int i; with range(-10, 10, +1)[3 .. object.length])

where "object" would be a reserved word and would refer to the current
with'd instance.

Thoughts?
Mar 21 2004
next sibling parent reply Ben Hinkle <bhinkle4 juno.com> writes:
[snip]

Maybe we can use "with", somehow, as in

    foreach(int i; with range(-10, 10, +1)[3 .. length])

or

    foreach(int i; with range(-10, 10, +1)[3 .. object.length])

where "object" would be a reserved word and would refer to the current
with'd instance.

Thoughts?



Seems like a simple work-around is to assign the range to a variable
and get the length of that. I don't think creating a range and
slicing it in the same expression is common.

Talking about ranges inspired me to play around with structs and
overloading. D is just too much fun. Here's a stab at a range struct
for indexing arrays. I hope this is roughly what you had in mind
for use cases for ranges. I couldn't find a nice API for overloading
the slicing of an arbitrary array type using ranges so I just
made it a template and defined some overloaded convience functions.


/** A range of ints a, a+step, a+2*step,..., b */
struct range {
   int a,b,step;

   /** Constructor (using Stewart Gordon's trick) */
   static range opCall(int a,int b,int step) {
      range t;
      t.a = a;
      t.b = b;
      t.step = step;
      return t;
   }

   /** Constructor with implicit step of 1 */
   static range opCall(int a,int b) {
      return range(a,b,1);
   }

   /** Length property */
   uint length() {
      int res = (b-a+1)/step; // overflow?
      return res>0?res:0;
   }

   /** Index operator */
   int opIndex(int x) {
      return a+x*step;
   }

   /** Slice operator */
   range opSlice(int x, int y) {
      return range(a+x*step, a+y*step,step);
   }
   
   /** Foreach iteration */
   int opApply(int delegate(inout int val) dg) {
      int res = 0;
      for (int k=a; k<b; k+=step) {
	 res = dg(k);
	 if (res)
	    break;
      }
      return res;
   }
}

template TStepSlice(T:T[]) {

   /** Slice and extract an array x of type T[] by range r */
   T[] slice(T[] x, range r) {
      uint len = r.length;
      int ind = r.a;
      T[] res = new T[len];
      for (int k; k<len; k++, ind+=r.step )
	 res[k] = x[ind];
      return res;
   }

}

// conveniece functions
double[] slice(double[] x, range r) {
   return TStepSlice!(double[]).slice(x,r);
}
int[] slice(int[] x, range r) {
   return TStepSlice!(int[]).slice(x,r);
}
// ...etc

int 
main()
{
   // make the array x we are going to slice
   double[10] x;
   for (int k=0;k<10;k++) x[k] = k;
   // print out x
   foreach (double val; x)
      printf("%f ", val);
   printf("\n");

   // slice x using a range
   double[] y = slice(x,range(0,10,2));

   // print out the result
   foreach (double val; y)
      printf("%f ", val);
   printf("\n");

   // index into a range
   range r = range(3,9,2);      // 3,5,7
   printf("r[1] = %d\n",r[1]);

   // slice a range
   range r2 = r[1 .. r.length]; // 5,7

   // print out the result
   foreach (int val; r2)
      printf("%d ", val);
   printf("\n");

   return 0;
}
Mar 21 2004
parent "Matthew" <matthew stlsoft.org> writes:
That looks a whole lot like std.dtl.ranges.IntegralRange!(). :)


"Ben Hinkle" <bhinkle4 juno.com> wrote in message
news:gqbr5016l0ajrvg5h5f1f4jbql4c7nok2p 4ax.com...

 [snip]

Maybe we can use "with", somehow, as in

    foreach(int i; with range(-10, 10, +1)[3 .. length])

or

    foreach(int i; with range(-10, 10, +1)[3 .. object.length])

where "object" would be a reserved word and would refer to the current
with'd instance.

Thoughts?



 Seems like a simple work-around is to assign the range to a variable
 and get the length of that. I don't think creating a range and
 slicing it in the same expression is common.

 Talking about ranges inspired me to play around with structs and
 overloading. D is just too much fun. Here's a stab at a range struct
 for indexing arrays. I hope this is roughly what you had in mind
 for use cases for ranges. I couldn't find a nice API for overloading
 the slicing of an arbitrary array type using ranges so I just
 made it a template and defined some overloaded convience functions.


 /** A range of ints a, a+step, a+2*step,..., b */
 struct range {
    int a,b,step;

    /** Constructor (using Stewart Gordon's trick) */
    static range opCall(int a,int b,int step) {
       range t;
       t.a = a;
       t.b = b;
       t.step = step;
       return t;
    }

    /** Constructor with implicit step of 1 */
    static range opCall(int a,int b) {
       return range(a,b,1);
    }

    /** Length property */
    uint length() {
       int res = (b-a+1)/step; // overflow?
       return res>0?res:0;
    }

    /** Index operator */
    int opIndex(int x) {
       return a+x*step;
    }

    /** Slice operator */
    range opSlice(int x, int y) {
       return range(a+x*step, a+y*step,step);
    }

    /** Foreach iteration */
    int opApply(int delegate(inout int val) dg) {
       int res = 0;
       for (int k=a; k<b; k+=step) {
 res = dg(k);
 if (res)
     break;
       }
       return res;
    }
 }

 template TStepSlice(T:T[]) {

    /** Slice and extract an array x of type T[] by range r */
    T[] slice(T[] x, range r) {
       uint len = r.length;
       int ind = r.a;
       T[] res = new T[len];
       for (int k; k<len; k++, ind+=r.step )
 res[k] = x[ind];
       return res;
    }

 }

 // conveniece functions
 double[] slice(double[] x, range r) {
    return TStepSlice!(double[]).slice(x,r);
 }
 int[] slice(int[] x, range r) {
    return TStepSlice!(int[]).slice(x,r);
 }
 // ...etc

 int
 main()
 {
    // make the array x we are going to slice
    double[10] x;
    for (int k=0;k<10;k++) x[k] = k;
    // print out x
    foreach (double val; x)
       printf("%f ", val);
    printf("\n");

    // slice x using a range
    double[] y = slice(x,range(0,10,2));

    // print out the result
    foreach (double val; y)
       printf("%f ", val);
    printf("\n");

    // index into a range
    range r = range(3,9,2);      // 3,5,7
    printf("r[1] = %d\n",r[1]);

    // slice a range
    range r2 = r[1 .. r.length]; // 5,7

    // print out the result
    foreach (int val; r2)
       printf("%d ", val);
    printf("\n");

    return 0;
 }
Mar 23 2004
prev sibling next sibling parent reply Ant <duitoolkit yahoo.ca> writes:
On Sun, 21 Mar 2004 09:18:56 +0000, Matthew wrote:


 A bit more DTL ranges, involving slices:
 
     foreach(int i; range(-10, 10, +1)[6 .. 12])
     foreach(int i; range(-10, 10, +1)[3 .. ??])
     foreach(int i; range(-10, 10, +1)[3 .. range(-10, 10, +1).length])
     foreach(int i; with range(-10, 10, +1)[3 .. length])
     foreach(int i; with range(-10, 10, +1)[3 .. object.length])
 Thoughts?


carefull this are my thoughts, you ask for it.

you lost it!

Isn't this a solution looking for a problem?
I notice that again when I browse one of your
columns on the online magazine.

No sane human will code that, it might be usefull
if you are generating code from a program,
but make sure the code generator is so good
that nobody will ever need to maintain the prog.

get a grip

well these are my thoughts. I warn you :)

Ant
Mar 21 2004
next sibling parent reply Ben Hinkle <bhinkle4 juno.com> writes:
On Sun, 21 Mar 2004 11:23:59 -0500, Ant <duitoolkit yahoo.ca> wrote:


On Sun, 21 Mar 2004 09:18:56 +0000, Matthew wrote:


 A bit more DTL ranges, involving slices:
 
     foreach(int i; range(-10, 10, +1)[6 .. 12])
     foreach(int i; range(-10, 10, +1)[3 .. ??])
     foreach(int i; range(-10, 10, +1)[3 .. range(-10, 10, +1).length])
     foreach(int i; with range(-10, 10, +1)[3 .. length])
     foreach(int i; with range(-10, 10, +1)[3 .. object.length])
 Thoughts?


carefull this are my thoughts, you ask for it.

you lost it!

Isn't this a solution looking for a problem?
I notice that again when I browse one of your
columns on the online magazine.

No sane human will code that, it might be usefull
if you are generating code from a program,
but make sure the code generator is so good
that nobody will ever need to maintain the prog.

get a grip

well these are my thoughts. I warn you :)

Ant


Ouch! harsh words, Ant. I don't agree with everything
Matthew proposes (see Vector, etc) but he doesn't deserve
to get flamed.

-Ben
Mar 21 2004
next sibling parent reply Ant <duitoolkit yahoo.ca> writes:
On Sun, 21 Mar 2004 11:34:51 -0500, Ben Hinkle wrote:


 
 On Sun, 21 Mar 2004 11:23:59 -0500, Ant <duitoolkit yahoo.ca> wrote:
 

On Sun, 21 Mar 2004 09:18:56 +0000, Matthew wrote:


 A bit more DTL ranges, involving slices:
 
     foreach(int i; range(-10, 10, +1)[6 .. 12])
     foreach(int i; range(-10, 10, +1)[3 .. ??])
     foreach(int i; range(-10, 10, +1)[3 .. range(-10, 10, +1).length])
     foreach(int i; with range(-10, 10, +1)[3 .. length])
     foreach(int i; with range(-10, 10, +1)[3 .. object.length])
 Thoughts?


carefull this are my thoughts, you ask for it.

you lost it!

Isn't this a solution looking for a problem?
I notice that again when I browse one of your
columns on the online magazine.

No sane human will code that, it might be usefull
if you are generating code from a program,
but make sure the code generator is so good
that nobody will ever need to maintain the prog.

get a grip

well these are my thoughts. I warn you :)

Ant


 
 Ouch! harsh words, Ant. I don't agree with everything
 Matthew proposes (see Vector, etc) but he doesn't deserve
 to get flamed.
 
 -Ben


Those are my thought, I put the first and last sentence to
try to make it lighter because every thing I write sounds
more harsh then I intended. I just can't write better in
english...
I also put the ":)" at the end...

don't take it that "harsh", Matthew, guys...

Ant
Mar 21 2004
parent reply "Matthew" <matthew stlsoft.org> writes:
"Ant" <duitoolkit yahoo.ca> wrote in message
news:pan.2004.03.21.16.43.50.708896 yahoo.ca...

 On Sun, 21 Mar 2004 11:34:51 -0500, Ben Hinkle wrote:


 On Sun, 21 Mar 2004 11:23:59 -0500, Ant <duitoolkit yahoo.ca> wrote:


On Sun, 21 Mar 2004 09:18:56 +0000, Matthew wrote:


 A bit more DTL ranges, involving slices:

     foreach(int i; range(-10, 10, +1)[6 .. 12])
     foreach(int i; range(-10, 10, +1)[3 .. ??])
     foreach(int i; range(-10, 10, +1)[3 .. range(-10, 10, +1).length])
     foreach(int i; with range(-10, 10, +1)[3 .. length])
     foreach(int i; with range(-10, 10, +1)[3 .. object.length])
 Thoughts?


carefull this are my thoughts, you ask for it.

you lost it!

Isn't this a solution looking for a problem?
I notice that again when I browse one of your
columns on the online magazine.

No sane human will code that, it might be usefull
if you are generating code from a program,
but make sure the code generator is so good
that nobody will ever need to maintain the prog.

get a grip

well these are my thoughts. I warn you :)

Ant


 Ouch! harsh words, Ant. I don't agree with everything
 Matthew proposes (see Vector, etc) but he doesn't deserve
 to get flamed.

 -Ben


 Those are my thought, I put the first and last sentence to
 try to make it lighter because every thing I write sounds
 more harsh then I intended. I just can't write better in
 english...
 I also put the ":)" at the end...

 don't take it that "harsh", Matthew, guys...


No worries. I've been attacked from the top to the bottom in the last year,
so it's cool with me. I think you could probably work on your presentation
though, as your post does have pretty unfortunate wording. Were I a bit
precious, I might react to the sentiments presented (which I don't imagine
are what you meant) rather than the one good point you made, which is that
the range thing was probably unnecessary, which I largely agree with.

:)
Mar 21 2004
parent reply John Reimer <jjreimer telus.net> writes:
<SNIP>
 

 No worries. I've been attacked from the top to the bottom in the last
 year, so it's cool with me. I think you could probably work on your
 presentation though, as your post does have pretty unfortunate wording.
 Were I a bit precious, I might react to the sentiments presented (which I
 don't imagine are what you meant) rather than the one good point you made,
 which is that the range thing was probably unnecessary, which I largely
 agree with.
 
 :)


I actually have got accustomed to Ant's style ;-).  "I warn you" was
probably meant to be past tense "I warned you."  From my perspective, he
was just preparing you for some critisism and referencing back to that
fact.  Despite the slight language barrier, I got the drift.  For the most
part, I think you never have to take offense from Ant.  His unfortunate
wording is more of a side affect of ESL than anything else.  It's
forgiveable as long as the skin trully is thick :-).  Presentation can
always be worked on, but that goes for everybody.

Later,

John
Mar 21 2004
parent reply Ant <Ant_member pathlink.com> writes:
In article <c3lrln$13i0$1 digitaldaemon.com>, John Reimer says...

<SNIP>
 

 No worries. I've been attacked from the top to the bottom in the last
 year, so it's cool with me. I think you could probably work on your
 presentation though, as your post does have pretty unfortunate wording.
 Were I a bit precious, I might react to the sentiments presented (which I
 don't imagine are what you meant) rather than the one good point you made,
 which is that the range thing was probably unnecessary, which I largely
 agree with.
 
 :)


I actually have got accustomed to Ant's style ;-).


[...]

 For the most part, I think you never have to take offense from Ant.
 His unfortunate wording is more of a side affect of ESL than anything else.


Of course you're right.
thank you.

I just realize that if I don't post this confirmation it might
look like I don't agree.

Ant
Mar 23 2004
parent Carlos Santander B. <Carlos_member pathlink.com> writes:
In article <c3ppc5$1lu7$1 digitaldaemon.com>, Ant says...

In article <c3lrln$13i0$1 digitaldaemon.com>, John Reimer says...

<SNIP>
 

 No worries. I've been attacked from the top to the bottom in the last
 year, so it's cool with me. I think you could probably work on your
 presentation though, as your post does have pretty unfortunate wording.
 Were I a bit precious, I might react to the sentiments presented (which I
 don't imagine are what you meant) rather than the one good point you made,
 which is that the range thing was probably unnecessary, which I largely
 agree with.
 
 :)


I actually have got accustomed to Ant's style ;-).


[...]

 For the most part, I think you never have to take offense from Ant.
 His unfortunate wording is more of a side affect of ESL than anything else.


Of course you're right.
thank you.

I just realize that if I don't post this confirmation it might
look like I don't agree.

Ant


Maybe it's a cultural thing: until now, I can't find his words offensive by any
means.

-------------------
Carlos Santander B.
Mar 23 2004
prev sibling next sibling parent reply "Matthew" <matthew stlsoft.org> writes:
"Ben Hinkle" <bhinkle4 juno.com> wrote in message
news:tlgr50dv76fdsbll3ro2hvkd8eu3dbfuj8 4ax.com...

 On Sun, 21 Mar 2004 11:23:59 -0500, Ant <duitoolkit yahoo.ca> wrote:


On Sun, 21 Mar 2004 09:18:56 +0000, Matthew wrote:


 A bit more DTL ranges, involving slices:

     foreach(int i; range(-10, 10, +1)[6 .. 12])
     foreach(int i; range(-10, 10, +1)[3 .. ??])
     foreach(int i; range(-10, 10, +1)[3 .. range(-10, 10, +1).length])
     foreach(int i; with range(-10, 10, +1)[3 .. length])
     foreach(int i; with range(-10, 10, +1)[3 .. object.length])
 Thoughts?


carefull this are my thoughts, you ask for it.

you lost it!

Isn't this a solution looking for a problem?
I notice that again when I browse one of your
columns on the online magazine.

No sane human will code that, it might be usefull
if you are generating code from a program,
but make sure the code generator is so good
that nobody will ever need to maintain the prog.

get a grip

well these are my thoughts. I warn you :)

Ant


 Ouch! harsh words, Ant. I don't agree with everything
 Matthew proposes (see Vector, etc) but he doesn't deserve
 to get flamed.


Worry not. Thick skin. ;)

In fact, Ant's probably got a point about this range thing being a solution
looking for a problem. Walter sent me an email earlier suggesting slices on
integral ranges, and I did leap straight to thinking about the coding issues
discussed before thinking of practical uses. But, to my mind anyway, that's
what a NG is for. We fly lots of ideas up, and the good ones survive being
shot at.

However, I don't agree with that being the assessment of either subjects -
the integer to string conversions or the Friendly Templates - from my CUJ
online columns so far. Both of these might smell like artificial things -
and I've received plenty an email to that effect from some C++ bods - but do
they have valid uses. The int2string conversions are super fast and of use
in performance-sensitive serialisation (and anything else you need to
convert numbers to strings quickly), and the Friendly Templates ... well,
you'll have to buy the book to see the use for them, but I promise you it's
incredibly useful. Greg Comeau added a new flag to the compiler on the
strength of it, which is pretty much all the affirmation I (or anyone else)
should really need. :-:)

One of the (unsolvable) problems in writing articles is knowing how much
context to put in. Whatever you do you'll be accused of wasting time
preaching things already known by some and not giving enough
context/practical examples by others. I have a good band of chaps whom I
consult with my articles (including some compiler vendors...), and their
feedback guides me, but at the end of the day you have to judge for
yourself.

In any case, a column is about stimulating thought about a subject, and
they've certainly done that. If you don't want that, don't read it. It
doesn't worry me either way.

(btw, I'm putting it down to cultural/language differences, but telling me
you "warn" me sounds very odd. What are you warning me about? You going to
pay me a visit? Very odd ...)

Cheers

Matthew
Mar 21 2004
next sibling parent reply Ant <duitoolkit yahoo.ca> writes:
On Sun, 21 Mar 2004 16:47:58 +0000, Matthew wrote:


 
 "Ben Hinkle" <bhinkle4 juno.com> wrote in message
 news:tlgr50dv76fdsbll3ro2hvkd8eu3dbfuj8 4ax.com...

 On Sun, 21 Mar 2004 11:23:59 -0500, Ant <duitoolkit yahoo.ca> wrote:


On Sun, 21 Mar 2004 09:18:56 +0000, Matthew wrote:


 A bit more DTL ranges, involving slices:

     foreach(int i; range(-10, 10, +1)[6 .. 12])
     foreach(int i; range(-10, 10, +1)[3 .. ??])
     foreach(int i; range(-10, 10, +1)[3 .. range(-10, 10, +1).length])
     foreach(int i; with range(-10, 10, +1)[3 .. length])
     foreach(int i; with range(-10, 10, +1)[3 .. object.length])
 Thoughts?


carefull this are my thoughts, you ask for it.

you lost it!

Isn't this a solution looking for a problem?
I notice that again when I browse one of your
columns on the online magazine.

No sane human will code that, it might be usefull
if you are generating code from a program,
but make sure the code generator is so good
that nobody will ever need to maintain the prog.

get a grip

well these are my thoughts. I warn you :)

Ant


 Ouch! harsh words, Ant. I don't agree with everything
 Matthew proposes (see Vector, etc) but he doesn't deserve
 to get flamed.


 
 Worry not. Thick skin. ;)


I'm relieved :}


 
 In fact, Ant's probably got a point about this range thing being a solution
 looking for a problem.


you win some...


 ...but I promise you it's incredibly useful. 


you loose some...


 (btw, I'm putting it down to cultural/language differences, but telling me
 you "warn" me sounds very odd. What are you warning me about? You going to
 pay me a visit? Very odd ...)


cultural/language differences?
I don't even know what you mean here!
What's "a visit" has to do with it?

Well, we got the main issues accross.
You know you can count on me to speak out my mind :)
(or however you say that)

Ant
Mar 21 2004
parent "Matthew" <matthew stlsoft.org> writes:
<snip>

We're all cool


 (btw, I'm putting it down to cultural/language differences, but telling




me

 you "warn" me sounds very odd. What are you warning me about? You going




to

 pay me a visit? Very odd ...)


 cultural/language differences?
 I don't even know what you mean here!
 What's "a visit" has to do with it?

 Well, we got the main issues accross.
 You know you can count on me to speak out my mind :)
 (or however you say that)


He he. It's just when someone says to me "I warn you", that sounds like a
threat, so I was jokingly asking whether the threat was to be a physical
one, which would require a visit. No matter. :)
Mar 21 2004
prev sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Matthew wrote:


Worry not. Thick skin. ;)

In fact, Ant's probably got a point about this range thing being a solution
looking for a problem. Walter sent me an email earlier suggesting slices on
integral ranges, and I did leap straight to thinking about the coding issues
discussed before thinking of practical uses. But, to my mind anyway, that's
what a NG is for. We fly lots of ideas up, and the good ones survive being
shot at.
  


Some good points.

Parhaps this range thing could be part of a pair (ie pair and range 
being the same thing).  ATM if the reason is to simplify the for loop, 
I'd leave it (because it doesn't simplify much).

-- 
-Anderson: http://badmama.com.au/~anderson/
Mar 21 2004
parent "Matthew" <matthew stlsoft.org> writes:
"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:c3kk16$268b$1 digitaldaemon.com...

 Matthew wrote:


Worry not. Thick skin. ;)

In fact, Ant's probably got a point about this range thing being a




solution

looking for a problem. Walter sent me an email earlier suggesting slices




on

integral ranges, and I did leap straight to thinking about the coding




issues

discussed before thinking of practical uses. But, to my mind anyway,




that's

what a NG is for. We fly lots of ideas up, and the good ones survive




being

shot at.


 Some good points.

 Parhaps this range thing could be part of a pair (ie pair and range
 being the same thing).  ATM if the reason is to simplify the for loop,
 I'd leave it (because it doesn't simplify much).


Speaking in C++, since that's my prime area of Range expertise at the
moment, there are several different range types, of which the
pair-of-iterators is only one. I see no reason why the three (currently)
range types should not transfer over to D, in which case, yes, there is more
of a reason than that you ascribe. :)
Mar 21 2004
prev sibling parent reply larry cowan <larry_member pathlink.com> writes:
 A bit more DTL ranges, involving slices:
 
     foreach(int i; range(-10, 10, +1)[6 .. 12])
     foreach(int i; range(-10, 10, +1)[3 .. ??])
     foreach(int i; range(-10, 10, +1)[3 .. range(-10, 10, +1).length])
     foreach(int i; with range(-10, 10, +1)[3 .. length])
     foreach(int i; with range(-10, 10, +1)[3 .. object.length])
 Thoughts?






How is this more useful, readable, valuable than:

for ( i = v1 ; i < v2 ; i += v3 )

?  Can it be used in cases which are not indexable directly or via opAdd and
opCmp?  Can it do something the "for loop" cannot?

Range: what uses are there beyond the loop usage?

Slicing: what does it add to the mix?

Performance: how can you hope to improve on the simple "for loop"?

Control: this does probably have automatic limits checking and does any
necessary memory allocation for itself, but what about the objects it's used on?

Readability: this is much harder to read and understand than the simple,
concise, and ubiquitously familar format of the "for loop". 


Generic programming is a wonderful concept, but should be used to standardize
and optimize the attack on more difficult and complex problems.  Where the
language itself, or common usage is simple and straightforward, and handles the
needs well it should go look for a richer vein.

Where the implementation is common but has a lot of code, generics can hide the
complexity and standardize the solution; however if a simple call to a library
function or class can handle it well, do it that way.  Only where the solution
needs many options and hooks into a standardized method, or where the coding is
often done incompletely or wrong do I see a need.  There are uses where building
blocks can be created and stacked together to do a large number of different
things well.  There are uses which provide a framework for a very generalized
activity.  Any well-defined territory where there are established coding methods
can probably provide useful generics, but look beyond library functions to more
structural needs and usages.  Probably a lot of what is currently being done
with specialized classes could be refactored into templates handling a wider
variety of object types and simpler even more specialized classes.

Suggestions beyond the current bounds (not for DTL):
Business: standardized file matching skeltons (2-file, 3-file, master/detail,
etc), multi-currency methods, database interaction models?, lots more...
Scientific: matrix operations, statistics, any area of math where a special
abbreviated terminology has developed and hides the underlying complexity.
Mar 21 2004
next sibling parent "Matthew" <matthew stlsoft.org> writes:
"larry cowan" <larry_member pathlink.com> wrote in message
news:c3li6m$l3t$1 digitaldaemon.com...

 A bit more DTL ranges, involving slices:

     foreach(int i; range(-10, 10, +1)[6 .. 12])
     foreach(int i; range(-10, 10, +1)[3 .. ??])
     foreach(int i; range(-10, 10, +1)[3 .. range(-10, 10, +1).length])
     foreach(int i; with range(-10, 10, +1)[3 .. length])
     foreach(int i; with range(-10, 10, +1)[3 .. object.length])
 Thoughts?






 How is this more useful, readable, valuable than:

 for ( i = v1 ; i < v2 ; i += v3 )

 ?


Depends on context. In "normal" code, it isn't, but I'm not (going to) claim
that it is.


  Can it be used in cases which are not indexable directly


In the general case, yes.


or via opAdd and
 opCmp?  Can it do something the "for loop" cannot?

 Range: what uses are there beyond the loop usage?


They encompass within a common construct - foreach in D - a wider range of
"ranges" than any other concept, since they include notional ranges, such as
for(int i = ...) and also actual ranges, as denoted by iterators.


 Slicing: what does it add to the mix?


Haven't a clue. Walter requested it, and I wrote before I thought. :)

Please don't everyone get hung up on the IntegralRange. It's fairly useful,
but I've shown it as it clearly illustrates the concept. Once everything's
written up it should be clearer how these things fall into place. (In my
defense, I'll say that Walter, the arch-pragmatist, gave the thumbs up to
the chapter on ranges in "Imperfect C++", so it's probably not all
philosophical fancy. <g>)


 Performance: how can you hope to improve on the simple "for loop"?


I don't. As good as is fine by me.

I'll be stunned if the compiler doesn't translate it into the exact same
machine code, heap objects and templates notwithstanding.


 Control: this does probably have automatic limits checking and does any
 necessary memory allocation for itself, but what about the objects it's


used on?

Don't understand the question


 Readability: this is much harder to read and understand than the simple,
 concise, and ubiquitously familar format of the "for loop".


Disagree. Once most/all things in D can be done by foreach, the opposite
could be said by someone who thinks in D.


 Generic programming is a wonderful concept, but should be used to


standardize

 and optimize the attack on more difficult and complex problems.  Where the
 language itself, or common usage is simple and straightforward, and


handles the

 needs well it should go look for a richer vein.


Generally agree. Time will tell on this specific case. (I refer one to the
pedagogical motivations of this example mentioned above)


 Where the implementation is common but has a lot of code, generics can


hide the

 complexity and standardize the solution; however if a simple call to a


library

 function or class can handle it well, do it that way.  Only where the


solution

 needs many options and hooks into a standardized method, or where the


coding is

 often done incompletely or wrong do I see a need.  There are uses where


building

 blocks can be created and stacked together to do a large number of


different

 things well.  There are uses which provide a framework for a very


generalized

 activity.  Any well-defined territory where there are established coding


methods

 can probably provide useful generics, but look beyond library functions to


more

 structural needs and usages.  Probably a lot of what is currently being


done

 with specialized classes could be refactored into templates handling a


wider

 variety of object types and simpler even more specialized classes.

 Suggestions beyond the current bounds (not for DTL):


Agreed. My intention - though I am aware I may be outvoted by the members of
the ISO 2006 D Language Standards Committe - is that DTL is what the STL is
to C++, and *not* what the standard library is. In other words, it's about
containers and algorithms, and *not* about all the other ill-judged cack
that got stuck in with it in C++, especially the IOStreams. If people want
to write their streams to interroperate with DTL, or even to ape its
interfaces, that's great, but I don't want to shove a load of nonsense - a
la the forward declarations of many IOStream components into the
basic_string<> implementation - into DTL that will do nothing but reduce
it's simplicity, orthogonality and low coupling. It may be that D's lack of
need for forward declarations will make this point moot, but if not I'll be
a real stick in the mud until and unless I'm overruled.


 Business: standardized file matching skeltons (2-file, 3-file,


master/detail,

 etc), multi-currency methods, database interaction models?, lots more...
 Scientific: matrix operations, statistics, any area of math where a


special

 abbreviated terminology has developed and hides the underlying complexity.


Agreed. We needs lots of great libs. We're getting OT now, though, so I'll
merely say I'm looking forward to a C implementation of the wildcards lib,
for recls and STLSoft. ;)
Mar 23 2004
prev sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
larry cowan wrote:


A bit more DTL ranges, involving slices:

    foreach(int i; range(-10, 10, +1)[6 .. 12])
    foreach(int i; range(-10, 10, +1)[3 .. ??])
    foreach(int i; range(-10, 10, +1)[3 .. range(-10, 10, +1).length])
    foreach(int i; with range(-10, 10, +1)[3 .. length])
    foreach(int i; with range(-10, 10, +1)[3 .. object.length])
Thoughts?
        






How is this more useful, readable, valuable than:

for ( i = v1 ; i < v2 ; i += v3 )
  


For one thing, you can pass this information by function parameter.

-- 
-Anderson: http://badmama.com.au/~anderson/
Mar 23 2004
parent reply "Matthew" <matthew stlsoft.org> writes:
"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:c3p9d5$oh2$1 digitaldaemon.com...

 larry cowan wrote:


A bit more DTL ranges, involving slices:

    foreach(int i; range(-10, 10, +1)[6 .. 12])
    foreach(int i; range(-10, 10, +1)[3 .. ??])
    foreach(int i; range(-10, 10, +1)[3 .. range(-10, 10, +1).length])
    foreach(int i; with range(-10, 10, +1)[3 .. length])
    foreach(int i; with range(-10, 10, +1)[3 .. object.length])
Thoughts?






How is this more useful, readable, valuable than:

for ( i = v1 ; i < v2 ; i += v3 )


 For one thing, you can pass this information by function parameter.


Quite right! I forgot my one compelling advantage.

The start, end and increment can be passed by function params, but what
about if you want the increment to be *=3, rather than +=3. This would lead
to really hairy, and inefficient, coding. With a range, you don't have to
worry about that, since the range knows how to do it's own "increment",
whatever that may be.

Thanks JA. :)
Mar 23 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Matthew wrote:


"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:c3p9d5$oh2$1 digitaldaemon.com...
  


larry cowan wrote:

    


A bit more DTL ranges, involving slices:

   foreach(int i; range(-10, 10, +1)[6 .. 12])
   foreach(int i; range(-10, 10, +1)[3 .. ??])
   foreach(int i; range(-10, 10, +1)[3 .. range(-10, 10, +1).length])
   foreach(int i; with range(-10, 10, +1)[3 .. length])
   foreach(int i; with range(-10, 10, +1)[3 .. object.length])
Thoughts?


            






How is this more useful, readable, valuable than:

for ( i = v1 ; i < v2 ; i += v3 )
      


For one thing, you can pass this information by function parameter.
    


Quite right! I forgot my one compelling advantage.

The start, end and increment can be passed by function params, but what
about if you want the increment to be *=3, rather than +=3. This would lead
to really hairy, and inefficient, coding. With a range, you don't have to
worry about that, since the range knows how to do it's own "increment",
whatever that may be.

Thanks JA. :)


  


Well you could pass it as 3 params but what I meant to say is that you 
can create a reusable object and store it and pass as a block.  Make it 
a member of a class for a kinda state machine, use it for returning 
range or whatever.  Pairs can be very useful, no doubt  ranges (of which 
a pair is one type) will be useful.

Can ranges be staticly created?  I mean like when the min and max values 
stay the same.  In ada they were.

-- 
-Anderson: http://badmama.com.au/~anderson/
Mar 23 2004
parent reply larry cowan <larry_member pathlink.com> writes:
In article <c3pels$11s8$2 digitaldaemon.com>, J Anderson says...

Matthew wrote:


Put my vote in for python syntax

slice[x:y], slice[:3], slice[:4], slice[1:-1], etc.

slice[:] forces a copy, I think, somebody correct me if I'm wrong.

If the colon is a parsing problem, then .. is ok, but changing to colon would
force a lot of current code to be updated (easy grep for \.\.) to replace
awkward xxxxxxxxxxxx.length-y constructs.  The empty left or right side should
make a 0 at the left unnecessary and the implied begin/end should make negative
right-side values easily interprable with +x on the left the same as just x.
This is far better than forcing a new symbol or keyword into being.

-larry
Mar 23 2004
parent reply larry cowan <larry_member pathlink.com> writes:
Update: The reasoning on negative index isn't right, because we need it in the
left side as well:  slice[-3,-1] for the last 2 chars, etc.  But I still think
it's the right way to go.

In article <c3pl6n$1ebh$1 digitaldaemon.com>, larry cowan says...

In article <c3pels$11s8$2 digitaldaemon.com>, J Anderson says...

Matthew wrote:


Put my vote in for python syntax

slice[x:y], slice[:3], slice[:4], slice[1:-1], etc.

slice[:] forces a copy, I think, somebody correct me if I'm wrong.

If the colon is a parsing problem, then .. is ok, but changing to colon would
force a lot of current code to be updated (easy grep for \.\.) to replace
awkward xxxxxxxxxxxx.length-y constructs.  The empty left or right side should
make a 0 at the left unnecessary and the implied begin/end should make negative
right-side values easily interprable with +x on the left the same as just x.
This is far better than forcing a new symbol or keyword into being.

-larry
Mar 23 2004
parent larry cowan <larry_member pathlink.com> writes:
I meant:


Update: The reasoning on negative index isn't right, because we need it in the
left side as well:  slice[-3:] for the last 3 chars, etc.  But I still think
it's the right way to go.
Mar 23 2004
prev sibling parent larry cowan <larry_member pathlink.com> writes:
In article <c3p9r8$q36$1 digitaldaemon.com>, Matthew says...

"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:c3p9d5$oh2$1 digitaldaemon.com...

 larry cowan wrote:


A bit more DTL ranges, involving slices:

    foreach(int i; range(-10, 10, +1)[6 .. 12])
    foreach(int i; range(-10, 10, +1)[3 .. ??])
    foreach(int i; range(-10, 10, +1)[3 .. range(-10, 10, +1).length])
    foreach(int i; with range(-10, 10, +1)[3 .. length])
    foreach(int i; with range(-10, 10, +1)[3 .. object.length])
Thoughts?






How is this more useful, readable, valuable than:

for ( i = v1 ; i < v2 ; i += v3 )


 For one thing, you can pass this information by function parameter.


Quite right! I forgot my one compelling advantage.

The start, end and increment can be passed by function params, but what
about if you want the increment to be *=3, rather than +=3. This would lead
to really hairy, and inefficient, coding. With a range, you don't have to
worry about that, since the range knows how to do it's own "increment",
whatever that may be.

Thanks JA. :)


Still don't see it. Even with

for (i=v1; i != v2%7 ;i=((i+2)*v3)%42)

it seems clearer than going on a search in other code to find out the rules that
are being used.  We are, however, still just talking about int stuff here.
Where external info (business rules) provide an adequate understanding of what
is being used all over in various ways, I may come around.
I have no problem with implementations of all sorts of common and useful
collection types where the same can be said of programmer concepts (external
info), but I still don't see where ranges fit in.
I should get your current DTL status file - I think you posted it or a link, but
I missed it.  Please repeat it if you did.  I should look through that before I
blow any more hot air. 

-larry
Mar 23 2004
prev sibling parent reply Andy Friesen <andy ikagames.com> writes:
Ant wrote:

 On Sun, 21 Mar 2004 09:18:56 +0000, Matthew wrote:
 
 

A bit more DTL ranges, involving slices:

    foreach(int i; range(-10, 10, +1)[6 .. 12])
    foreach(int i; range(-10, 10, +1)[3 .. ??])
    foreach(int i; range(-10, 10, +1)[3 .. range(-10, 10, +1).length])
    foreach(int i; with range(-10, 10, +1)[3 .. length])
    foreach(int i; with range(-10, 10, +1)[3 .. object.length])
Thoughts?


 
 Isn't this a solution looking for a problem?
 I notice that again when I browse one of your
 columns on the online magazine.


In the specific case of range(), maybe.  But in the general case, I 
don't think so; some way to describe the end of an unnamed sequence is 
definitely needed.

Is there a reason that the endpoints couldn't simply be omitted, like 
python does?  ie blah[5..] slicing everything starting at index 5.

  -- andy
Mar 21 2004
parent reply "Matthew" <matthew stlsoft.org> writes:
"Andy Friesen" <andy ikagames.com> wrote in message
news:c3kjso$25vm$1 digitaldaemon.com...

 Ant wrote:

 On Sun, 21 Mar 2004 09:18:56 +0000, Matthew wrote:



A bit more DTL ranges, involving slices:

    foreach(int i; range(-10, 10, +1)[6 .. 12])
    foreach(int i; range(-10, 10, +1)[3 .. ??])
    foreach(int i; range(-10, 10, +1)[3 .. range(-10, 10, +1).length])
    foreach(int i; with range(-10, 10, +1)[3 .. length])
    foreach(int i; with range(-10, 10, +1)[3 .. object.length])
Thoughts?


 Isn't this a solution looking for a problem?
 I notice that again when I browse one of your
 columns on the online magazine.


 In the specific case of range(), maybe.  But in the general case, I
 don't think so; some way to describe the end of an unnamed sequence is
 definitely needed.

 Is there a reason that the endpoints couldn't simply be omitted, like
 python does?  ie blah[5..] slicing everything starting at index 5.


IIRC, the objections are that it would make it harder to parse. However,
given the recent comments on LR parsing - Manfred and Stewart, I think - I
wonder whether there should be a move to a more Python-like syntax, whereby
the range operator is :, as in

    blah[0:5]
    blah[3:]
    blah[:23]

since this seems not ambiguous. I'm interested to hear Walter's thoughts on
all this LR parsability / range syntax issue, since he's the compiler man.
If he's no objections, then I think we should move to the : purely so that
we can have implicit start/end to range expressions
Mar 21 2004
next sibling parent Patrick Down <pat codemoon.com> writes:
"Matthew" <matthew stlsoft.org> wrote in
news:c3kkim$2739$1 digitaldaemon.com: 

 IIRC, the objections are that it would make it harder to parse.
 However, given the recent comments on LR parsing - Manfred and
 Stewart, I think - I wonder whether there should be a move to a more
 Python-like syntax, whereby the range operator is :, as in
 
     blah[0:5]
     blah[3:]
     blah[:23]


Yes! I've been writing .. in python code and : in D.
Standadizing on : would be good.
Mar 21 2004
prev sibling parent reply Andy Friesen <andy ikagames.com> writes:
Matthew wrote:

 IIRC, the objections are that it would make it harder to parse. However,
 given the recent comments on LR parsing - Manfred and Stewart, I think - I
 wonder whether there should be a move to a more Python-like syntax, whereby
 the range operator is :, as in
 
     blah[0:5]
     blah[3:]
     blah[:23]
 
 since this seems not ambiguous. I'm interested to hear Walter's thoughts on
 all this LR parsability / range syntax issue, since he's the compiler man.
 If he's no objections, then I think we should move to the : purely so that
 we can have implicit start/end to range expressions


I think the problem with that is conflict with the ?: operator.

-> is somewhat logical:
    blah[3 -> 5]
    blah[3 -> ]
    blah[ -> 8]

The C crowd would love it.

I think the colon works much better, though.

  -- andy
Mar 21 2004
parent reply Brad Anderson <brad sankaty.dot.com> writes:
http://www.digitalmars.com/d/sdwest/scan0030.jpg



Andy Friesen wrote:

 Matthew wrote:
 

 IIRC, the objections are that it would make it harder to parse. However,
 given the recent comments on LR parsing - Manfred and Stewart, I think 
 - I
 wonder whether there should be a move to a more Python-like syntax, 
 whereby
 the range operator is :, as in

     blah[0:5]
     blah[3:]
     blah[:23]

 since this seems not ambiguous. I'm interested to hear Walter's 
 thoughts on
 all this LR parsability / range syntax issue, since he's the compiler 
 man.
 If he's no objections, then I think we should move to the : purely so 
 that
 we can have implicit start/end to range expressions


 
 
 I think the problem with that is conflict with the ?: operator.
 
 -> is somewhat logical:
    blah[3 -> 5]
    blah[3 -> ]
    blah[ -> 8]
 
 The C crowd would love it.
 
 I think the colon works much better, though.
 
  -- andy
Mar 21 2004
parent Ilya Minkov <minkov cs.tum.edu> writes:
Brad Anderson schrieb:


 http://www.digitalmars.com/d/sdwest/scan0030.jpg


That's exactly the reason why it can be done. ;)
Mar 22 2004
prev sibling next sibling parent Patrick Down <pat codemoon.com> writes:
"Matthew" <matthew stlsoft.org> wrote in
news:c3jmsb$o6d$1 digitaldaemon.com: 


 
 But to go to the end from, say, the third element, what do we do?
 
     foreach(int i; range(-10, 10, +1)[3 .. ??])
 
 Now of course we can calculate it by the following:
 
     foreach(int i; range(-10, 10, +1)[3 .. range(-10, 10, +1).length])


In this one particular situation I think you may be looking for
a solution to a problem that will occur in only 1% of the common
usage cases of range.

However, I do belive that slicing to the end or from the beginning
of and array or sliceable object is a problem worth addressing.

My proposal would be the inclusion of opLeft and opRight.

a[3..] calls opRight(3)

a[..4] calls opLeft(4)
Mar 21 2004
prev sibling parent "Ivan Senji" <ivan.senji public.srce.hr> writes:
I like the idea of with beeing used this way, it could save a lot of typing
and help prevent a lot of bugs.
It would be great if I could, instead of writing something like this (real
code):
        P.G.nonTerminalToStr[a.element][1 ..
P.G.nonTerminalToStr[a.element].length-1]
write something like this:
        with(P.G.nonTerminalToStr[a.element])[1..length-1]
//compiler realizes that "length" is something that needs to be called on
"P.G.nonTerminalToStr[a.element]"

This is more readable, easier to find bugs in, easier to change if changes
need to be made.
I only don't know is it possible to implement.


"Matthew" <matthew stlsoft.org> wrote in message
news:c3jmsb$o6d$1 digitaldaemon.com...

 A bit more DTL ranges, involving slices:

     foreach(int i; range(-10, 10, +1)[6 .. 12])
     {
         printf("%d ", i);
     }

 This prints out

     -4 -3 -2 -1 0 1

 To slice from the beginning, we would start with 0, as in:

     foreach(int i; range(-10, 10, +1)[0 .. 12])

 This prints out

     -10 -9 -8 -7 -6 -5 -4 -3 -2 -1 0 1

 But to go to the end from, say, the third element, what do we do?

     foreach(int i; range(-10, 10, +1)[3 .. ??])

 Now of course we can calculate it by the following:

     foreach(int i; range(-10, 10, +1)[3 .. range(-10, 10, +1).length])

 But it's not very succinct, is it? It's pretty confusing to look at for


me,

 so I'm guessing people who aren't familiar with it would have a hard time.

 Maybe we can use "with", somehow, as in

     foreach(int i; with range(-10, 10, +1)[3 .. length])

 or

     foreach(int i; with range(-10, 10, +1)[3 .. object.length])

 where "object" would be a reserved word and would refer to the current
 with'd instance.

 Thoughts?
Mar 22 2004