www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Compile time iota

reply zeljkog <zeljkog home.com> writes:
Maybe something like this can be added to Fobos:

template Iota(int start, int stop, int step = 1){
     template tuple(T...){
         alias tuple = T;
     }
     static if(start < stop)
         alias Iota = tuple!(start, Iota!(start + step, stop, step));
     else
         alias Iota = tuple!();
}
Jan 21 2015
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Jan 21, 2015 at 07:14:09PM +0100, zeljkog via Digitalmars-d wrote:

 
 Maybe something like this can be added to Fobos:
 
 template Iota(int start, int stop, int step = 1){
     template tuple(T...){
         alias tuple = T;
     }
     static if(start < stop)
         alias Iota = tuple!(start, Iota!(start + step, stop, step));
     else
         alias Iota = tuple!();
 }


This is actually already implemented as std.typecons.staticIota, but
it's currently undocumented and restricted to only Phobos code. I'm not
sure why it was decided not to make it public, but if you file an
enhancement request, the devs can look at it and decide if it's worth
making it public.


T

-- 
Life is unfair. Ask too much from it, and it may decide you don't deserve what
you have now either.
Jan 21 2015
next sibling parent reply zeljkog <zeljkog home.com> writes:
On 21.01.15 19:23, H. S. Teoh via Digitalmars-d wrote:

 This is actually already implemented as std.typecons.staticIota, but
 it's currently undocumented and restricted to only Phobos code. I'm not
 sure why it was decided not to make it public, but if you file an
 enhancement request, the devs can look at it and decide if it's worth
 making it public.


I see, thx.

And good name staticIota, unlike TypeTuple. I always wonder what is raw 
tuple, TypeTuple or Tuple :)
Jan 21 2015
parent reply Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On 21/01/2015 19:15, zeljkog wrote:

 And good name staticIota, unlike TypeTuple. I always wonder what is raw
 tuple, TypeTuple or Tuple :)


Yes, there's a DIP to rename std.typetuple to std.meta.list. I made a 
pull to do that (which goes further than the DIP), but I don't know if 
the deprecation/disruption will be acceptable. If not, perhaps we could 
just add a better named alias for TypeTuple (e.g. MetaTuple) but keep 
the same module name. I don't think the status quo is really acceptable.

(In fact, I don't agree with removing deprecated symbols unless they are 
actually buggy - this is what GTK does. If we kept them there would be 
less friction and less cause not to deprecate things which are problematic).
Jan 22 2015
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 22 January 2015 at 13:06:26 UTC, Nick Treleaven 
wrote:

 On 21/01/2015 19:15, zeljkog wrote:

 And good name staticIota, unlike TypeTuple. I always wonder 
 what is raw
 tuple, TypeTuple or Tuple :)


 Yes, there's a DIP to rename std.typetuple to std.meta.list. I 
 made a pull to do that (which goes further than the DIP), but I 
 don't know if the deprecation/disruption will be acceptable. If 
 not, perhaps we could just add a better named alias for 
 TypeTuple (e.g. MetaTuple) but keep the same module name. I 
 don't think the status quo is really acceptable.

 (In fact, I don't agree with removing deprecated symbols unless 
 they are actually buggy - this is what GTK does. If we kept 
 them there would be less friction and less cause not to 
 deprecate things which are problematic).


Ah, great, now I am least sure that you and ntrel are the same 
person :) Fate of your pull and DIP in general is in Andrei hands 
- but, as he has mentioned in this thread, his mailbox queue is 
not easy to deal with. So right now can't really do anything but 
sit and wait.
Jan 22 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/22/15 5:08 AM, Dicebot wrote:

 On Thursday, 22 January 2015 at 13:06:26 UTC, Nick Treleaven wrote:

 On 21/01/2015 19:15, zeljkog wrote:

 And good name staticIota, unlike TypeTuple. I always wonder what is raw
 tuple, TypeTuple or Tuple :)


 Yes, there's a DIP to rename std.typetuple to std.meta.list. I made a
 pull to do that (which goes further than the DIP), but I don't know if
 the deprecation/disruption will be acceptable. If not, perhaps we
 could just add a better named alias for TypeTuple (e.g. MetaTuple) but
 keep the same module name. I don't think the status quo is really
 acceptable.

 (In fact, I don't agree with removing deprecated symbols unless they
 are actually buggy - this is what GTK does. If we kept them there
 would be less friction and less cause not to deprecate things which
 are problematic).


 Ah, great, now I am least sure that you and ntrel are the same person :)
 Fate of your pull and DIP in general is in Andrei hands - but, as he has
 mentioned in this thread, his mailbox queue is not easy to deal with. So
 right now can't really do anything but sit and wait.


