www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Reddit: 
http://www.reddit.com/r/programming/comments/1g6x9g/dconf_2013_code_analysis_for_d_with_analyzed/

Hackernews: https://news.ycombinator.com/item?id=5867764

Twitter: https://twitter.com/D_Programming/status/344798127775182849

Facebook: https://www.facebook.com/dlang.org/posts/655927124420972

Youtube: http://youtube.com/watch?v=ph_uU7_QGY0

Please drive discussions on the social channels, they help D a lot.


Andrei
Jun 12 2013
next sibling parent reply David <d dav1d.de> writes:
Am 12.06.2013 14:50, schrieb Andrei Alexandrescu:
 Reddit:
 http://www.reddit.com/r/programming/comments/1g6x9g/dconf_2013_code_analysis_for_d_with_analyzed/
 
 
 Hackernews: https://news.ycombinator.com/item?id=5867764
 
 Twitter: https://twitter.com/D_Programming/status/344798127775182849
 
 Facebook: https://www.facebook.com/dlang.org/posts/655927124420972
 
 Youtube: http://youtube.com/watch?v=ph_uU7_QGY0
 
 Please drive discussions on the social channels, they help D a lot.
 
 
 Andrei
The reddit link seems to be deleted?
Jun 12 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/12/13 9:00 AM, David wrote:
 Am 12.06.2013 14:50, schrieb Andrei Alexandrescu:
 Reddit:
 http://www.reddit.com/r/programming/comments/1g6x9g/dconf_2013_code_analysis_for_d_with_analyzed/


 Hackernews: https://news.ycombinator.com/item?id=5867764

 Twitter: https://twitter.com/D_Programming/status/344798127775182849

 Facebook: https://www.facebook.com/dlang.org/posts/655927124420972

 Youtube: http://youtube.com/watch?v=ph_uU7_QGY0

 Please drive discussions on the social channels, they help D a lot.


 Andrei
