Re: DIP1001: Exception Handling Extensions
On Sun, 10 Jul 2016 21:55:04 +, Superstar64 wrote: > You could use both c style and d stack unwinding: I misread that. The tagged union part applies even if the function can throw some types that don't participate in the compile-time error system.
Re: DIP: Tail call optimization
On Tuesday, 12 July 2016 at 01:42:13 UTC, Andrew Godfrey wrote: 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). I've thought about using pragmas and they would allow for an easier implementation if ignored pragmas raise warnings (and errors with strict flags) when a pragma was ignored. Under that setup, people who need the errors can enable the flags, while people who doesn't care about this can just ignore/disable the warnings and keep their programs without need for rewrite. Also, using pragmas requires no change on the grammar, nor adding new attributes that most people really dislike (I still don't get why, probably the text editors should take care to make them less distracting or even hiding them).
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: Announcing new DIP handling process
On Saturday, 9 July 2016 at 12:56:48 UTC, Dicebot wrote: After quite some preliminary discussions and preparations, new D Improvement Proposals handling process is finally happenning. Please read description and explanation here: [...] On reddit Steve Klabnik from the Rust team mentioned that they are currently trying to refine their RFC process. It could be worthwhile to learn from their experiences: http://aturon.github.io/blog/2016/07/05/rfc-refinement/ https://github.com/rust-lang/rfcs
Re: DIP1001: Exception Handling Extensions
On Sunday, 10 July 2016 at 19:55:37 UTC, Superstar64 wrote: link: https://github.com/dlang/DIPs/pull/9 file: https://github.com/Superstar64/DIPs/blob/exception_extensions/DIPs/DIP1001.md I'm not too familiar with stack unwinding generation, but would generating a separate unwind table for each type(that doesn't inherit from Throwable) be faster than the current handling? Is it worth adding it to the DIP?
Re: DIP: Tail call optimization
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. 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?
Re: NanoSVG port
also, i extended the original library a little: added rudimentary support for "style" tag and styling svg elements. nothing fancy, but many svgs found in internet are using that to avoid repeating "style" everywhere. it is a dirty hack (sorry), but makes even more svgs "renderable".
new cpuid is ready for comments
Hello :-) `cpuid` package is core.cpuid analog. It would be used by future D BLAS implementation. Why it is better? See https://github.com/libmir/cpuid#api-features https://github.com/libmir/cpuid#implementation-features https://issues.dlang.org/show_bug.cgi?id=16028 Please report your CPU (GitHub/Gist): ``` dub fetch cpuid dub test cpuid ``` ... AMD was not tested at all and I hope to see your reports. ARM contributors are wanted! Destroy! Best regards, Ilya Docs: http://docs.cpuid.dlang.io GitHub: https://github.com/libmir/cpuid Dub: cpuid
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 16:18:47 UTC, Dietrich Daroch wrote: Previous discussion seems to favour @unboundedStack as it can become a requirement to go beyond the stack-size-safe operations effectibly tracking where stack overflow may happen and encourage detailed review of those functions. I would favour it, but I am not a DMD developer ;-) Walter's concern is that a great amount of the D runtime library would make this unpractical. Maybe another attribute to promise bounded stack without a proof might be required to make the idea viable. I really think that this kinds of proofs are somewhat natural in D, as it follows ideas like contracts, and safe/trusted attributes. Yes. Although keep in mind that DMD does not have a shared intermediate representation, so each backend probably might have to implement it over a low level SSA which may or may not be suitable. So, if they have to implement 3 different versions of it for DMD, LDC and GDC what are then the chances that this will pass? Contrast this to a language like Whiley which has an intermediate representation geared towards theorem-proving. Would D benefit from a shared intermediate representation suitable for static analysis? Sure. But you probably need more than a single feature-request to get there.
Re: DIP: Tail call optimization
On Monday, 11 July 2016 at 15:48:08 UTC, Ola Fosheim Grøstad wrote: On Monday, 11 July 2016 at 15:27:54 UTC, Dietrich Daroch wrote: I've been thinking about changing @tco for @boundedStack, as it'll really reflect guarantees on functions while implicitly asking for TCO on functions that require it. But the fact that most functions should be marked as @boundedStack is something that bothers me. Just keep in mind that a @tco constraint is much easier to implement than @boundedStack. I don't do tail calls much, but I think you have the right idea for a system level language: specify the constraints you want to hold rather than explicitly laying out everything manually. That's what I expect from a modern system level language. I have previously argued in favour of something similar like @boundedStack, but there is quite a bit of resistance against (and lack of interest in) solid static analysis in the D community. You probably will save yourself some trouble by reading one of the numerous threads touching on stack handling in D. Here is one: http://forum.dlang.org/post/logpgo$2k1d$1...@digitalmars.com Previous discussion seems to favour @unboundedStack as it can become a requirement to go beyond the stack-size-safe operations effectibly tracking where stack overflow may happen and encourage detailed review of those functions. Walter's concern is that a great amount of the D runtime library would make this unpractical. Maybe another attribute to promise bounded stack without a proof might be required to make the idea viable. I really think that this kinds of proofs are somewhat natural in D, as it follows ideas like contracts, and safe/trusted attributes.
Re: DIP: Tail call optimization
On Monday, 11 July 2016 at 15:27:54 UTC, Dietrich Daroch wrote: I've been thinking about changing @tco for @boundedStack, as it'll really reflect guarantees on functions while implicitly asking for TCO on functions that require it. But the fact that most functions should be marked as @boundedStack is something that bothers me. Just keep in mind that a @tco constraint is much easier to implement than @boundedStack. I don't do tail calls much, but I think you have the right idea for a system level language: specify the constraints you want to hold rather than explicitly laying out everything manually. That's what I expect from a modern system level language. I have previously argued in favour of something similar like @boundedStack, but there is quite a bit of resistance against (and lack of interest in) solid static analysis in the D community. You probably will save yourself some trouble by reading one of the numerous threads touching on stack handling in D. Here is one: http://forum.dlang.org/post/logpgo$2k1d$1...@digitalmars.com
Re: DIP: Tail call optimization
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. I've been thinking about changing @tco for @boundedStack, as it'll really reflect guarantees on functions while implicitly asking for TCO on functions that require it. But the fact that most functions should be marked as @boundedStack is something that bothers me. The complement, @unboundedStack, might be better, as it would explicitly mark the functions that might cause stack overflows so they drag required attention and would also force the compiler to do TCO where required. Focusing on stack size, rather than directly on TCO might even allow to guarantee that many D programs do not crash due to a stack overflow, which is a nice guarantee that not many languages, allow to express. I'd like thoughts on this change of perspective. BTW, I'm glad that discussion has arised, as it can only make the propossal better.
Re: Berlin D Meetup July 2016
On Monday, 11 July 2016 at 10:05:15 UTC, Ben Palmer wrote: Hi All, The July Berlin D Meetup will be happening at 20:00 on Friday the 15th of July at Berlin Co-Op (http://co-up.de/) on the fifth floor. This time we will be doing a hackathon with DUB. Mathias Lang will be present to give a brief introduction, provide assistance, and point people in the direction of open issues that would be good to get sorted. Sociomantic have come to the party once more and will be sponsoring food (including vegetarian options) and drinks (both alcoholic and non-alcoholic). More details are available on the meetup page here: http://www.meetup.com/Berlin-D-Programmers/events/232532625/ Thanks, Ben. Hi, I'll try to be there.
Re: DIP1001: Exception Handling Extensions
On Monday, 11 July 2016 at 14:44:08 UTC, Seb wrote: On Monday, 11 July 2016 at 12:36:59 UTC, Basile B. wrote: On Sunday, 10 July 2016 at 19:55:37 UTC, Superstar64 wrote: link: https://github.com/dlang/DIPs/pull/9 file: https://github.com/Superstar64/DIPs/blob/exception_extensions/DIPs/DIP1001.md https://forum.dlang.org/post/auplvezvpisiufwvd...@forum.dlang.org @SuperStar64, please ignore the troll(s) and keep working on your proposal by incorporating the constructive critic you have received so far. As Dicebot already stated it's very important to provide good & convincing arguments in favor of your proposal because changing a language isn't a simple thing and (may) have wide implications. Yes, please get on, even if there's a possibility that you've been misleaded by a guy who thinks he's a manager, but is not and, maybe has made a "management error".
Re: DIP1001: Exception Handling Extensions
On Monday, 11 July 2016 at 12:36:59 UTC, Basile B. wrote: On Sunday, 10 July 2016 at 19:55:37 UTC, Superstar64 wrote: link: https://github.com/dlang/DIPs/pull/9 file: https://github.com/Superstar64/DIPs/blob/exception_extensions/DIPs/DIP1001.md https://forum.dlang.org/post/auplvezvpisiufwvd...@forum.dlang.org @SuperStar64, please ignore the troll(s) and keep working on your proposal by incorporating the constructive critic you have received so far. As Dicebot already stated it's very important to provide good & convincing arguments in favor of your proposal because changing a language isn't a simple thing and (may) have wide implications.
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
On Monday, 11 July 2016 at 12:29:33 UTC, Basile B. wrote: 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 Oh no, another consequence of the wilzaback. He has announced everywhere that it's possible to make DIPs on github...what a surpise to see that. I am happy to learn why posting the announcement to reddit was a mistake. The reception was entirely positive and as Dicebot pointed out, having a formal process about language changes is a must-have criteria for many companies and thus a blocker for further adaption of D. On the contrary I think it was a wake-up call for people being frustrated with some deficits of D. Moreover I am not sure why you keep misspelling my lastname. If eight letter are to difficult to memorize for you, you might want to stop complaining about deficit's of other people. So...Dietrich, do you use D a bit at least ? Or do you come because you read r/programming or hackernews ? Did you take the time to look at the DIP before making your offenses? Dietrich has already published D modules on Github which you would have seen if you be generally interested and not trolling. As other people already have stated the DIP is not trivial and the only thing that was sub-optimal was it's announcement in News before being fleshed out, but to be fair Dietrich just followed the new DIP process protocol, which still needs fine-tuning in its details. However without motivated alpha warriors like Dietrich such fine-tuning can't happen, so you should be more thankful to him. @Dietrich: Don't let yourself distract by trolls. Keep on improving your DIP and making it great & convincing!
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 Would something like Clojure's recur and trampoline do what you want? http://www.clojure.org/about/functional_programming#_recursive_looping A number of Common Lisp programmers like to use those functions because TCO is then guaranteed, and unlike Common Lisp where you don't know for sure what will happen, it is explicit.
Re: DIP1001: Exception Handling Extensions
On Sunday, 10 July 2016 at 19:55:37 UTC, Superstar64 wrote: link: https://github.com/dlang/DIPs/pull/9 file: https://github.com/Superstar64/DIPs/blob/exception_extensions/DIPs/DIP1001.md https://forum.dlang.org/post/auplvezvpisiufwvd...@forum.dlang.org
Zurich D Meetup
sorry for the short notice, but i'm glad to host Ilya with a talk on scientific computing with D. more infos here: http://www.meetup.com/de-DE/Zurich-D-Programming-Language-Meetup/events/232534480/?eventId=232534480
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 Oh no, another consequence of the wilzaback. He has announced everywhere that it's possible to make DIPs on github...what a surpise to see that. So...Dietrich, do you use D a bit at least ? Or do you come because you read r/programming or hackernews ?
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 In the future I'd recommend to delay announcing DIP until it get to the point of being merged into the queue (I'd do it myself at that point). Right now there are quite some boring technical details to be fleshed out before it becomes a complete proposal - asking for community feedback is likely to be time-inefficient. And sorry for some of the inadequate responses you got here. D language authors don't want to enforce any code of conduct or moderation in the newsgroup which means certain personas have to be simply ignored. In the end only thing that should matter is a good technical document to be merged into the queue.
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 17:10:32 UTC, Dietrich Daroch wrote:
On Sunday, 10 July 2016 at 16:52:09 UTC, Ola Fosheim Grøstad
wrote:
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.
Why should it be part of the function prototype? @nogc makes
sense, because it is a guarantee for the caller.
@tco does not bring any guarantees to the caller, so you might
as well annotate the call-site with some compiler specific
feature.
Annotating every callsite seems uncomfortable, being able to
perform TCO is a property of the function and not something
that might look call-site dependant.
You are thinking about recursive functions only, but actually a
"tail call" has nothing to do with recursion. Example:
int foo() { return 42; }
int bar() { return foo(); }
There is no recursion, but a tail call in bar and you may want
the the compiler to optimize it.
If you want to turn recursive functions into loops, then you
should change to name imho. Maybe @stackbounded.
It could be a function property, if you want recursions of more
than one function to be bounded wrt stack space. You could then
require that @tco functions can only call other @tco functions.
Example:
@tco int foo(int x) { if (x < 42) return x; else return
bar(x-1); }
@tco int bar(int x) { if (x < 41) return x; else return
foo(x-5); }
Also, you might want to compiler switch to disable to
optimization for debugging. TCO may be confusing, when you run
your in a debugger.
Overall, this DIP is not as trivial as it looks. I would like to
see a more convincing use case/example as a justification.
Re: DIP: Tail call optimization
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.
Berlin D Meetup July 2016
Hi All, The July Berlin D Meetup will be happening at 20:00 on Friday the 15th of July at Berlin Co-Op (http://co-up.de/) on the fifth floor. This time we will be doing a hackathon with DUB. Mathias Lang will be present to give a brief introduction, provide assistance, and point people in the direction of open issues that would be good to get sorted. Sociomantic have come to the party once more and will be sponsoring food (including vegetarian options) and drinks (both alcoholic and non-alcoholic). More details are available on the meetup page here: http://www.meetup.com/Berlin-D-Programmers/events/232532625/ Thanks, Ben.
Re: First dmd nightly shipping with dub
When packaging dub with a compiler, it'd be nice if dub per default selected the compiler it came packaged with, I think. (it currently doesn't) Perhaps people can chime in here with ideas? https://github.com/dlang/dub/issues/895 https://github.com/dlang/dub/pull/875 Thanks, Johan
