Re: DIP1001: Exception Handling Extensions
On Sunday, 10 July 2016 at 21:52:37 UTC, Lodovico Giaretta 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 I'm not convinced by this proposal. Here are some early thoughts: 1) Wouldn't a library solution based on functional-style tagged results achieve the same without changing the language and making things less clear (see my other points)? Something on the lines of variant? 2) Wouldn't this make code quite obscure? I mean, now if you see a throw or a catch you know what's going on. With this proposal, when you see a throw or a catch, you have to go look at the declaration of the thrown or catched type to get what's going on. This proposal allows you to switch between error code handling and stack unwinding by just switching one line of code. 3) From your proposal, it seems that current exception handling needs the GC, which is not true; you can already do exception handling in @nogc code, without any extra quirk. Wouldn't that still require allocation for the exception's message and stack trace? 4) C++ deprecated throw lists; while this does not automatically mean that they are bad, we shall learn from others' errors, and be very careful. Throw lists where added because they are required for this to work with incremental compilation. But all of this is just my opinion based on a fast read of the proposal. P.S.: something went wrong (probably with copy-pasting) here: A function which calls a sub function with a @throws(TypeList) attribute must have alluncaught possible exceptions must be a part of the @throws(TypeList) attribute of the caller function. Nothing wrong on my end.
Re: DIP1001: Exception Handling Extensions
On Sunday, 10 July 2016 at 21:43:08 UTC, Chris Wright wrote:
On Sun, 10 Jul 2016 19:55:37 +, Superstar64 wrote:
link: https://github.com/dlang/DIPs/pull/9 file:
https://github.com/Superstar64/DIPs/blob/exception_extensions/DIPs/
DIP1001.md
So if my function calls any runtime functions -- it allocates
memory, slices an array, etc -- I can't use C-style exception
handling. Unless I manually do something like:
struct ThrowableWrapper {
Throwable error;
}
int[] foo(int i) {
try {
return [i];
} catch (Throwable t) {
throw ThrowableWrapper(t);
}
}
You could use both c style and d stack unwinding:
---
struct CustomErrorCode
{
enum __ErrorCode = true;
}
struct CustomUnwind
{
}
int foo(int[] arr, int index)
@throws(Throwable,CustomErrorCode,CustomUnwind)
{
auto val = arr[index]; // may throw RangeError with d's
existing handling
if (val == 0xdead)
{
throw CustomErrorCode(); // throws using new error code
handling
}
else if (val == 0xbad)
{
throw CustomUnwind(); // throws using new by value
unwinding
}
}
---
Or possible wrap your function in a template that catch Unwind
exceptions and throws Error Codes.
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 convinced by this proposal. Here are some early thoughts: 1) Wouldn't a library solution based on functional-style tagged results achieve the same without changing the language and making things less clear (see my other points)? Something on the lines of variant? 2) Wouldn't this make code quite obscure? I mean, now if you see a throw or a catch you know what's going on. With this proposal, when you see a throw or a catch, you have to go look at the declaration of the thrown or catched type to get what's going on. 3) From your proposal, it seems that current exception handling needs the GC, which is not true; you can already do exception handling in @nogc code, without any extra quirk. 4) C++ deprecated throw lists; while this does not automatically mean that they are bad, we shall learn from others' errors, and be very careful. But all of this is just my opinion based on a fast read of the proposal. P.S.: something went wrong (probably with copy-pasting) here: A function which calls a sub function with a @throws(TypeList) attribute must have alluncaught possible exceptions must be a part of the @throws(TypeList) attribute of the caller function.
Re: DIP1001: Exception Handling Extensions
On Sunday, 10 July 2016 at 20:30:56 UTC, Stefan Koch 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 You don't have to use gc-allocated exceptions anyway. Allowing to throw any type makes chaining impossible. Can you please explain why it makes chaining impossible?
Re: DIP1001: Exception Handling Extensions
On Sun, 10 Jul 2016 19:55:37 +, Superstar64 wrote:
> link: https://github.com/dlang/DIPs/pull/9 file:
> https://github.com/Superstar64/DIPs/blob/exception_extensions/DIPs/
DIP1001.md
So if my function calls any runtime functions -- it allocates memory,
slices an array, etc -- I can't use C-style exception handling. Unless I
manually do something like:
struct ThrowableWrapper {
Throwable error;
}
int[] foo(int i) {
try {
return [i];
} catch (Throwable t) {
throw ThrowableWrapper(t);
}
}
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 Adding another attribute to the language and having the compiler do magic behind the scenes? No thanks.
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 You don't have to use gc-allocated exceptions anyway. Allowing to throw any type makes chaining impossible.
DIP1001: Exception Handling Extensions
link: https://github.com/dlang/DIPs/pull/9 file: https://github.com/Superstar64/DIPs/blob/exception_extensions/DIPs/DIP1001.md
Re: First dmd nightly shipping with dub
On 2016-07-08 22:43, Martin Nowak wrote: That actually indicates that shipping dub with dmd isn't that useful. I think it's very useful, if nothing else to increase the awareness of Dub. Doesn't hurt to have a separate binary as well. -- /Jacob Carlborg
Re: Vision document for H2 2016
On 2016-07-10 19:09, Robert burner Schadek wrote: Yes if anybody had access to the trello and would want to use yet another tool. I think that is unrealistic. Trello is already used: https://trello.com/dlang -- /Jacob Carlborg
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 17:32:32 UTC, Dietrich Daroch wrote: It might be interesting to have proof that the stack is bounded (and won't overflow). Yes, a stack depth guarantee would be useful for D fibers.
Re: First dmd nightly shipping with dub
On Friday, 8 July 2016 at 20:43:58 UTC, Martin Nowak wrote: On 07/08/2016 11:22 AM, Dicebot wrote: On Friday, 8 July 2016 at 09:13:08 UTC, Martin Nowak wrote: What would be the use-case for those? Using newer dub versions with an older compiler? Or simply using dub with ldc/gdb without also installing dmd. Kai is working on shipping LDC releases with Dub too! -Johan
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 17:16:10 UTC, Ola Fosheim Grøstad wrote: On Sunday, 10 July 2016 at 17:10:32 UTC, Dietrich Daroch wrote: 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 only need to annotate the location where the function calls itself. The function might want some recursive calls to work without tail recursion restrictions and at the same time use tail recursion at the end. Or do you mean that this should prevent all kinds of recursion? That is a quite demanding analysis. For instance, the function could get itself passed in as a parameter... My bad, I misunderstood your point. Annotating recursive calls seems more flexible. Now the question is how should they be annotated? pragma is verbose, but avoids adding keywords. I think a constant stack size annotation would still make sense, but might not promise that stack overflows are not possible if a lot of local data is used and a big, but constant numbers of calls are made. It might be interesting to have proof that the stack is bounded (and won't overflow).
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 17:10:32 UTC, Dietrich Daroch wrote: 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 only need to annotate the location where the function calls itself. The function might want some recursive calls to work without tail recursion restrictions and at the same time use tail recursion at the end. Or do you mean that this should prevent all kinds of recursion? That is a quite demanding analysis. For instance, the function could get itself passed in as a parameter...
Re: Vision document for H2 2016
On Friday, 8 July 2016 at 18:04:16 UTC, Andrei Alexandrescu wrote: It seems to me six months is a sweet spot. Large companies such as Google and Facebook also use a six-months horizon because it's long enough to avoid micromanagement hysteria and short enough to be verifiable and accountable. Yes, I do have a vision for a longer horizon, but it's too vague to be useful - "D will be a major programming language by 2020". But we are not Facebook or Google. And I bet even they have some mid/long-term visions. I consider it competition with other things that Walter and I need to worry about. Walter put it cleverly: you can't add more administration without administrators. IMO that is wrong, well not so much wrong as misleading. We don't just need more administration because we need more administration. We need more administration or lets say more management and delegation to get things done. A semestrial vision document summarizing our outlook and intentions is about as much as we can bear. Well, you and Walter graduated from engineering to management. That, reviewing other peoples work and delegating is your job now. Like it or not. Would trello help with that kind of stuff? Yes if anybody had access to the trello and would want to use yet another tool. I think that is unrealistic. But we already have the wiki and github. So extending the VD to rolling VD in the wiki is the way to go IMO. Or move everything to github including bugtracker and start using milestones etc. Again, IMO in the long run a long term VD, updated on a need to basis with subtasks will save you work. I don't think preapproved work would lead to less rejection. Rejection is of work of insufficient quality, not of work that has not been preapproved. Conversely, preapproval does not guarantee any work will be actually approaved. Considering the current event is disagree. Maybe preapproved work is not the right wording. Maybe preapproved designs.
Re: DIP: Tail call optimization
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. Ok, I see as why it can be useless for the caller, maybe this should morph into a more general constant stack size growth annotation, but I don't see uses other than enforcing TCO.
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 16:52:09 UTC, Ola Fosheim Grøstad wrote: @tco does not bring any guarantees to the caller, so you might as well annotate the call-site with some compiler specific feature. actually, annotating the call itself seems to have alot more sense judging from described OP inspiration for the feature.
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 06:17:08 UTC, ketmar wrote: your DIP is aimed for is brain-damaged coders who are not able to understand how programs work (and why "scope(exit)" may prevent TCO). it won't help anyone. sorry. This is really unacceptablely rude. Step away from the computer and cool off.
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. 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.
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 12:01:54 UTC, Andrew Godfrey 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 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. If you look at it as trying to make the build fail, then it's definitely weird, but I think the point is to be able to state your expectations and get feedback from the compiler on those, the same as we already do with static typing. I feel the same about the multi-paradigm thing, D supports functional programming, so it definitely needs to ensure executions are efficient for people coming from functional languages. Probably recursion is more natural to them than manually unrolling to avoid a problem that did not existed in their previous language. I personally prefeer longer names, but I felt that @tco followed @nogc. We should consider what other languages have this kind of annotation to get a reasonable name for newcomers. Scala has @tailrec and it seeks the same goal as this DIP, finding wrong assumptions and seeking to ensure having a bounded call stack.
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 11:17:17 UTC, ag0aep6g wrote: Your quote leaves out the "because" part, which is the interesting part. because it is irrelevant.
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 10:50:20 UTC, "Smoke" Adams wrote: You are not i am.
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: DIP: Tail call optimization
On 07/10/2016 12:21 PM, ketmar wrote: On Sunday, 10 July 2016 at 09:46:24 UTC, ag0aep6g wrote: So when one makes a post here saying that "D is aimed at brain-dead people", we shouldn't take that for an insult. absolutely. but "D is crap" is whole different story. Your quote leaves out the "because" part, which is the interesting part.
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 09:20:07 UTC, ketmar wrote: On Sunday, 10 July 2016 at 09:05:46 UTC, Tofu Ninja wrote: Your joking right? No personal attacks? where do you see personal attack in my words? i'm not saying that OP is dumb, and i'm not saying that his proposal is dumb. but it is *aimed* to dumb people (which doesn't automatically makes it dumb, you know). and i got tired of being "polite", from now on when i'll see dumb people, i'll say that i see dumb people, not "different" or "mentally impaired". as for the topic, i *tried* to explain why i see no value in the proposal. and part of the explanation included referring to "brain-damaged coders". but yeah, this (again) reminded me why i once resigned from NG. i'd probably should do it again, IRC is enough. Seems like your pretty dumb. You don't capitalize I, which is a basic grammatical rule in the English language. I'm sure you have your dumb logic for it though. Your real problem is that you are an arrogant prick that seems to think the world revolves around your tiny little pathetic uninteresting life. You are not god, not the end all be all, not the shit, not even popular or important. Stop trying to pretend you are and actually try to get along with other people, and accept that not every is as smart as you think you are. Maybe not everyone in the world is a bad ass leet coder as you are, maybe they are a bad ass Tennis player that does coding for fun on the side to expand their understanding of life. What do you do besides code? Are you actually any good at coding BTW? I doubt as good as you think you are. People like you have a very tiny understanding of reality and it shows. Please grow up, quickly. Your life and everyone around you will benefit. It's not about how big you think your balls are, how big they actually are, or if there tennis balls... Grow up, act your age(if your not 12, which you probably are, so act like your 30 then), get with the program, and try to help make everyone's life a bit more enjoyable. If you get your panties in a ruff because someone says something that you think is "dumb", enlighten them nicely... after all, you might just be the one needing enlightenment.
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 09:46:24 UTC, ag0aep6g wrote: So when one makes a post here saying that "D is aimed at brain-dead people", we shouldn't take that for an insult. absolutely. but "D is crap" is whole different story.
Re: DIP: Tail call optimization
On 07/10/2016 11:30 AM, ketmar wrote: On Sunday, 10 July 2016 at 09:24:58 UTC, ag0aep6g wrote: [...] It's no stretch to assume that the one who proposes the feature would make use of it. You called those who would use it "brain-damaged". i am not responsible for people's assumptions. So when one makes a post here saying that "D is aimed at brain-dead people", we shouldn't take that for an insult. Because, hey, they couldn't have known that we use it, and there's clearly no reason for them to assume so.
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 09:24:58 UTC, ag0aep6g wrote: On 07/10/2016 08:39 AM, ketmar wrote: note that i didn't said this about OP, in no way. so no personal attacks here. It's no stretch to assume that the one who proposes the feature would make use of it. You called those who would use it "brain-damaged". i am not responsible for people's assumptions.
Re: DIP: Tail call optimization
On 07/10/2016 08:39 AM, ketmar wrote: note that i didn't said this about OP, in no way. so no personal attacks here. It's no stretch to assume that the one who proposes the feature would make use of it. You called those who would use it "brain-damaged".
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 09:05:46 UTC, Tofu Ninja wrote: Your joking right? No personal attacks? where do you see personal attack in my words? i'm not saying that OP is dumb, and i'm not saying that his proposal is dumb. but it is *aimed* to dumb people (which doesn't automatically makes it dumb, you know). and i got tired of being "polite", from now on when i'll see dumb people, i'll say that i see dumb people, not "different" or "mentally impaired". as for the topic, i *tried* to explain why i see no value in the proposal. and part of the explanation included referring to "brain-damaged coders". but yeah, this (again) reminded me why i once resigned from NG. i'd probably should do it again, IRC is enough.
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 06:39:06 UTC, ketmar wrote: On Sunday, 10 July 2016 at 06:37:18 UTC, ketmar wrote: On Sunday, 10 July 2016 at 06:20:59 UTC, Seb wrote: ... guys, please stay friendly, constructive and polite! I thought we are all grown-ups here! i do. someone who is not able to understand when and how TCO works is clearly brain-damaged. if he isn't, why did he become programmer in the first place? it is clear that he is not able to program. note that i didn't said this about OP, in no way. so no personal attacks here. Your joking right? No personal attacks?
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 07:43:14 UTC, ketmar wrote: we already has one optimization case speced -- NRVO. and it is BAD. adding another implementation detail to the spec will only worsen the situation, i believe. We have other cases cases where optimization is expected but it is poorly speced. However I like the fact that the spec does demand some optimizations because it ensures the quality of a conforming implementation. Yet, TCO in particular it not applicable directly in many cases, and usually needs many transformations before it can be applied. There nothing wrong with guaranteeing that it will be applied in trivial cases. (This should be done by adding a sentence to the spec, not by adding a pargma) However for more complex cases it heavily depends on the optimizer and on the backend! In general you don't want to relay in such optimizations. When in doubt avoid recursion.
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 07:30:32 UTC, Dietrich Daroch wrote: If attributes look messy, pragma can be used. It may look as an addition with little gain, but one of the reasons of compiling is to prevent runtime errors as early as possible and this seeks exactly that. then TCO should be added to language spec too. for now, compiler is not obliged to implement it. also, many implementations only implement TCO for functions with exactly same args -- is this something that should be speced, or not? we already has one optimization case speced -- NRVO. and it is BAD. adding another implementation detail to the spec will only worsen the situation, i believe.
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 06:59:21 UTC, ketmar wrote: On Sunday, 10 July 2016 at 06:44:22 UTC, Dietrich Daroch wrote: Yes, there is no cure for poor skills, but the point is to prevent the need to avoid recursion to ensure there are no stack overflows. It seems reasonable considering D targets systems programming. i see "system programmer" as someone who is able to understand when TCO is in effect without additional attribute noise. and for others it just doesn't matter -- as they probably is using a library written by "system programmer" anyway, and won't dive into code. ;-) sorry, it is really just a noise, like "@nogc". compiler does a fairly good work on TCO already, and adding another attribute will just make code messier. it is already @too @many @attributes @in @D. If attributes look messy, pragma can be used. It may look as an addition with little gain, but one of the reasons of compiling is to prevent runtime errors as early as possible and this seeks exactly that.
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 06:47:47 UTC, Jack Stouffer wrote: On Sunday, 10 July 2016 at 06:29:43 UTC, A.B wrote: Get fucked by yourself asshole ! Your penance is that you'll have to review all the crappy DIPs that will come on GH until your death, now that anyone can post his fantastic idea easily. Hahahahaha. Go back to >>>/g/ what does that (>>>/g/) mean ?
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 06:44:22 UTC, Dietrich Daroch wrote: Yes, there is no cure for poor skills, but the point is to prevent the need to avoid recursion to ensure there are no stack overflows. It seems reasonable considering D targets systems programming. i see "system programmer" as someone who is able to understand when TCO is in effect without additional attribute noise. and for others it just doesn't matter -- as they probably is using a library written by "system programmer" anyway, and won't dive into code. ;-) sorry, it is really just a noise, like "@nogc". compiler does a fairly good work on TCO already, and adding another attribute will just make code messier. it is already @too @many @attributes @in @D.
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 06:29:43 UTC, A.B wrote: Get fucked by yourself asshole ! Your penance is that you'll have to review all the crappy DIPs that will come on GH until your death, now that anyone can post his fantastic idea easily. Hahahahaha. Go back to >>>/g/
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 06:17:08 UTC, ketmar wrote: On Sunday, 10 July 2016 at 05:55:50 UTC, Dietrich Daroch wrote: Yes, it probably does TCO. The problem is what if you think it does and it cannot do it because of a misunderstanding on when it can be applied or a bug? there can't be any "misunderstanding" from compiler side. either it is a leaf return, or not -- it is as easy as that. what your DIP is aimed for is brain-damaged coders who are not able to understand how programs work (and why "scope(exit)" may prevent TCO). it won't help anyone. sorry. Yes, there is no cure for poor skills, but the point is to prevent the need to avoid recursion to ensure there are no stack overflows. It seems reasonable considering D targets systems programming.
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 06:18:41 UTC, Jack Stouffer wrote: On Sunday, 10 July 2016 at 05:55:50 UTC, Dietrich Daroch wrote: Yes, it probably does TCO. The problem is what if you think it does and it cannot do it because of a misunderstanding on when it can be applied or a bug? Then file a bug report? Not a bug on the compiler, but on the function you expect to be tail recursive.
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 06:37:18 UTC, ketmar wrote: On Sunday, 10 July 2016 at 06:20:59 UTC, Seb wrote: ... guys, please stay friendly, constructive and polite! I thought we are all grown-ups here! i do. someone who is not able to understand when and how TCO works is clearly brain-damaged. if he isn't, why did he become programmer in the first place? it is clear that he is not able to program. note that i didn't said this about OP, in no way. so no personal attacks here.
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 06:20:59 UTC, Seb wrote: ... guys, please stay friendly, constructive and polite! I thought we are all grown-ups here! i do. someone who is not able to understand when and how TCO works is clearly brain-damaged. if he isn't, why did he become programmer in the first place? it is clear that he is not able to program.
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 06:20:59 UTC, Seb wrote: On Sunday, 10 July 2016 at 06:17:17 UTC, A.B wrote: On Sunday, 10 July 2016 at 05:55:50 UTC, Dietrich Daroch wrote: On Sunday, 10 July 2016 at 05:24:49 UTC, A.B wrote: On Sunday, 10 July 2016 at 05:03:46 UTC, Dietrich Daroch wrote: [...] That's crap...I disassemble DMD output some time to time. It already does TCO. Definitively a lol day... Yes, it probably does TCO. The problem is what if you think it does and it cannot do it because of a misunderstanding on when it can be applied or a bug? When the tought is not clear the sentences are messy. - "That's crap" - "brain-damaged coders" ... guys, please stay friendly, constructive and polite! I thought we are all grown-ups here! Get fucked by yourself asshole ! Your penance is that you'll have to review all the crappy DIPs that will come on GH until your death, now that anyone can post his fantastic idea easily. Hahahahaha.
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 06:17:17 UTC, A.B wrote: On Sunday, 10 July 2016 at 05:55:50 UTC, Dietrich Daroch wrote: On Sunday, 10 July 2016 at 05:24:49 UTC, A.B wrote: On Sunday, 10 July 2016 at 05:03:46 UTC, Dietrich Daroch wrote: [...] That's crap...I disassemble DMD output some time to time. It already does TCO. Definitively a lol day... Yes, it probably does TCO. The problem is what if you think it does and it cannot do it because of a misunderstanding on when it can be applied or a bug? When the tought is not clear the sentences are messy. - "That's crap" - "brain-damaged coders" ... guys, please stay friendly, constructive and polite! I thought we are all grown-ups here!
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 05:55:50 UTC, Dietrich Daroch wrote: Yes, it probably does TCO. The problem is what if you think it does and it cannot do it because of a misunderstanding on when it can be applied or a bug? Then file a bug report?
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 05:55:50 UTC, Dietrich Daroch wrote: On Sunday, 10 July 2016 at 05:24:49 UTC, A.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 That's crap...I disassemble DMD output some time to time. It already does TCO. Definitively a lol day... Yes, it probably does TCO. The problem is what if you think it does and it cannot do it because of a misunderstanding on when it can be applied or a bug? When the tought is not clear the sentences are messy.
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 05:55:50 UTC, Dietrich Daroch wrote: Yes, it probably does TCO. The problem is what if you think it does and it cannot do it because of a misunderstanding on when it can be applied or a bug? there can't be any "misunderstanding" from compiler side. either it is a leaf return, or not -- it is as easy as that. what your DIP is aimed for is brain-damaged coders who are not able to understand how programs work (and why "scope(exit)" may prevent TCO). it won't help anyone. sorry.
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 05:24:49 UTC, A.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 That's crap...I disassemble DMD output some time to time. It already does TCO. Definitively a lol day... Yes, it probably does TCO. The problem is what if you think it does and it cannot do it because of a misunderstanding on when it can be applied or a bug?
