DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[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

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[David]

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?

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Andrei Alexandrescu]

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

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[bearophile]

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

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Adam D. Ruppe]

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.

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Andrei Alexandrescu]

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

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Andrej Mitrovic]

On 6/12/13, Adam D. Ruppe  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.

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Adam D. Ruppe]

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".

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Jonathan M Davis]

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

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Nick Sabalausky]

On Wed, 12 Jun 2013 08:50:41 -0400
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

Torrents and links:
http://semitwist.com/download/misc/dconf2013/

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Walter Bright]

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.

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Jonathan M Davis]

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

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[bearophile]

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

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Walter Bright]

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.

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[bearophile]

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

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Andrej Mitrovic]

On 6/12/13, 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.

I thought doing this only for function definitions could make sense.
For declarations the user would have to do it manually.

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Ary Borenszweig]

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)

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Ary Borenszweig]

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?

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Timon Gehr]

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?

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Adam D. Ruppe]

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.

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[bearophile]

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

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Ary Borenszweig]

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?

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[bearophile]

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

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Jonathan M Davis]

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

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Walter Bright]

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.

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[bearophile]

Walter Bright:


See the link to Bruce Eckel's article I posted in this thread.


Mine was a rhetorical question :-)

Bye,
bearophile

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Anthony Goins]

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?

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[bearophile]

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

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Jacob Carlborg]

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

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Don]

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.

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[bearophile]

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

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[bearophile]

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

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Jacob Carlborg]

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

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Steven Schveighoffer]

On Fri, 14 Jun 2013 05:12:09 -0400, Jacob Carlborg  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

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Dicebot]

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.

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Jacob Carlborg]

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

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Jacob Carlborg]

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

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Timon Gehr]

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.

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Timon Gehr]

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.

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[bearophile]

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

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Timon Gehr]

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.

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[bearophile]

I don't understand this topic well enough, so I am not saying 
useful things. Thank you for your comments Timon...


Bye,
bearophile

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Jacob Carlborg]

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

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Steven Schveighoffer]

On Sat, 15 Jun 2013 11:16:22 -0400, Jacob Carlborg  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

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Jacob Carlborg]

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

Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[Brad Anderson]

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  is down.  
Did it get moved to somewhere else?