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:
On Sat, 15 Jun 2013 11:16:22 -0400, Jacob Carlborg d...@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
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
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
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
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:
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
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,
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:
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
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 don't understand this topic well enough, so I am not saying
useful things. Thank you for your comments Timon...
Bye,
bearophile
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
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:
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.
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
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.
--
On Fri, 14 Jun 2013 05:12:09 -0400, Jacob Carlborg d...@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
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
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:
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
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:
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
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:
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:
On 6/12/13, Adam D. Ruppe destructiona...@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
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
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.
On Wed, 12 Jun 2013 08:50:41 -0400
Andrei Alexandrescu seewebsiteforem...@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:
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
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).
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
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
On 6/12/13, Adam D. Ruppe destructiona...@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
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.
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
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
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
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
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
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
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
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.
Walter Bright:
See the link to Bruce Eckel's article I posted in this thread.
Mine was a rhetorical question :-)
Bye,
bearophile
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:
45 matches
Mail list logo