I'm ambivalent about this; I think it could go either way without making 
a huge impact. (BTW I like GTK's idea to keep the old names around. They 
could be marginalized in the documentation but still allow older 
programs to build.)

I'm more worried about another trend though (only loosely related to 
this particular one). I might talk about that tonight.ñ

While working on the new site menus I was copying std modules by hand - 
and boy, there's just so much work to be done. Streams, json, encoding, 
mmfile, outbuffer, signals, socket, socketstream, xml, zip - all that 
stuff, maybe a third of the standard library packages, are /known/ to be 
in need of a good revamp (ranging from better documenting to refactoring 
to improving to completely rewriting) yet recently a lot of work has 
been spent on renaming, splitting, ... - shuffling the rubble in the 
garden, especially parts that are already good: container, algorithm, 
range, typecons.

Moreover, there's a ton of brand new work to be done! We don't have 
standard decent wrappers for libevent or libarchive, networking 
protocols, web servers, databases, and just a ton of other things.

I hypothesize much of it is because a small improvement to something 
that's already good is easier to push past review; what's there works, 
the new stuff is even nicer - game, set, and match. Pull merged. In 
contrast, embarking on a significant new work is likely to receive a lot 
more scrutiny and criticism.

This might be because an asymmetry: we have a high bar for reviews and a 
good process in place, but no strong enough large submissions to make it 
past it. As a consequence our current dynamics "optimizes" for small 
improvements of already working code.

In WWI, the advent of mounted machine guns created a large asymmetry 
between defense and offense: defense was much more effective than 
offense, which led to the trench stalemate. It seems to me we have an 
asymmetry between the review process and the strength of potential 
submissions. The WWI stalemate was broken by the invention of the tank. 
We apparently need an equivalent of it :o).

===

Take a look at 
https://github.com/D-Programming-Language/phobos/pull/2687/files. So we 
have a bunch of replacements like "TypeTuple" to "meta.List" and 
"allSatisfy" to "meta.all". Are the new names nicer? Arguably. I like 
them! Do they improve things? I guess. There'd be less confusion about 
TypeTuple not always containing types etc, which does matter. Will they 
have an important contribution to the adoption of D? Very, very little 
if at all, especially compared with the opportunity costs: all the good 
work that WASN'T done by the talented contributors involved while they 
were busy renaming things.

That said https://github.com/D-Programming-Language/phobos/pull/2687 
will probably get pulled. Why? Because it's sensible, and because it's 
there. It's the sensible, okay work that I'm most worried about, even 
more than bad work.

Bad work is visibly undesirable so it won't get far. The problem with 
okay work is it does get implemented and pulled, so it takes away time 
from the great work that does make a difference.


Andrei
Jan 22 2015
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
Things like std.typetuple, while not being as broken as std.json 
implementation-wise, deal good amount of damage being a technical 
debt. It simply unpleasant to build anything on top of it and 
Phobos lacks quite many metaprogramming utilities. It is also a 
small but important step in simplifying related learning curve.

I agree it shouldn't be considered a priority but if there is a 
work done already there - why not?
Jan 22 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/22/15 2:39 PM, Dicebot wrote:

 Things like std.typetuple, while not being as broken as std.json
 implementation-wise, deal good amount of damage being a technical debt.
 It simply unpleasant to build anything on top of it and Phobos lacks
 quite many metaprogramming utilities. It is also a small but important
 step in simplifying related learning curve.

 I agree it shouldn't be considered a priority but if there is a work
 done already there - why not?


I agree! And... I was afraid you were going to say all that. -- Andrei
Jan 22 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 23 January 2015 at 00:52:33 UTC, Andrei Alexandrescu 
wrote:

 On 1/22/15 2:39 PM, Dicebot wrote:

 Things like std.typetuple, while not being as broken as 
 std.json
 implementation-wise, deal good amount of damage being a 
 technical debt.
 It simply unpleasant to build anything on top of it and Phobos 
 lacks
 quite many metaprogramming utilities. It is also a small but 
 important
 step in simplifying related learning curve.

 I agree it shouldn't be considered a priority but if there is 
 a work
 done already there - why not?


 I agree! And... I was afraid you were going to say all that. -- 
 Andrei


