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.



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.



 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