www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP83

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Here are a few comments about http://wiki.dlang.org/DIP83:

* Meta: We continue to be shorthanded at both reviewing and implementing 
DIPs. DIP83 has a few issues that are simple and obvious, and would be 
easily fixed upon review by the community. After approval, it will be 
difficult to find someone to carry the implementation.

* Overall: The proposal is a good start but needs serious work toward 
making it a precise specification. Right now it is not ready to act as a 
blueprint of an implementation, or be converted to a section of the 
language reference.

By paragraph:

* Minor phrasing: "when flagged for in call to compiler" - the meaning 
is understandable only after having read the entire document. 
Suggestion: "Allow for assert to do pretty printing of its failing 
expression when a specific command line flag is passed to the compiler."

* Why is this feature subject to a compiler flag? The document should 
explain why, or just enable the feature regardless.

* Minor phrasing: "This extra, so called, pretty printing" -> "This 
extra so-called pretty printing" or better yet "This additional pretty 
printing".

* "give no hint" -> "gives no hint". I won't submit further proofreading 
comments.

* The rationale mentions unary operators. However, those are unlikely to 
be of use: -, +, ~, *. Additionally, ++ and -- are straight 
unrecommended inside an assert. Only assert(!e) may be arguably 
interesting, although I can't think of good examples. I suggest we drop 
unary operators altogether.

* The proposal should enumerate what top-level BINOPs are considered. 
For example, are the assignment operators part of the set? Probably not. 
My understanding is the proposal has been written mainly with these in 
mind: ==, !=, <, <=, >, >=. && is also interesting. || is only 
interesting if more decomposition is done on its operands. "in" would be 
great. Off the top of my head, I'm not sure about these: +, -, *, /, %, 
^^, &, |, ^, <<, >>, >>>, ~. The point here is it needs to be clearly 
stated which operators are allowed.

* I fail to see how "Non-Operator Lowering" could be useful. assert(e) 
fails if e is zero or null. The only possible case would be the odd 
overloading of opCast!bool, in which case the document should explain 
and motivate that with examples.

* The section "Non-Equality Operator Lowering" should be demoted because 
it's just an implementation note. At the level of this DIP, != is 
treated as an operator of its own.

* The onAssertFailed example imports std.traits but we're here in 
druntime. This illustrates a broader discussion - without std.conv and 
generally Phobos, onAssertFailed will only have little capability to 
format nice strings. I don't have a good idea on how to address this.


Andrei
Jan 14
parent reply deadalnix <deadalnix gmail.com> writes:
Ok I'll bite: it doesn't matter.

This DIP is additive. The problem with D is not that we don't 
have stuff in there, is most of the stuff in there are half 
backed. Adding more half baked things in there only makes things 
worse.

We don't have line number in stack traces, what does a better 
assert error message (that one can configure by code) will do  ? 
Worse, how is that consistent with the position that "Segfault 
are good enough with a debugger" and null by default reference 
types ?

There is no point in discussing the doorbell when the house has 
no window.
Jan 14
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2016-01-14 15:28, deadalnix wrote:

 There is no point in discussing the doorbell when the house has no window.
+1. And AST macros would solve the problem (and a lot of other problems). -- /Jacob Carlborg
Jan 14
parent reply Atila Neves <atila.neves gmail.com> writes:
On Thursday, 14 January 2016 at 19:51:37 UTC, Jacob Carlborg 
wrote:
 On 2016-01-14 15:28, deadalnix wrote:

 There is no point in discussing the doorbell when the house 
 has no window.
+1. And AST macros would solve the problem (and a lot of other problems).
I used to think we didn't need AST macros until I hit the problems this DIP tries to address. After 2 years or so, I think you've finally convinced me Jacob ;) Atila
Jan 15
parent Jacob Carlborg <doob me.com> writes:
On 2016-01-15 11:21, Atila Neves wrote:

 I used to think we didn't need AST macros until I hit the problems this
 DIP tries to address. After 2 years or so, I think you've finally
 convinced me Jacob ;)
:D -- /Jacob Carlborg
Jan 15
prev sibling next sibling parent reply Tofu Ninja <emmons0 purdue.edu> writes:
On Thursday, 14 January 2016 at 14:28:05 UTC, deadalnix wrote:
 We don't have line number in stack traces
Huh? We dont have line numbers in stack traces? I have line numbers, I am using latest dmd, or are you talking about one of the other compilers?
Jan 15
parent reply deadalnix <deadalnix gmail.com> writes:
On Friday, 15 January 2016 at 11:11:41 UTC, Tofu Ninja wrote:
 On Thursday, 14 January 2016 at 14:28:05 UTC, deadalnix wrote:
 We don't have line number in stack traces
