www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - New std.range submodule

reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
Recently, some good progress has been made in cleaning up the messy web
of imports between Phobos modules, so that importing one module for a
single function won't also pull in half of Phobos. Part of this work has
been to separate the range API constraints (isInputRange, hasLength,
isForwardRange, etc.) from std.range into a new submodule currently
named std.range.constraints.

However, we are considering renaming it to a better name, because
currently it also contains a bunch of stuff that are *not* "constraints"
per se -- such as the range primitives for built-in arrays. They were
put there because they are often used together with the range API
constraints, and any code that uses them would also need to import the
constraints anyway.

Any ideas for a better name for this submodule? We'd like to get this
decided before the next release, after which it will be more troublesome
to rename it.

Possible alternatives include:

- std.range.core
- std.range.api
- etc.

Any other suggestions?


T

-- 
Without outlines, life would be pointless.
Nov 13 2014
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 14/11/2014 6:30 p.m., H. S. Teoh via Digitalmars-d wrote:
 Recently, some good progress has been made in cleaning up the messy web
 of imports between Phobos modules, so that importing one module for a
 single function won't also pull in half of Phobos. Part of this work has
 been to separate the range API constraints (isInputRange, hasLength,
 isForwardRange, etc.) from std.range into a new submodule currently
 named std.range.constraints.

 However, we are considering renaming it to a better name, because
 currently it also contains a bunch of stuff that are *not* "constraints"
 per se -- such as the range primitives for built-in arrays. They were
 put there because they are often used together with the range API
 constraints, and any code that uses them would also need to import the
 constraints anyway.

 Any ideas for a better name for this submodule? We'd like to get this
 decided before the next release, after which it will be more troublesome
 to rename it.

 Possible alternatives include:

 - std.range.core
 - std.range.api
 - etc.

 Any other suggestions?


 T
std.range.checks I use this naming scheme for modules (with their purpose) for heavy ctfe code. Checks are: 1. Free functions 2. Expected to run at compile time only 3. Pure 4. Are templated Helpers are: 1. Free functions 2. Expected to run at runtime 3. Not pure 4. May or may not be templated
Nov 13 2014
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Friday, 14 November 2014 at 06:10:43 UTC, Rikki Cattermole 
wrote:
 std.range.checks
For this, std.range.constraints would also be perfectly fine. The point is that the module also contains the array->range adapters that are definitely not constraints, checks, or however else you might call them. David
Nov 14 2014
next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Friday, 14 November 2014 at 21:52:04 UTC, David Nadlinger 
wrote:
 On Friday, 14 November 2014 at 06:10:43 UTC, Rikki Cattermole 
 wrote:
 std.range.checks
For this, std.range.constraints would also be perfectly fine. The point is that the module also contains the array->range adapters that are definitely not constraints, checks, or however else you might call them. David
Perhaps they shouldn't be in the same module then. Maybe use two submodules: std.range.checks (or constraints) std.range.adapters
Nov 14 2014
next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Nov 14, 2014 at 10:22:16PM +0000, Brad Anderson via Digitalmars-d wrote:
 On Friday, 14 November 2014 at 21:52:04 UTC, David Nadlinger wrote:
On Friday, 14 November 2014 at 06:10:43 UTC, Rikki Cattermole wrote:
std.range.checks
For this, std.range.constraints would also be perfectly fine. The point is that the module also contains the array->range adapters that are definitely not constraints, checks, or however else you might call them. David
Perhaps they shouldn't be in the same module then. Maybe use two submodules: std.range.checks (or constraints) std.range.adapters
OTOH, the current std.range also has a lot of other "adapters" like cycle, take, etc.. Which you probably don't want to be importing every time just because you need to use array range primitives. T -- First Rule of History: History doesn't repeat itself -- historians merely repeat each other.
Nov 14 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Friday, 14 November 2014 at 22:22:17 UTC, Brad Anderson wrote:
 On Friday, 14 November 2014 at 21:52:04 UTC, David Nadlinger 
 wrote:
 On Friday, 14 November 2014 at 06:10:43 UTC, Rikki Cattermole 
 wrote:
 std.range.checks