Sorry, I don't understand what I have done wrong this time :)

So, to put it clear : do you approve merging 
https://github.com/D-Programming-Language/phobos/pull/2687 in 
general? (without any details about actual std.meta module layout 
etc). Assuming that old std.typetuple will be kept deprecated and 
(eventually) hidden from docs without removal for a very long 
time of course.
Jan 23 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/23/15 7:21 AM, Dicebot wrote:

 So, to put it clear : do you approve merging
 https://github.com/D-Programming-Language/phobos/pull/2687 in general?
 (without any details about actual std.meta module layout etc). Assuming
 that old std.typetuple will be kept deprecated and (eventually) hidden
 from docs without removal for a very long time of course.


I made a pass through the entire document and discussion and it seems to 
need a few improvements before being pulled.

The main issues I see are (a) the names changed from a confusing word to 
a confusing idiom; (b) the Pack template, probably the one thing that 
could add value to the establishment, is private.

So in the bad old times we had this confusing name Typelist in 
std.typelist and some okay/meh names like staticMap and staticIndexOf.

With the new coolness std.typelist.Typelist is std.meta.list.List. That 
is confusing if used standalone as "List" after importing 
"std.meta.list" and a good mouthful to use with full qualification, so 
the following idiom is proposed:

import meta = std.meta.list;

This doesn't sound good. If one is in the need for some list-specific 
stuff, how come they have to import std.meta.list and then call it meta? 
Does one ever use import container = std.container.array?

Also there's only std.meta.list and no other std.meta.xxx. Is there a 
plan there?

Why not use packages etc? Just define TemplateList and TemplatePack in 
std.meta and call it a day.


Andrei
Jan 23 2015
parent "Dicebot" <public dicebot.lv> writes:
Thanks, I have copied your comments to PR to keep it all in one 
place.
Jan 24 2015
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 22 January 2015 at 22:39:12 UTC, Dicebot wrote:

 Things like std.typetuple, while not being as broken as 
 std.json implementation-wise, deal good amount of damage being 
 a technical debt. It simply unpleasant to build anything on top 
 of it and Phobos lacks quite many metaprogramming utilities. It 
 is also a small but important step in simplifying related 
 learning curve.

 I agree it shouldn't be considered a priority but if there is a 
 work done already there - why not?


It is funny how some thing come up again and again. Literally 
everybody is confused as hell by tuples for ages.

As for json, Adam had some very nice work done on this. I'd love 
to see what he did become part of std.json (or something similar 
interfacewize).
Jan 30 2015
prev sibling next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jan 22, 2015 at 01:21:39PM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
[...]

 I'm ambivalent about this; I think it could go either way without
 making a huge impact. (BTW I like GTK's idea to keep the old names
 around. They could be marginalized in the documentation but still
 allow older programs to build.)


+1. I think we should adopt this policy. Deprecated symbols should stick
around basically forever (possibly relegated to a dedicated submodule
publicly imported by the original module, if we don't like accumulating
cruft in the latter), unless they were deprecated because we wanted to
reuse the symbol for something else. So they should basically have no
more documentation after the deprecation cycle but they should still
carry the deprecated() tag to point old code to the right place.


[...]

 That said https://github.com/D-Programming-Language/phobos/pull/2687
 will probably get pulled. Why? Because it's sensible, and because it's
 there.  It's the sensible, okay work that I'm most worried about, even
 more than bad work.


Yay! Does that mean we can merge 2687? :-P


T

-- 
Жил-был король когда-то, при нём блоха жила.
Jan 22 2015
prev sibling parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 01/22/2015 10:21 PM, Andrei Alexandrescu wrote:

 While working on the new site menus I was copying std modules by hand -
 and boy, there's just so much work to be done. Streams, json, encoding,
 mmfile, outbuffer, signals, socket, socketstream, xml, zip - all that
 stuff, maybe a third of the standard library packages, are /known/ to be
 in need of a good revamp (ranging from better documenting to refactoring
 to improving to completely rewriting) yet recently a lot of work has
 been spent on renaming, splitting, ... - shuffling the rubble in the
 garden, especially parts that are already good: container, algorithm,
 range, typecons.

 Moreover, there's a ton of brand new work to be done! We don't have
 standard decent wrappers for libevent or libarchive, networking
 protocols, web servers, databases, and just a ton of other things.