The reddit link seems to be deleted?
Sorry, wrong URL. It's here: http://www.reddit.com/r/programming/comments/1g6xbi/dconf_2013_code_analysis_for_d_with_analyzed_by/ Please vote, it only has 3 points! Andrei
Jun 12 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 Youtube: http://youtube.com/watch?v=ph_uU7_QGY0
It's an interesting talk. Maybe all talks of this conference were interesting. Some notes on the slides. - - - - - - - - - - - - Slide 12:
A class is an item with a strict boundary. e.g.: Arrays will be 
dupped at these borders.<
I think this kind of privacy for reference data is a common need. I think enforcing this is not a job of static analysis tools, it looks like a job for the type system. An annotation should suffice (in theory this annotation should allow the access of the array from outside, so it should be forbidden by default for private fields. Now this can't be done, so an annotation needs to do the opposite). Maybe this needs some discussion in the main D newsgroup. - - - - - - - - - - - - Slide 12:
We do not use Ddoc, because most important information about 
functions are not included.
- In- / Out-Constrains - Exceptional Cases aka Throws< How to annotate throws in ddoct? Do they need to be generated automatically? Regarding pre/post conditions, maybe a ddoc macro or switch can be used to make them appear in the ddoc output on request. - - - - - - - - - - - - Slide 12:
Next to classes also model package dependency
- no cyclic dependencies anymore< Maybe it's possisible to add some way (like a standard annotation) to enforce the absence of cyclic dependencies in a section of a project (like inside a package). - - - - - - - - - - - - Slide 14:
- Private static functions which could be tested inplace are 
tested using D-unittest-Blocks (Unit =:= Function)
- Other tests require setups, teardowns, names (Testdox http://agiledox.sourceforge.net/). Need to be filtered, selected. For them using Dunit. (Unit =:= Class / Struct)< I think the built-in unit test system should be improved, so in _most_ cases there's no need to use a second unittest system. Bye, bearophile
Jun 12 2013
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 12 June 2013 at 17:31:27 UTC, bearophile wrote:
We do not use Ddoc, because most important information about 
functions are not included.
- In- / Out-Constrains
These are pretty easy to add to dmd. In doc.c's FuncDelaration::toDocBuffer you can throw in something like this: if(frequire) buf->writestring(frequire->toChars()); if(fensure) buf->writestring(fensure->toChars()); with a little cleanup and a wrapper macro and I think that would be good.
 - Exceptional Cases aka Throws<
No easy way to do this automatically though because the compiler doesn't even know what a function can throw. You'd just have to do it manually.
Jun 12 2013
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/12/13, Adam D. Ruppe <destructionator gmail.com> wrote:
 No easy way to do this automatically though because the compiler
 doesn't even know what a function can throw. You'd just have to
 do it manually.
Are you sure? A compiler can tell whether a function /can/ throw (hence why nothrow works), so I assume it has information on where an exception is thrown. I think it'd be nice if we added this ability to ddoc, having to manually do it often means the documentation being out of date.
Jun 12 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 12 June 2013 at 20:23:43 UTC, Andrej Mitrovic wrote:
 Are you sure? A compiler can tell whether a function /can/ throw
 (hence why nothrow works), so I assume it has information on 
 where an exception is thrown.
Consider this: extern(D) void foo(); void bar() { foo(); } That's legal D code, and foo could throw anything, and bar would have no idea what it is. Looking at dmd's source, looks like Walter actually wrote code to parse a throws Exception, etc. to be part of the function signature but stripped it out (surely because that's annoying). Without a list like that, the compiler just can't be sure what happens. It could maybe try to figure it out based on the source it has available, and at least get an incomplete list, but currently it doesn't attempt to do that. That might not be too hard to do actually, when outputting the ddoc, dive into the function body for throw statements and build up a list. If the call tree goes down to anything it doesn't recognize and is not marked nothrow, then it could say "I'm not sure if this is everything but this is what I found".
Jun 12 2013
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, June 12, 2013 22:29:15 Adam D. Ruppe wrote:
 On Wednesday, 12 June 2013 at 20:23:43 UTC, Andrej Mitrovic wrote:
 Are you sure? A compiler can tell whether a function /can/ throw
 (hence why nothrow works), so I assume it has information on
 where an exception is thrown.
Consider this: extern(D) void foo(); void bar() { foo(); } That's legal D code, and foo could throw anything, and bar would have no idea what it is.
nothrow is like safe or pure. The compiler knows whether that attribute on the function is valid by looking at the signatures of the functions called within that function (as well as what the built-in operations used are). The bodies of the functions being called never comes into play. At least some of the time, it would be theoretically possible for the compiler to go look in the bodies of the functions being called, but all of that stuff is based off of the function signatures, not their bodies. A function's body is only looked at when it's being compiled, not when other functions refer to it. And with the C linking model, it really doesn't make sense for the compiler to look at the bodies of other functions when compiling a function. Tools could certainly look at source code and figure out stuff like what exceptions could be thrown from a particular function, but that requires having all of the source and examining it, and that's not how compilers normally work. - Jonathan M Davis
Jun 12 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/12/2013 1:29 PM, Adam D. Ruppe wrote:
 Looking at dmd's source, looks like Walter actually wrote code to parse a
throws
 Exception, etc. to be part of the function signature but stripped it out
(surely
 because that's annoying).
That detritus should be removed. It was a bad idea, which is why I disabled it.
Jun 12 2013
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, June 12, 2013 13:46:20 Walter Bright wrote:
 On 6/12/2013 1:29 PM, Adam D. Ruppe wrote:
 Looking at dmd's source, looks like Walter actually wrote code to parse a
 throws Exception, etc. to be part of the function signature but stripped
 it out (surely because that's annoying).
That detritus should be removed. It was a bad idea, which is why I disabled it.
Well, I assume that it was the beginnings of a checked exceptions implementations, and checked exceptions do have their advantages, but the general verdict of the programming world as a whole does seem to be that they were ultimately a bad idea. Sometimes, it _does_ suck to not know exactly which exceptions a function can throw, but on the whole, I think that we hit a good balance with nothrow. What I find most interesting about checked exceptions is the fact that almost everyone thinks that they're a fantastic idea when they first encounter them and yet they're actually a bad idea. It's actually a good example of how a feature sometimes needs to be thoroughly field-tested before it becomes clear how good or bad it is. - Jonathan M Davis
Jun 12 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 What I find most interesting about checked exceptions is the 
 fact that almost
 everyone thinks that they're a fantastic idea when they first 
 encounter them
 and yet they're actually a bad idea. It's actually a good 
 example of how a
 feature sometimes needs to be thoroughly field-tested before it 
 becomes clear how good or bad it is.
Maybe checked exceptions are bad only for the type system of Java. Maybe for a language that has global type inferencing on the exceptions such feature becomes better. Bye, bearophile
Jun 12 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/12/2013 2:21 PM, bearophile wrote:
 Jonathan M Davis:

 What I find most interesting about checked exceptions is the fact that almost
 everyone thinks that they're a fantastic idea when they first encounter them
 and yet they're actually a bad idea. It's actually a good example of how a
 feature sometimes needs to be thoroughly field-tested before it becomes clear
 how good or bad it is.
Maybe checked exceptions are bad only for the type system of Java. Maybe for a language that has global type inferencing on the exceptions such feature becomes better.
C++98 had checked exceptions (exception specifications), too. Another failure of the idea, it failed so badly hardly anyone but language lawyers ever knew it had it.
Jun 12 2013
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 Maybe checked exceptions are bad only for the type system of 
 Java. Maybe for a
 language that has global type inferencing on the exceptions 
 such feature becomes
 better.
C++98 had checked exceptions (exception specifications), too.
C++98 doesn't have a global type inferencer for exceptions. Bye, bearophile
Jun 12 2013
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/12/2013 11:23 PM, Walter Bright wrote:
 On 6/12/2013 2:21 PM, bearophile wrote:
 Jonathan M Davis:

 What I find most interesting about checked exceptions is the fact
 that almost
 everyone thinks that they're a fantastic idea when they first
 encounter them
 and yet they're actually a bad idea. It's actually a good example of
 how a
 feature sometimes needs to be thoroughly field-tested before it
 becomes clear
 how good or bad it is.
Maybe checked exceptions are bad only for the type system of Java. Maybe for a language that has global type inferencing on the exceptions such feature becomes better.
C++98 had checked exceptions (exception specifications), too. Another failure of the idea, it failed so badly hardly anyone but language lawyers ever knew it had it.
Weren't those checked at runtime?
Jun 12 2013
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, June 12, 2013 23:33:31 Timon Gehr wrote:
 C++98 had checked exceptions (exception specifications), too. Another
 failure of the idea, it failed so badly hardly anyone but language
 lawyers ever knew it had it.
Weren't those checked at runtime?
Yes. If another exception type was thrown, it called something like unexpected_exception (I don't remember the exact function) which called abort by default and killed your program. So, while Java's checked are ultimately a bad idea, they at least have _some_ redeeming value, whereas C++ throw specifiers really don't. - Jonathan M Davis
Jun 12 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/12/2013 2:21 PM, bearophile wrote:
 Jonathan M Davis:

 What I find most interesting about checked exceptions is the fact that almost
 everyone thinks that they're a fantastic idea when they first encounter them
 and yet they're actually a bad idea. It's actually a good example of how a
 feature sometimes needs to be thoroughly field-tested before it becomes clear
 how good or bad it is.
Maybe checked exceptions are bad only for the type system of Java. Maybe for a language that has global type inferencing on the exceptions such feature becomes better.
It's not just Java specific. Bruce Eckel wrote a wonderful piece on why exception specifications *cause* bad code to be written. http://www.mindview.net/Etc/Discussions/CheckedExceptions
Jun 12 2013
parent Ary Borenszweig <ary esperanto.org.ar> writes:
On 6/12/13 6:26 PM, Walter Bright wrote:
 On 6/12/2013 2:21 PM, bearophile wrote:
 Jonathan M Davis:

 What I find most interesting about checked exceptions is the fact
 that almost
 everyone thinks that they're a fantastic idea when they first
 encounter them
 and yet they're actually a bad idea. It's actually a good example of
 how a
 feature sometimes needs to be thoroughly field-tested before it
 becomes clear
 how good or bad it is.
Maybe checked exceptions are bad only for the type system of Java. Maybe for a language that has global type inferencing on the exceptions such feature becomes better.
It's not just Java specific. Bruce Eckel wrote a wonderful piece on why exception specifications *cause* bad code to be written. http://www.mindview.net/Etc/Discussions/CheckedExceptions
Do you think the same will happen if the compiler tracks possible null references and whenever you might have a null pointer exception you are forced to handle it? (provided that the compiler is smart enough to know when a variable can't be null for sure, for transforming the code to SSA)
Jun 12 2013
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 6/12/13 6:21 PM, bearophile wrote:
 Jonathan M Davis:

 What I find most interesting about checked exceptions is the fact that
 almost
 everyone thinks that they're a fantastic idea when they first
 encounter them
 and yet they're actually a bad idea. It's actually a good example of
 how a
 feature sometimes needs to be thoroughly field-tested before it
 becomes clear how good or bad it is.
Maybe checked exceptions are bad only for the type system of Java. Maybe for a language that has global type inferencing on the exceptions such feature becomes better.
Why?
Jun 12 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Ary Borenszweig:

 Maybe checked exceptions are bad only for the type system of 
 Java. Maybe
 for a language that has global type inferencing on the 
 exceptions such
 feature becomes better.
Why?
I am not an expert of type systems, so this is this just an hypothesis. What are the disadvantages of checked exceptions? One problem is that those annotations are heavy, make the code rigid to change, and this doesn't go well with normal programmer laziness. A global type inferencer (that doesn't work well with the dynamic nature of Java) avoids the need for all exception annotations, but forces you to catch exceptions somewhere, assuring no holes remain if you don't want holes. Bye, bearophile
Jun 12 2013
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 6/12/13 6:49 PM, bearophile wrote:
 Ary Borenszweig:

 Maybe checked exceptions are bad only for the type system of Java. Maybe
 for a language that has global type inferencing on the exceptions such
 feature becomes better.
Why?
I am not an expert of type systems, so this is this just an hypothesis. What are the disadvantages of checked exceptions? One problem is that those annotations are heavy, make the code rigid to change, and this doesn't go well with normal programmer laziness. A global type inferencer (that doesn't work well with the dynamic nature of Java) avoids the need for all exception annotations, but forces you to catch exceptions somewhere, assuring no holes remain if you don't want holes. Bye, bearophile
But if a type checker deduces a function foo throws exception A, and in function bar you call foo: are you forced to handle the exception? If not, do you have to tell the compiler that you don't want to handle that exception? Isn't that the same as what Java does?
Jun 12 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
Ary Borenszweig:

 But if a type checker deduces a function foo throws exception 
 A, and in function bar you call foo: are you forced to handle 
 the exception? If not, do you have to tell the compiler that 
 you don't want to handle that exception? Isn't that the same as 
 what Java does?
Let's keep playing :-) - I think if you don't want to handle the exception, you don't handle the exception, and the type system assumes you will handle the exception at a higher level. - In every point of the program you can also ask to the type system (like through the IDE) what are the current exceptions that can happen there. - If you don't handle exceptions in the main, your program will throw them. If you annotate a function with nothrow then the type system forces you to handle all the possible exceptions of that function inside the function. Bye, bearophile
Jun 12 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/12/2013 2:49 PM, bearophile wrote:
 What are the disadvantages of checked exceptions?
See the link to Bruce Eckel's article I posted in this thread.
Jun 12 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 See the link to Bruce Eckel's article I posted in this thread.
Mine was a rhetorical question :-) Bye, bearophile
Jun 12 2013
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/12/13, Adam D. Ruppe <destructionator gmail.com> wrote:
 On Wednesday, 12 June 2013 at 20:23:43 UTC, Andrej Mitrovic wrote:
 Are you sure? A compiler can tell whether a function /can/ throw
 (hence why nothrow works), so I assume it has information on
 where an exception is thrown.
Consider this: extern(D) void foo(); void bar() { foo(); } That's legal D code, and foo could throw anything, and bar would have no idea what it is.
I thought doing this only for function definitions could make sense. For declarations the user would have to do it manually.
Jun 12 2013
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 12 June 2013 at 21:34:31 UTC, Andrej Mitrovic wrote:
 I thought doing this only for function definitions could make 
 sense.
 For declarations the user would have to do it manually.
Yeah, it'd still be somewhat imprecise though because bar() would also 'throw' whatever foo() can throw too. (And if foo() is private there may be no documentation to check, either.) But it could still probably do a pretty good job, might be worth looking into.
Jun 12 2013
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:

 These are pretty easy to add to dmd. In doc.c's 
 FuncDelaration::toDocBuffer you can throw in something like 
 this:
             if(frequire)
                 buf->writestring(frequire->toChars());
             if(fensure)
                 buf->writestring(fensure->toChars());

 with a little cleanup and a wrapper macro and I think that 
 would be good.
Maybe with a compiler switch syntax like: -D:+-switch1,...,+-switchn Using a command like? -D:+contracts Bye, bearophile
Jun 13 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-12 19:31, bearophile wrote:

 How to annotate throws in ddoct? Do they need to be generated
 automatically?
That would be nice. Possibly a macro the compiler knows about so you can place it anywhere you want. Or a way to opt it out.
 Regarding pre/post conditions, maybe a ddoc macro or switch can be used
 to make them appear in the ddoc output on request.
Wouldn't mind having that.
 I think the built-in unit test system should be improved, so in _most_
 cases there's no need to use a second unittest system.
I agree. But there's a conflict of interest here. Some people like output when the tests are running (I do), some don't. Walter likes the simplicity of the unit test system. -- /Jacob Carlborg
Jun 13 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jacob Carlborg:

 Walter likes the simplicity of the unit test system.
Maybe Walter is slowly realizing that the built-in uinittest system doesn't cut it. I am saying this since years. On the other hand, unittest systems come and go, while D language must be designed to last 10 or 20 years. So hard coding too much of a unittest design inside the language risks introducing something that few years from now will become obsolete (hopefully something like QuickCheck will become more commonly used in D). So I suggested to offer the tools, but not a complete built-in solution. Bye, bearophile
Jun 14 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-14 10:58, bearophile wrote:

 So I suggested to offer the tools, but not a complete built-in solution.
I agree. You can get quite far with what we have now and library support. Perhaps we could have a couple of different implementations in druntime that we can choose from. -- /Jacob Carlborg
Jun 14 2013
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 14 Jun 2013 05:12:09 -0400, Jacob Carlborg <doob me.com> wrote:

 On 2013-06-14 10:58, bearophile wrote:

 So I suggested to offer the tools, but not a complete built-in solution.
I agree. You can get quite far with what we have now and library support. Perhaps we could have a couple of different implementations in druntime that we can choose from.
With UDAs, we have a lot of unrealized power for unit tests. I have asked for ModuleInfo to contain an rtInfo member [1], like TypeInfo does. With that, and possibly splitting the unit tests into individual functions (if not done already, I don't know), you have all you need to completely re-design the unit testing framework. It can even be runtime selectable. -Steve [1] http://d.puremagic.com/issues/show_bug.cgi?id=10023
Jun 14 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-14 17:13, Steven Schveighoffer wrote:

 With  UDAs, we have a lot of unrealized power for unit tests.

 I have asked for ModuleInfo to contain an rtInfo member [1], like
 TypeInfo does.  With that, and possibly splitting the unit tests into
 individual functions (if not done already, I don't know), you have all
 you need to completely re-design the unit testing framework.  It can
 even be runtime selectable.
It would also be nice to not have to change the druntime to use RTInfo. Is that part of what you're suggesting? -- /Jacob Carlborg
Jun 15 2013
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sat, 15 Jun 2013 11:16:22 -0400, Jacob Carlborg <doob me.com> wrote:

 On 2013-06-14 17:13, Steven Schveighoffer wrote:

 With  UDAs, we have a lot of unrealized power for unit tests.

 I have asked for ModuleInfo to contain an rtInfo member [1], like
 TypeInfo does.  With that, and possibly splitting the unit tests into
 individual functions (if not done already, I don't know), you have all
 you need to completely re-design the unit testing framework.  It can
 even be runtime selectable.
It would also be nice to not have to change the druntime to use RTInfo. Is that part of what you're suggesting?
No, currently RTInfo is for types only. I want to have it work for modules as well (where unit tests typically live). It would be nice to make it easily extensible. I think that can be done by keying on certain members in the type/module. -Steve
Jun 17 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-06-17 16:21, Steven Schveighoffer wrote:

 No, currently RTInfo is for types only.  I want to have it work for
 modules as well (where unit tests typically live).
I think I understand what you mean now. -- /Jacob Carlborg
Jun 17 2013
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/12/13 8:50 AM, Andrei Alexandrescu wrote:
 Reddit:
 http://www.reddit.com/r/programming/comments/1g6x9g/dconf_2013_code_analysis_for_d_with_analyzed/


 Hackernews: https://news.ycombinator.com/item?id=5867764

 Twitter: https://twitter.com/D_Programming/status/344798127775182849

 Facebook: https://www.facebook.com/dlang.org/posts/655927124420972

 Youtube: http://youtube.com/watch?v=ph_uU7_QGY0

 Please drive discussions on the social channels, they help D a lot.


 Andrei
In HD: https://archive.org/details/dconf2013-day03-talk02 Andrei
Jun 12 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 12 Jun 2013 08:50:41 -0400
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 Reddit: 
 http://www.reddit.com/r/programming/comments/1g6x9g/dconf_2013_code_analysis_for_d_with_analyzed/
 
 Hackernews: https://news.ycombinator.com/item?id=5867764
 
 Twitter: https://twitter.com/D_Programming/status/344798127775182849
 
 Facebook: https://www.facebook.com/dlang.org/posts/655927124420972
 
 Youtube: http://youtube.com/watch?v=ph_uU7_QGY0
 
 Please drive discussions on the social channels, they help D a lot.
 
 
 Andrei
Torrents and links: http://semitwist.com/download/misc/dconf2013/
Jun 12 2013
prev sibling next sibling parent "Anthony Goins" <neontotem gmail.com> writes:
On Wednesday, 12 June 2013 at 12:50:39 UTC, Andrei Alexandrescu 
wrote:
 Reddit: 
 http://www.reddit.com/r/programming/comments/1g6x9g/dconf_2013_code_analysis_for_d_with_analyzed/

 Hackernews: https://news.ycombinator.com/item?id=5867764

 Twitter: 
 https://twitter.com/D_Programming/status/344798127775182849

 Facebook: 
 https://www.facebook.com/dlang.org/posts/655927124420972

 Youtube: http://youtube.com/watch?v=ph_uU7_QGY0

 Please drive discussions on the social channels, they help D a 
 lot.


 Andrei
He mentions a D plug-in for sonar. Is this available publicly?
Jun 12 2013
prev sibling next sibling parent reply "Don" <turnyourkidsintocash nospam.com> writes:
On Wednesday, 12 June 2013 at 12:50:39 UTC, Andrei Alexandrescu 
wrote:
 Reddit: 
 http://www.reddit.com/r/programming/comments/1g6x9g/dconf_2013_code_analysis_for_d_with_analyzed/

 Hackernews: https://news.ycombinator.com/item?id=5867764

 Twitter: 
 https://twitter.com/D_Programming/status/344798127775182849

 Facebook: 
 https://www.facebook.com/dlang.org/posts/655927124420972

 Youtube: http://youtube.com/watch?v=ph_uU7_QGY0

 Please drive discussions on the social channels, they help D a 
 lot.


 Andrei
The restrictions on contracts were very interesting. Obviously the static analysis could be more sophisticated than what you currently have, but I don't think contracts can be much use to a static analyzer if they can contain arbitrary code. I would be interested to see how much freedom is actually required, in order to make contracts adequately expressive. Perhaps it was a language mistake to allow arbitrary code inside contracts, it might have been better to start with something very restricted and gradually relax the rules.
Jun 14 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Don:

 I don't think contracts can be much use to a static analyzer if 
 they can contain arbitrary code.
The other contract systems I know of (Eiffel, Ada, C#, Sing#), plus few other systems that use the type system for similar reasons (Liquid Haskell, etc), use a very restricted expression language to state contracts. D is the only that uses free form D code. I presented this problem to Walter lot of time ago in a post. He answered me that analysing a loop is not harder than analysing the all/any/exists used in those systems. I was never convinced by that. I still think there's one D design problem here. Bye, bearophile
Jun 14 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/14/2013 11:03 AM, bearophile wrote:
 Don:

 I don't think contracts can be much use to a static analyzer if they
 can contain arbitrary code.
The other contract systems I know of (Eiffel, Ada, C#, Sing#), plus few other systems that use the type system for similar reasons (Liquid Haskell, etc), use a very restricted expression language to state contracts. D is the only that uses free form D code.
Eiffel can call arbitrary methods in contracts.
 I presented this problem to Walter lot of time ago in a post. He
 answered me that analysing a loop is not harder than analysing the
 all/any/exists used in those systems. I was never convinced by that.

 I still think there's one D design problem here.
...
I disagree. The only problem is the verboseness of the contract system.
Jun 15 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Timon Gehr:

 Eiffel can call arbitrary methods in contracts.
This is surprising. Maybe the "Modern Eiffel" is more strict.
 I disagree. The only problem is the verboseness of the contract 
 system.
If your contracts contain arbitrary D code, I don't think a static analyser will be able to use them. So it will give you a compilation error, or it will give a warning and then keep the contract as run-time test. In both cases this makes the static analysis much less useful. So you end using a subsed of the D syntax and D semantics. But then compilation becomes a try-and-guess, and different static analysers will digest different amounts of D syntax and semantics, causing those contracts to be not portable across static analysers. Both Ada and Liquid Haskell avoids all this. Bye, bearophile
Jun 15 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/16/2013 12:07 AM, bearophile wrote:
 Timon Gehr:

 Eiffel can call arbitrary methods in contracts.
This is surprising. Maybe the "Modern Eiffel" is more strict.
It's design isn't finished, but IIRC it enforces purity, contracts can be arbitrarily complex, and manual proofs are required.
 I disagree. The only problem is the verboseness of the contract system.
If your contracts contain arbitrary D code, I don't think a static analyser will be able to use them.
Why not? The static analyser obviously needs to analyse arbitrary D code anyway, unless it only analyses contracts, which is not useful.
 So it will give you a compilation
 error, or it will give a warning and then keep the contract as run-time
 test.
It's unreasonable to expect that the static analyser will automatically prove all correct programs correct without manually provided evidence. This holds true independently of the format the contracts are specified in.
 In both cases this makes the static analysis much less useful.
Than what?
 So you end using a subsed of the D syntax and D semantics. But then
 compilation becomes a try-and-guess, and different static analysers will
 digest different amounts of D syntax and semantics,
Obviously. But not closely related to the way contracts are specified.
 causing those contracts to be not portable across static analysers.
If those analysers all follow the same specification, they will be portable in any case.
 Both Ada
Reference?
 and Liquid Haskell avoids all this.
 ...
It does not make any sense to claim that Liquid Haskell avoids all this. It is not a programming language but a static verifier, AFAIK based on predicate abstraction.
Jun 15 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
I don't understand this topic well enough, so I am not saying 
useful things. Thank you for your comments Timon...

Bye,
bearophile
Jun 15 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
Slowly catching up with published videos :)

This has kind of convinced me that once D gets wider usage, tools 
similar to AnalyzeD may become de-facto standard part of any 
production toolchain, with a configurable rule set. D is complex 
and multi-paradigm language (which rocks) and any single project 
is likely to use only specific style subset (which is kind of 
hard to enforce). Once front-end parses becomes less coupled with 
rest of the compiler it should become more and more popular 
approach.
Jun 15 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-12 14:50, Andrei Alexandrescu wrote:
 Reddit:
 http://www.reddit.com/r/programming/comments/1g6x9g/dconf_2013_code_analysis_for_d_with_analyzed/


 Hackernews: https://news.ycombinator.com/item?id=5867764

 Twitter: https://twitter.com/D_Programming/status/344798127775182849

 Facebook: https://www.facebook.com/dlang.org/posts/655927124420972

 Youtube: http://youtube.com/watch?v=ph_uU7_QGY0
As I understand it, the static analyzer doesn't handle D completely. How does it behave/what happens if it encounters something it cannot handle? -- /Jacob Carlborg
Jun 15 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/15/2013 05:14 PM, Jacob Carlborg wrote:
 On 2013-06-12 14:50, Andrei Alexandrescu wrote:
 Reddit:
 http://www.reddit.com/r/programming/comments/1g6x9g/dconf_2013_code_analysis_for_d_with_analyzed/



 Hackernews: https://news.ycombinator.com/item?id=5867764

 Twitter: https://twitter.com/D_Programming/status/344798127775182849

 Facebook: https://www.facebook.com/dlang.org/posts/655927124420972

 Youtube: http://youtube.com/watch?v=ph_uU7_QGY0
As I understand it, the static analyzer doesn't handle D completely. How does it behave/what happens if it encounters something it cannot handle?
It bails out.
Jun 15 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-06-15 23:50, Timon Gehr wrote:

 It bails out.
I see. That's always the problem when not using a complete compiler. Example, in my tool DStep which converts C headers to D modules it doesn't handle everything (macros and similar) but it won't bail out and continues parsing. That's because it uses a real complete compiler (Clang). So I can choose to either give an error and bail out, just skip what it cannot handle or output a comment in the translated file. -- /Jacob Carlborg
Jun 16 2013
prev sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Wednesday, 12 June 2013 at 12:50:39 UTC, Andrei Alexandrescu 
wrote:
 Reddit: 
 http://www.reddit.com/r/programming/comments/1g6x9g/dconf_2013_code_analysis_for_d_with_analyzed/

 Hackernews: https://news.ycombinator.com/item?id=5867764

 Twitter: 
 https://twitter.com/D_Programming/status/344798127775182849

 Facebook: 
 https://www.facebook.com/dlang.org/posts/655927124420972

 Youtube: http://youtube.com/watch?v=ph_uU7_QGY0

 Please drive discussions on the social channels, they help D a 
 lot.


 Andrei
The website for AnalyzeD <http://analyzed.no-ip.org/> is down. Did it get moved to somewhere else?
Nov 01 2013