www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Dithering about ranges

reply Georg Wrede <georg.wrede iki.fi> writes:
Not cosidering D or programming, the notion of a range implies a 
beginning and an end. So, in a certain sense, ranges could be 
conceptualized as slices.

All's well, and everything. But, things like input streams don't really 
support the notion of "range", or "slice". They don't even want to.

Sure, one could "coerce" or "forge" an input range to pretend some 
manner of them, but that would be awkward at best, and laborios in practice.


Does that mean that I'm against ranges? No. But there might be the 
possibility that ranges are not a panacea. Just as Structured 
Programming wasn't (look at Walter's gotos all over the place), OOP 
wasn't, Functional Programming wasn't, or that metaprogramming doesn't 
tell us whether God exists. Ranges solve some gargantuan problems in 
Modern Programming, but I don't expect them to usurp a dozen of other 
paradigms.

Could it be that the optimum would be to have /both/ ranges and, ehhh, 
pointing notions?

Today, no sane programmer (outside of C or outside of Java) would make 
his application /entirely/ ranges or /entirely/ classes.
May 21 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Georg Wrede wrote:
 Not cosidering D or programming, the notion of a range implies a 
 beginning and an end.

Actually, not. Infinity is a primitive notion with ranges. A range that defines empty like this: enum bool empty = false; is detected as infinite and treated accordingly by certain other ranges and algorithms. See isInfinite in std.range.
 So, in a certain sense, ranges could be 
 conceptualized as slices.

Yes, slices were a motivator and model for ranges.
 All's well, and everything. But, things like input streams don't really 
 support the notion of "range", or "slice". They don't even want to.

Why don't they?
 Sure, one could "coerce" or "forge" an input range to pretend some 
 manner of them, but that would be awkward at best, and laborios in 
 practice.

What would be a natural interface for an input range?
 Does that mean that I'm against ranges? No. But there might be the 
 possibility that ranges are not a panacea. Just as Structured 
 Programming wasn't (look at Walter's gotos all over the place), OOP 
 wasn't, Functional Programming wasn't, or that metaprogramming doesn't 
 tell us whether God exists. Ranges solve some gargantuan problems in 
 Modern Programming, but I don't expect them to usurp a dozen of other 
 paradigms.

For sure nobody cracked them to be that great. I think you perceive them as an imposition when they really are some rather unremarkable types with at most a handful of primitives.
 Could it be that the optimum would be to have /both/ ranges and, ehhh, 
 pointing notions?
 
 Today, no sane programmer (outside of C or outside of Java) would make 
 his application /entirely/ ranges or /entirely/ classes.

I don't quite understand this. Ranges are a very simple abstraction for iteration. They show how other iteration abstractions either were too unsafe and verbose (C++/STL) or too bare-bones (C# iterators, Java iterators, singly-linked lists used by functional languages), so in that regard I think they hit the spot pretty nicely. Ranges are useful, but hardly a be-all end-all. Thinking of building an application entirely of ranges... I can't quite parse that. Andrei
May 21 2009