Leave the better part of this to freestanding libraries, they prosper 
much better.

14 database drivers
http://code.dlang.org/?sort=updated&category=library.database
24 networking libraries
http://code.dlang.org/?sort=updated&category=library.network
5 JSON libraries
http://code.dlang.org/search?q=json

A lot of them are quite good and it has become really simple to write a 
nice library that is well tested and documented.
I try to maintain this library as state-of-the-art D project
with dub, ddox, travis-ci and doveralls integration.

https://github.com/MartinNowak/bloom
Jan 30 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/30/15 5:41 AM, Martin Nowak wrote:

 Leave the better part of this to freestanding libraries, they prosper
 much better.

 14 database drivers
 http://code.dlang.org/?sort=updated&category=library.database
 24 networking libraries
 http://code.dlang.org/?sort=updated&category=library.network
 5 JSON libraries
 http://code.dlang.org/search?q=json

 A lot of them are quite good and it has become really simple to write a
 nice library that is well tested and documented.
 I try to maintain this library as state-of-the-art D project
 with dub, ddox, travis-ci and doveralls integration.

 https://github.com/MartinNowak/bloom


I think we need to promote the best of the breed into the standard 
library. -- Andrei
Jan 30 2015
next sibling parent "Martin Nowak" <code dawg.eu> writes:
On Friday, 30 January 2015 at 14:58:14 UTC, Andrei Alexandrescu 
wrote:

 I think we need to promote the best of the breed into the 
 standard library. -- Andrei


True that for anything not too subjective (XML, json, streams), 
but for frameworks it might be healthier to leave decisions open. 
And we shouldn't hurry with choosing libraries. Some real-world 
testing and some alternative implementations are good for natural 
selection.
Jan 30 2015
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 30 January 2015 at 14:58:14 UTC, Andrei Alexandrescu 
wrote:

 On 1/30/15 5:41 AM, Martin Nowak wrote:

 Leave the better part of this to freestanding libraries, they 
 prosper
 much better.

 14 database drivers
 http://code.dlang.org/?sort=updated&category=library.database
 24 networking libraries
 http://code.dlang.org/?sort=updated&category=library.network
 5 JSON libraries
 http://code.dlang.org/search?q=json

 A lot of them are quite good and it has become really simple 
 to write a
 nice library that is well tested and documented.
 I try to maintain this library as state-of-the-art D project
 with dub, ddox, travis-ci and doveralls integration.

 https://github.com/MartinNowak/bloom


 I think we need to promote the best of the breed into the 
 standard library. -- Andrei


Most of those are much better were they are.
Jan 30 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/30/15 9:17 PM, Dicebot wrote:

 On Friday, 30 January 2015 at 14:58:14 UTC, Andrei Alexandrescu wrote:

 On 1/30/15 5:41 AM, Martin Nowak wrote:

 Leave the better part of this to freestanding libraries, they prosper
 much better.

 14 database drivers
 http://code.dlang.org/?sort=updated&category=library.database
 24 networking libraries
 http://code.dlang.org/?sort=updated&category=library.network
 5 JSON libraries
 http://code.dlang.org/search?q=json

 A lot of them are quite good and it has become really simple to write a
 nice library that is well tested and documented.
 I try to maintain this library as state-of-the-art D project
 with dub, ddox, travis-ci and doveralls integration.

 https://github.com/MartinNowak/bloom


 I think we need to promote the best of the breed into the standard
 library. -- Andrei


 Most of those are much better were they are.


Clearly this is a matter in which reasonable people can disagree. It is 
my opinion that more functionality in the standard library is the right 
strategy for D.

Andrei
Jan 30 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Saturday, 31 January 2015 at 05:50:26 UTC, Andrei Alexandrescu 
wrote:

 Clearly this is a matter in which reasonable people can 
 disagree. It is my opinion that more functionality in the 
 standard library is the right strategy for D.

 Andrei


Some functionality is more functional than others :) There is lot 
of good stuff missing in Phobos but turning it into kitchen sink 
mess does not seem a good idea. Also relevant : my remark about 
GUI lib in Phobos : 
http://forum.dlang.org/post/wrwwtzxcohgarqsnftwv forum.dlang.org

