Re: D support for the Meson build system
This looks very nice, but I'm having trouble getting it to work on Windows with DMD. What static linker are you using? DmdDCompiler is defined to need one, but the code in detect_static_linker expects the linker to support the "--version" command-line parameter (or "/?" if the linker is named "lib" or "lib.exe"). DMD's "lib.exe" doesn't support "--version" or "/?". I suspect this is what I should be pointing it to, but the term "static linker" confuses me - maybe I want to be pointing it to "link.exe". DMD's "link.exe" doesn't support "--version" but does support "/?". I can hack around this, but I'm wondering why I'm alone in encountering this. Thanks!
Re: DIP: Tail call optimization
On Monday, 11 July 2016 at 17:31:23 UTC, Dietrich Daroch wrote: On Monday, 11 July 2016 at 16:27:38 UTC, Andrew Godfrey wrote: [...] * It must not be ignorable by the compiler. * It must generate an error if that compiler would be unable to do the TCO. Otherwise, the compiler *may* (not "must") apply the TCO, unless compiled under (some optimization level, please specify), in which case it *must* apply TCO. One difficulty with this is the words "that compiler". I.e. other compilers are free to be unable to make the TCO. This means that by using this feature, you have made your code non-portable. I think that noticing problems while porting it it's better than having it crash unexpectedly as it would currently happen. Sure, non-portability that causes a guaranteed compiler error, is better than other kinds of non-portability. But it's still non-portable. That is distasteful enough that you probably need to make a more compelling case; factorial is a "toy" function that's not enough - on its own - to justify adding a feature. I personally feel like it is a neat idea, and it may enable some programming styles that I'm not familiar with so I can't say they definitively they have no value. The reason I'm not familiar with them could be that I've never had this feature in a language I've used a lot. So there could be something here, BUT I also think it would need to be a portable feature, which implies much more rigorous rules that all compilers would have to follow. (They could still do TCO for more complicated situations, but those wouldn't interact with this feature; to make use of this feature you'd have to conform to the more rigorous rules). P.S. You have proposed annotating the function with @tco - it seems more like it's the call site that needs to be annotated. I'm not sure about how to do annotations on the call site. Would a new keyword be required? I don't know this. (E.g. Are attributes allowed at the beginning of a statement?)
Re: DIP: Tail call optimization
On Monday, 11 July 2016 at 15:27:54 UTC, Dietrich Daroch wrote: On Monday, 11 July 2016 at 14:36:22 UTC, Andrew Godfrey wrote: On Monday, 11 July 2016 at 10:25:36 UTC, Tofu Ninja wrote: On Sunday, 10 July 2016 at 13:15:38 UTC, Andrew Godfrey wrote: Btw here's a thread from 2014 that touches on the idea of a "tailrec" annotation. At the time, Walter viewed the optimization as the compiler's business and not something he'd elevate to a language feature: http://forum.dlang.org/post/lqp6pu$1kkv$1...@digitalmars.com I find it odd that something like tail recursions that actually makes certain things possible that wouldn't be otherwise is seen as only an optimization, when things like inlining which really is only an optimization is seen as important enough to have a pragma. I agree. Maybe Walter has reconsidered since then. He did also say, though, that he thinks D supports enough different programming styles already. Would you be satisfied with a pragma? I'd intuited (but could be wrong) that the focus of your proposal was to get a compiler error if someone makes a change to a recursive function, that causes the compiler to be unable to apply the TCO optimization. If that is your focus, it has heavy implications and the feature can't just be a pragma. Pragma does not seem enough, at least current pragmas can be ignored by the compilers (http://dlang.org/spec/pragma.html#predefined-pragmas), but if it's required for tco it can make it. Ola addressed the "bounded stack" idea. TCO is hard enough, I'll stick to that: When people say "it should be a pragma", I think they particularly are saying, "it should be ignorable by the compiler". That is a different feature. I think you need to lay out *exactly* what you want it to do - because doing so will raise the questions that need to be answered. I'll take a stab, but this may not be the direction you're pushing in. This is a straw man to illustrate the difficulties I see: * It must not be ignorable by the compiler. * It must generate an error if that compiler would be unable to do the TCO. Otherwise, the compiler *may* (not "must") apply the TCO, unless compiled under (some optimization level, please specify), in which case it *must* apply TCO. One difficulty with this is the words "that compiler". I.e. other compilers are free to be unable to make the TCO. This means that by using this feature, you have made your code non-portable. If you additionally want to make it portable, then you need to specify the conditions under which *any valid compiler* must be able to apply the TCO. Also, you need to make the feature generate a compiler error if it is used under other conditions. This all seems rather difficult; at any rate, I don't see any hints in the current proposal about what these rules would be. (Even a rule as simple as "the call must be to the same function" could be tricky.) P.S. You have proposed annotating the function with @tco - it seems more like it's the call site that needs to be annotated.
Re: DIP: Tail call optimization
On Monday, 11 July 2016 at 10:25:36 UTC, Tofu Ninja wrote: On Sunday, 10 July 2016 at 13:15:38 UTC, Andrew Godfrey wrote: Btw here's a thread from 2014 that touches on the idea of a "tailrec" annotation. At the time, Walter viewed the optimization as the compiler's business and not something he'd elevate to a language feature: http://forum.dlang.org/post/lqp6pu$1kkv$1...@digitalmars.com I find it odd that something like tail recursions that actually makes certain things possible that wouldn't be otherwise is seen as only an optimization, when things like inlining which really is only an optimization is seen as important enough to have a pragma. I agree. Maybe Walter has reconsidered since then. He did also say, though, that he thinks D supports enough different programming styles already. Would you be satisfied with a pragma? I'd intuited (but could be wrong) that the focus of your proposal was to get a compiler error if someone makes a change to a recursive function, that causes the compiler to be unable to apply the TCO optimization. If that is your focus, it has heavy implications and the feature can't just be a pragma.
Re: DIP: Tail call optimization
Btw here's a thread from 2014 that touches on the idea of a "tailrec" annotation. At the time, Walter viewed the optimization as the compiler's business and not something he'd elevate to a language feature: http://forum.dlang.org/post/lqp6pu$1kkv$1...@digitalmars.com
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 05:03:46 UTC, Dietrich Daroch wrote: Hi everyone (= I've just added a new proposal to add a new attribute to ensure TCO is applied. The proposal is really simple, but I'm clueless on how to implement it and also interested on getting feedback on it. The proposal it's ready for merge on the new [DIPs repo](https://github.com/dlang/DIPs/pull/6) -- Dietrich I'll chime in to give a counterpoint to the ... I'll say "immature" discussion this generated. Just my opinion: Yes, an attribute to express something you expect the compiler to do, has value. (Clearly some people on here don't have experience with a codebase that is maintained by thousands of people). Even if compilers aren't required to implement TCO, it could work (compilers which didn't, would always give an error if you used the attribute). But it would then feel weird to me to use this attribute, knowing that some compilers would pass it and some would fail it. And compilers which always fail it, would feel pressure to do better. Whether this is good depends on your outlook. D does think of itself as "multi-paradigm", so maybe it should push on this. Personally I could see myself making use of this, but not being very sad if it didn't happen. I do prefer your more verbose proposals over "@tco" - a short abbreviation doesn't feel appropriate.
Re: Vision document for H2 2016
On Thursday, 7 July 2016 at 19:55:51 UTC, Andrei Alexandrescu wrote: https://wiki.dlang.org/Vision/2016H2 -- Andrei I see that this thread has sparked a lot of "ideas for the future". That's a great outcome but many of them don't belong in this vision document, and in fact some probably deserve mention in the vision doc as "great ideas the leadership won't be funding yet - but feel free to drive it yourself if you feel passionate about it". I think this is important because it would greatly raise satisfaction with the vision doc, if it was more clear "what it is not". So I'm wondering if there are ways to improve the structure. 1) A link to that action list, placing it in context relative to this doc, and encouraging people to add their ideas like "rust aliases" there instead of here. (Or maybe you have a better place for this, like a forum where such requests are discussed first). 2) A link to a longer-term vision doc. The question I posted recently in "general", about the evolution of the language, is the kind of thing I would want to see answered there. Another kind of thing is anything "long term strategic" that isn't a priority right now - e.g. pain points for new adopters that "we can't work on yet" (e.g. "there are 3 compilers, and many practitioners end up installing at least 2 of them"). And generally, I'd like a place that sets long term expectations, e.g. the rate of future deprecation of existing features in the language and in Phobos.
Re: Perl6 Unicode support
On Sunday, 12 June 2016 at 08:15:37 UTC, ag0aep6g wrote: On 06/12/2016 05:16 AM, Andrew Godfrey wrote: Eg it says ".chars returns the number of characters (aka graphemes)" Does this count the number of graphemes, or the number of grapheme clusters? Later on with \r\n it pretty much says that it counts grapheme clusters. Here it says it counts graphemes. Sorry, I still don't get it. Can you give an example string where counting graphemes gives a different result from counting grapheme clusters? Huh. On researching "grapheme cluster", I see it is a weird Unicode term that apparently means the same thing as grapheme. Definitely something to avoid in an article (or, explain very carefully). To the uninitiated, "grapheme cluster" means "a cluster of graphemes" and implies a one-to-many mapping.
Re: Perl6 Unicode support
On Saturday, 11 June 2016 at 19:43:45 UTC, ag0aep6g wrote: On 06/11/2016 09:25 PM, Andrew Godfrey wrote: That's the distinction, yes. The article mentions both in a way that makes me unsure if Perl 6 confused the terms (or maybe it's just the article that isn't being clear). But how would you "focus" on one or the other? Is there any operation that works differently on graphemes than on grapheme clusters? Counting/skipping/extracting graphemes is the same as counting grapheme clusters, no? Eg it says ".chars returns the number of characters (aka graphemes)" Does this count the number of graphemes, or the number of grapheme clusters? Later on with \r\n it pretty much says that it counts grapheme clusters. Here it says it counts graphemes.
Re: Perl6 Unicode support
On Saturday, 11 June 2016 at 18:33:04 UTC, ag0aep6g wrote: On 06/11/2016 06:47 PM, Andrew Godfrey wrote: OTOH, it mentions both graphemes and grapheme clusters, without much distinction. So I'm not exactly sure which is the default focus. What distinction is there to be made? As far as I understand, a grapheme cluster is a sequence (or cluster) of code points that together represent one grapheme. That's the distinction, yes. The article mentions both in a way that makes me unsure if Perl 6 confused the terms (or maybe it's just the article that isn't being clear).
Re: Perl6 Unicode support
On Wednesday, 11 May 2016 at 12:11:32 UTC, Guillaume Chatelet wrote: It looks good: https://perl6advent.wordpress.com/2015/12/07/day-7-unicode-perl-6-and-you/ Especially, it works in graphemes, and ".codes" lets you count code points. The article isn't even mentioning "code units". OTOH, it mentions both graphemes and grapheme clusters, without much distinction. So I'm not exactly sure which is the default focus.
Re: Interfacing D to existing C++ code
Is it common for a C++ library you want to interface to, to use std library types in its interface? Things like iterators or maybe containers. Do those hit any of the hard cases, so that you'd need to change the std library to resolve the issue?
Re: Fix #2529: explicit protection package #3651
On 8/26/14, 9:46 AM, Dicebot wrote: ...and it has just been merged! ^_^ Thanks Walter! Nice! This felt like a glaring hole, and you've filled it!
