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/

"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

"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. :)

"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)

"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.

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

>>> 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.

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

<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

Brad Anderson schrieb:

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

That's exactly the reason why it can be done. ;)