I think we should aim to include dub into 2.068 standard 
distribution to make people more aware of all good stuff.
Jan 30 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/30/15 10:17 PM, Dicebot wrote:

 On Saturday, 31 January 2015 at 05:50:26 UTC, Andrei Alexandrescu wrote:

 Clearly this is a matter in which reasonable people can disagree. It
 is my opinion that more functionality in the standard library is the
 right strategy for D.

 Andrei


 Some functionality is more functional than others :) There is lot of
 good stuff missing in Phobos but turning it into kitchen sink mess does
 not seem a good idea.


So... you just repeated your opinion. Should I also repeat mine?


 Also relevant : my remark about GUI lib in Phobos
 : http://forum.dlang.org/post/wrwwtzxcohgarqsnftwv forum.dlang.org


GUI is big enough to be too challenging.


 I think we should aim to include dub into 2.068 standard distribution to
 make people more aware of all good stuff.


That may be getting somewhere.


Andrei
Jan 30 2015
parent "Dicebot" <public dicebot.lv> writes:
On Saturday, 31 January 2015 at 07:17:00 UTC, Andrei Alexandrescu 
wrote:

 Some functionality is more functional than others :) There is 
 lot of
 good stuff missing in Phobos but turning it into kitchen sink 
 mess does
 not seem a good idea.


 So... you just repeated your opinion. Should I also repeat mine?


I think you have just done it already, indirectly :P

Sorry, I simply wasn't sure if it is just the wording or you 
really stand by this opinion currently - if latter is the case, 
so be it :)
Jan 30 2015
prev sibling next sibling parent zeljkog <zeljkog home.com> writes:
On 22.01.15 14:06, Nick Treleaven wrote:

 On 21/01/2015 19:15, zeljkog wrote:

 And good name staticIota, unlike TypeTuple. I always wonder what is raw
 tuple, TypeTuple or Tuple :)


 Yes, there's a DIP to rename std.typetuple to std.meta.list. I made a
 pull to do that (which goes further than the DIP), but I don't know if
 the deprecation/disruption will be acceptable. If not, perhaps we could
 just add a better named alias for TypeTuple (e.g. MetaTuple) but keep
 the same module name. I don't think the status quo is really acceptable.


Maybe RawTuple or CtTuple?
Descriptive and As Short As Possible :)
Jan 22 2015
prev sibling parent "Meta" <jared771 gmail.com> writes:
On Thursday, 22 January 2015 at 13:06:26 UTC, Nick Treleaven 
wrote:

 On 21/01/2015 19:15, zeljkog wrote:

 And good name staticIota, unlike TypeTuple. I always wonder 
 what is raw
 tuple, TypeTuple or Tuple :)


 Yes, there's a DIP to rename std.typetuple to std.meta.list. I 
 made a pull to do that (which goes further than the DIP), but I 
 don't know if the deprecation/disruption will be acceptable. If 
 not, perhaps we could just add a better named alias for 
 TypeTuple (e.g. MetaTuple) but keep the same module name. I 
 don't think the status quo is really acceptable.


I'm excited for that DIP to be implemented so I'll have my own 
Phobos module.
Jan 22 2015
prev sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Wednesday, 21 January 2015 at 18:26:11 UTC, H. S. Teoh via 
Digitalmars-d wrote:

 On Wed, Jan 21, 2015 at 07:14:09PM +0100, zeljkog via 
 Digitalmars-d wrote:

 
 Maybe something like this can be added to Fobos:
 
 template Iota(int start, int stop, int step = 1){
     template tuple(T...){
         alias tuple = T;
     }
     static if(start < stop)
         alias Iota = tuple!(start, Iota!(start + step, stop, 
 step));
     else
         alias Iota = tuple!();
 }


 This is actually already implemented as 
 std.typecons.staticIota, but
 it's currently undocumented and restricted to only Phobos code. 
 I'm not
 sure why it was decided not to make it public, but if you file 
 an
 enhancement request, the devs can look at it and decide if it's 
 worth
 making it public.


 T


There was a PR to make `staticIota` public, but it was superceded 
by a more general `toTypeTuple`[1] that works with any CTFE-able 
range, including the titular `iota`. It too was eventually 
closed, this time because of the whole naming situation. It's an 
unfortunate situation, but now that we've come this far, I think 
the way forward is to go ahead and try to get the std.meta rename 
merged.

[1] https://github.com/D-Programming-Language/phobos/pull/1472
Jan 22 2015