For this, std.range.constraints would also be perfectly fine. The point is that the module also contains the array->range adapters that are definitely not constraints, checks, or however else you might call them. David
Perhaps they shouldn't be in the same module then. Maybe use two submodules: std.range.checks (or constraints) std.range.adapters
As far as I understand idea is exactly to separate it (while release has not happened and it is not too late)
Nov 14 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 14 November 2014 at 22:22:17 UTC, Brad Anderson wrote:
 On Friday, 14 November 2014 at 21:52:04 UTC, David Nadlinger 
 wrote:
 On Friday, 14 November 2014 at 06:10:43 UTC, Rikki Cattermole 
 wrote:
 std.range.checks
For this, std.range.constraints would also be perfectly fine. The point is that the module also contains the array->range adapters that are definitely not constraints, checks, or however else you might call them. David
Perhaps they shouldn't be in the same module then. Maybe use two submodules: std.range.checks (or constraints) std.range.adapters
As far as I understand idea is exactly to separate it (while release has not happened and it is not too late)
Nov 14 2014
parent "Dicebot" <public dicebot.lv> writes:
On Friday, 14 November 2014 at 22:47:38 UTC, Dicebot wrote:
 As far as I understand idea is exactly to separate it (while 
 release has not happened and it is not too late)
(that was my original proposal when reviewing PR too)
Nov 14 2014
prev sibling parent reply Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On 14/11/2014 21:52, David Nadlinger wrote:
 On Friday, 14 November 2014 at 06:10:43 UTC, Rikki Cattermole wrote:
 std.range.checks
For this, std.range.constraints would also be perfectly fine.
If it's not too late, can we change the name to std.range.traits? It seems better as they can be used in 'static if', not just for template constraints. Plus it's shorter and consistent with std.traits naming.
Nov 19 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Nov 19, 2014 at 06:06:26PM +0000, Nick Treleaven via Digitalmars-d
wrote:
 On 14/11/2014 21:52, David Nadlinger wrote:
On Friday, 14 November 2014 at 06:10:43 UTC, Rikki Cattermole wrote:
std.range.checks
For this, std.range.constraints would also be perfectly fine.
If it's not too late, can we change the name to std.range.traits? It seems better as they can be used in 'static if', not just for template constraints. Plus it's shorter and consistent with std.traits naming.
It's not too late until the next release. I prefer std.range.primitives, since it's not just traits, but also includes things like range API for built-in arrays (.front, .empty, .popFront). T -- What do you mean the Internet isn't filled with subliminal messages? What about all those buttons marked "submit"??
Nov 19 2014
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Wednesday, 19 November 2014 at 18:22:27 UTC, H. S. Teoh via
Digitalmars-d wrote:
 On Wed, Nov 19, 2014 at 06:06:26PM +0000, Nick Treleaven via 
 Digitalmars-d wrote:
 On 14/11/2014 21:52, David Nadlinger wrote:
On Friday, 14 November 2014 at 06:10:43 UTC, Rikki Cattermole 
wrote:
std.range.checks
For this, std.range.constraints would also be perfectly fine.
If it's not too late, can we change the name to std.range.traits? It seems better as they can be used in 'static if', not just for template constraints. Plus it's shorter and consistent with std.traits naming.
It's not too late until the next release. I prefer std.range.primitives, since it's not just traits, but also includes things like range API for built-in arrays (.front, .empty, .popFront). T
I think "constraints" should be called "traits", because that's what it actually is, and the top level module is called "traits" (eg: isSomeString <==> isForwardRange). It makes little sense to me for both to have different names. The "popFront"/"moveFront" and friends I think belong in "primitives". It sounds nice. Also, every package std.range.* should publicly include std.range.constraints too. That's what container does, in that every sub package also includes the the "make" in std.container.utility.
Nov 21 2014
parent "Dicebot" <public dicebot.lv> writes:
I disagree that `traits` and `constraints` are the same. 
Constraint is a specific case of a trait which returns boolean 
value and has semantical from of `isSomething`. Trait is pretty 
much any static reflection utility, whatever it does.
Dec 04 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
std.range.primitives ?
Nov 14 2014
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
15-Nov-2014 00:17, Dicebot пишет:
 std.range.primitives ?
+1 -- Dmitry Olshansky
Nov 14 2014
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sat, Nov 15, 2014 at 12:56:33AM +0300, Dmitry Olshansky via Digitalmars-d
wrote:
 15-Nov-2014 00:17, Dicebot пишет:
std.range.primitives ?
+1
[...] Mmmm, I like that. T -- The diminished 7th chord is the most flexible and fear-instilling chord. Use it often, use it unsparingly, to subdue your listeners into submission!
Nov 14 2014