Re: Compile time iota
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.
Re: Compile time iota
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=updatedcategory=library.database 24 networking libraries http://code.dlang.org/?sort=updatedcategory=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
Re: Compile time iota
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=updatedcategory=library.database 24 networking libraries http://code.dlang.org/?sort=updatedcategory=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.
Re: Compile time iota
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/wrwwtzxcohgarqsnf...@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.
Re: Compile time iota
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).
Re: Compile time iota
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/wrwwtzxcohgarqsnf...@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
Re: Compile time iota
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 :)
Re: Compile time iota
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=updatedcategory=library.database 24 networking libraries http://code.dlang.org/?sort=updatedcategory=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
Re: Compile time iota
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=updatedcategory=library.database 24 networking libraries http://code.dlang.org/?sort=updatedcategory=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
Re: Compile time iota
Thanks, I have copied your comments to PR to keep it all in one place.
Re: Compile time iota
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
Re: Compile time iota
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.
Re: Compile time iota
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.
Re: Compile time iota
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 :)
Re: Compile time iota
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).
Re: Compile time iota
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
Re: Compile time iota
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?
Re: Compile time iota
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
Re: Compile time iota
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.
Re: Compile time iota
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 -- Жил-был король когда-то, при нём блоха жила.
Re: Compile time iota
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
Re: Compile time iota
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.
Compile time iota
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!();
}
Re: Compile time iota
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 :)