Huh? We dont have line numbers in stack traces? I have line numbers, I am using latest dmd, or are you talking about one of the other compilers?
Well I don't, both on OSX and linux, using the latest release. On linux I can do the addr2line dance, but on OSX I can't even do that as it require information that are gone once the program terminate.
Jan 15
next sibling parent Tofu Ninja <emmons0 purdue.edu> writes:
On Friday, 15 January 2016 at 13:20:18 UTC, deadalnix wrote:
 Well I don't, both on OSX and linux, using the latest release. 
 On linux I can do the addr2line dance, but on OSX I can't even 
 do that as it require information that are gone once the 
 program terminate.
Hmmm, I'm on windows so maybe that's it, pretty odd tho.
Jan 15
prev sibling next sibling parent reply Yazan D <invalid email.com> writes:
On Fri, 15 Jan 2016 13:20:18 +0000, deadalnix wrote:

 
 Well I don't, both on OSX and linux, using the latest release. On linux
 I can do the addr2line dance, but on OSX I can't even do that as it
 require information that are gone once the program terminate.
Are you compiling with debug symbols on (-g)? You should get stacktraces on linux.
Jan 15
parent deadalnix <deadalnix gmail.com> writes:
On Friday, 15 January 2016 at 15:06:00 UTC, Yazan D wrote:
 On Fri, 15 Jan 2016 13:20:18 +0000, deadalnix wrote:

 
 Well I don't, both on OSX and linux, using the latest release. 
 On linux I can do the addr2line dance, but on OSX I can't even 
 do that as it require information that are gone once the 
 program terminate.
Are you compiling with debug symbols on (-g)? You should get stacktraces on linux.
Yes, with function mangled names and symbol instruction's address. And only if I link with -export-dynamic , which is disabled by default on ld (and, really, shouldn't be necessary).
Jan 16
prev sibling parent rsw0x <anonymous anonymous.com> writes:
On Friday, 15 January 2016 at 13:20:18 UTC, deadalnix wrote:
 On Friday, 15 January 2016 at 11:11:41 UTC, Tofu Ninja wrote:
 On Thursday, 14 January 2016 at 14:28:05 UTC, deadalnix wrote:
 We don't have line number in stack traces
Huh? We dont have line numbers in stack traces? I have line numbers, I am using latest dmd, or are you talking about one of the other compilers?
Well I don't, both on OSX and linux, using the latest release. On linux I can do the addr2line dance, but on OSX I can't even do that as it require information that are gone once the program terminate.
dmd generates stack traces on linux now I think it was either ldc or gdc that did before.
Jan 15
prev sibling parent reply =?UTF-8?B?TcOhcmNpbw==?= Martins <marcioapm gmail.com> writes:
On Thursday, 14 January 2016 at 14:28:05 UTC, deadalnix wrote:
 Ok I'll bite: it doesn't matter.

 This DIP is additive. The problem with D is not that we don't 
 have stuff in there, is most of the stuff in there are half 
 backed. Adding more half baked things in there only makes 
 things worse.

 We don't have line number in stack traces, what does a better 
 assert error message (that one can configure by code) will do  
 ? Worse, how is that consistent with the position that 
 "Segfault are good enough with a debugger" and null by default 
 reference types ?

 There is no point in discussing the doorbell when the house has 
 no window.
True that. I think it's great to keep evolving the language and making it better, on the other hand, if D is to get serious adoption, then everything, especially the basics like debuggability, quality of codegen and compiler bugs will need to be solid. D as a language is already powerful enough to thrash the competition, this is why we love it. But the reason it's experiencing slow adoption, is because of tooling and general implementation quality, and the lower threshold of tolerance from the general population.
Jan 15
parent reply rsw0x <anonymous anonymous.com> writes:
On Friday, 15 January 2016 at 11:58:19 UTC, Márcio Martins wrote:
 On Thursday, 14 January 2016 at 14:28:05 UTC, deadalnix wrote:
 [...]
True that. I think it's great to keep evolving the language and making it better, on the other hand, if D is to get serious adoption, then everything, especially the basics like debuggability, quality of codegen and compiler bugs will need to be solid. D as a language is already powerful enough to thrash the competition, this is why we love it. But the reason it's experiencing slow adoption, is because of tooling and general implementation quality, and the lower threshold of tolerance from the general population.
I think what he was pointing out is that many D features are currently barely functioning or not working and adding more features is just a waste of time.
Jan 15
parent deadalnix <deadalnix gmail.com> writes:
On Saturday, 16 January 2016 at 03:00:33 UTC, rsw0x wrote:
 On Friday, 15 January 2016 at 11:58:19 UTC, Márcio Martins 
 wrote:
 On Thursday, 14 January 2016 at 14:28:05 UTC, deadalnix wrote:
 [...]
True that. I think it's great to keep evolving the language and making it better, on the other hand, if D is to get serious adoption, then everything, especially the basics like debuggability, quality of codegen and compiler bugs will need to be solid. D as a language is already powerful enough to thrash the competition, this is why we love it. But the reason it's experiencing slow adoption, is because of tooling and general implementation quality, and the lower threshold of tolerance from the general population.
I think what he was pointing out is that many D features are currently barely functioning or not working and adding more features is just a waste of time.
Yes, that was the larger point.
Jan 16