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