View mode: basic / threaded / horizontal-split · Log in · Help
November 05, 2009
Re: safety model in D
Andrei Alexandrescu Wrote:

> Leandro Lucarella wrote:
> > A clear example of this, is not being able to take the address of a local.
> > This is too restrictive to be useful, as you pointed in you post about
> > having to write static methods because of this. If you can't find
> > a workaround for this, I guess safety in D can look a little unrealistic.
> 
> Most other languages do not allow taking addresses of locals. Why are 
> they realistic and SafeD wouldn't? Just because we know we could do it 
> in unsafe D?

I think part of the problem is that current users of D have picked it up because they do get this power. But it makes sense that there are potential users that would like the compiler to prevent them from unsafe constructs. And I can't imagine it being more restrictive than Java or C# which are very popular languages.

I do like the different approaches though taken by C# and D. C# took a safe model and punched holes in it. D is taking an unsafe model and restricting it.
November 05, 2009
Re: safety model in D
Andrei Alexandrescu wrote:
> First off: _all_ languages except C, C++, and assembler are or at least
> claim to be safe. All. I mean ALL. Did I mention all? If that was some
> ideology that is not realistic, is extremely difficult to achieve, and
> ends up too painful to use, then such theories would be difficult to
> corroborate with "ALL". Walter and I are in agreement that safety is not
> difficult to achieve in D and that it would allow a great many good
> programs to be written.

You're forgetting about all other system programming languages.  Also,
many of these claims to safety are demonstrably false.

> The text is very approachable and informative, and I suggest anyone
> interested to read through page 5 at least. I think it's a must for
> anyone participating in this to read the whole thing. Cardelli
> distinguishes between programs with "trapped errors" versus programs
> with "untrapped errors". Yesterday Walter and I have had a long
> discussion, followed by an email communication between Cardelli and
> myself, which confirmed that these three notions are equivalent:
> 
> a) "memory safety" (notion we used so far)
> b) "no undefined behavior" (C++ definition, suggested by Walter)
> c) "no untrapped errors" (suggested by Cardelli)


They are clearly not equivalent.  ++x + ++x has nothing to do with
memory safety.  Conversely, machine language has no concept of undefined
behavior but is clearly not memory safe.  Also, you haven't formally
defined any of these concepts, so you're basically just hand-waving.


-- 
Rainer Deyke - rainerd@eldwood.com
November 05, 2009
Re: safety model in D
Rainer Deyke wrote:
> Andrei Alexandrescu wrote:
>> First off: _all_ languages except C, C++, and assembler are or at least
>> claim to be safe. All. I mean ALL. Did I mention all? If that was some
>> ideology that is not realistic, is extremely difficult to achieve, and
>> ends up too painful to use, then such theories would be difficult to
>> corroborate with "ALL". Walter and I are in agreement that safety is not
>> difficult to achieve in D and that it would allow a great many good
>> programs to be written.
> 
> You're forgetting about all other system programming languages.

[citation needed]

>  Also,
> many of these claims to safety are demonstrably false.

Which?

>> The text is very approachable and informative, and I suggest anyone
>> interested to read through page 5 at least. I think it's a must for
>> anyone participating in this to read the whole thing. Cardelli
>> distinguishes between programs with "trapped errors" versus programs
>> with "untrapped errors". Yesterday Walter and I have had a long
>> discussion, followed by an email communication between Cardelli and
>> myself, which confirmed that these three notions are equivalent:
>>
>> a) "memory safety" (notion we used so far)
>> b) "no undefined behavior" (C++ definition, suggested by Walter)
>> c) "no untrapped errors" (suggested by Cardelli)
> 
> 
> They are clearly not equivalent.  ++x + ++x has nothing to do with
> memory safety.  Conversely, machine language has no concept of undefined
> behavior but is clearly not memory safe.  Also, you haven't formally
> defined any of these concepts, so you're basically just hand-waving.

Memory safety is defined formally in Pierce's book. Undefined behavior 
is defined by the C++ standard. Cardelli defines trapped and untrapped 
errors.


Andrei
November 06, 2009
Re: safety model in D
Andrei Alexandrescu, el  5 de noviembre a las 09:57 me escribiste:
> Leandro Lucarella wrote:
> >Andrei Alexandrescu, el  5 de noviembre a las 08:48 me escribiste:
> >>First off: _all_ languages except C, C++, and assembler are or at
> >>least claim to be safe. All. I mean ALL. Did I mention all? If that
> >>was some ideology that is not realistic, is extremely difficult to
> >>achieve, and ends up too painful to use, then such theories would be
> >>difficult to corroborate with "ALL". Walter and I are in agreement
> >>that safety is not difficult to achieve in D and that it would allow
> >>a great many good programs to be written.
> >
> >I think the problem is the cost. The cost for the programmer (the subset
> >of language features it can use is reduced) and the cost for the compiler
> >(to increase the subset of language features that can be used, the
> >compiler has to be much smarter).
> >
> >Most languages have a lot of developers, and can afford making the
> >compiler smarter to allow safety with a low cost for the programmer (at
> >least when writing code, that cost might be higher performance-wise).
> 
> D is already a rich superset of Java. So the cost of making the
> language safe and useful was already absorbed.

That's an unfair comparison. Java has a very efficient GC (partially
because of safety), so using D as it were Java yields very inefficient
programs (using classes and new all over the places). D can't be
completely safe and because of that, it's doomed to have a quite worse GC,
so writing code a la Java in D beats the purpose of using D in the first
place.

> >A clear example of this, is not being able to take the address of a local.
> >This is too restrictive to be useful, as you pointed in you post about
> >having to write static methods because of this. If you can't find
> >a workaround for this, I guess safety in D can look a little unrealistic.
> 
> Most other languages do not allow taking addresses of locals. Why
> are they realistic and SafeD wouldn't? Just because we know we could
> do it in unsafe D?

Because in other languages there are no locals! All objects are references
and allocated in the heap (except, maybe, some value types). Again, you
can do that in D too, but because D is a system language, you can't assume
a lot of things and it has a lot less optimization opportune ties,
yielding bad performance when not used wisely.

> >I like the idea of having a safe subset in D, but I think being
> >a programming language, *runtime* safety should be *always* a choice for
> >the user compiling the code.
> 
> Well in that case we need to think again about the command-line options.

Not necessarily, -release is already there =)

But then, I don't have any issues with the GCC-way of hundreds of compiler
flags to have fine grained control, so I'm all for adding new flags for
that.

> >As other said, you can never be 100% sure your program won't blow for
> >unknown reasons (it could do that because a bug in the
> >compiler/interpreter, or even because a hardware problem), you can just
> >try to make it as difficult as possible, but 100% safety doesn't exist.
> 
> I understand that stance, but I don't find it useful.

The usefulness is that D can't be 100% safe, so spending time in trying to
make it that way (specially at the expense of flexibility, i.e., don't
providing a way to disable bound-checking in safe modules) makes no sense.
You'll just end up with a less efficient Java.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
The average person laughs 13 times a day
November 06, 2009
Re: the List example
Andrei Alexandrescu, el  5 de noviembre a las 10:06 me escribiste:
> Leandro Lucarella wrote:
> >A clear example of this, is not being able to take the address of a local.
> >This is too restrictive to be useful, as you pointed in you post about
> >having to write static methods because of this. If you can't find
> >a workaround for this, I guess safety in D can look a little unrealistic.
> 
> Sorry, I forgot to mention one thing. My example of List in the
> thread "An interesting consequence of safety requirements" used
> struct, but it should be mentioned there's a completely safe
> alternative: just define List as a class and there is no safety
> problem at all. Java, C#, and others define lists as classes and it
> didn't seem to kill them. I agree that using a struct in D would be
> marginally more efficient, but that doesn't mean that if I want
> safety I'm dead in the water. In particular it's great that pointers
> are still usable in SafeD. I'm actually surprised that nobody sees
> how nicely safety fits D, particularly its handling of "ref".

See my other response about efficiency of D when using new/classes a lot.
You just can't do it efficiently in D, ask bearophile for some benchmarks
;)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Wake from your sleep,
the drying of your tears,
Today we escape, we escape.
November 06, 2009
Re: safety model in D
Andrei Alexandrescu wrote:
> Rainer Deyke wrote:
>> You're forgetting about all other system programming languages.

Delphi.

>>  Also,
>> many of these claims to safety are demonstrably false.
> 
> Which?

I can get Python to segfault.

> Memory safety is defined formally in Pierce's book.

Do you mean "Types and programming languages" by Benjamin C. Pierce?
According to Google books, it does not contain the phrase "memory
safety".  It does contain a section of "language safety", which says
that "a safe language is one that protects its own abstractions".  By
that definition, machine language is safe, because it has no
abstractions to protect.

Another quote: "Language safety can be achieved by static checking, but
also by run-time checks that trap nonsensical operations just at the
moment when they are attempted and stop the program or raise an
exception".  In other words, Pierce sees runtime checks and compile-time
checks as orthogonal methods for providing the same safety.

> Undefined behavior
> is defined by the C++ standard.

Undefined behavior is a simple concept: the language specification does
not define what will happen when the program invokes undefined behavior.
Undefined behavior can be trivially eliminated from the language by
replacing it with defined behavior.  If a language construct is defined
to trash the process memory space, then it is not undefined behavior.

> Cardelli defines trapped and untrapped
> errors.

Untrapped error: An execution error that does not immediately result in
a fault.

I can't find his definition of "execution error", which makes this
definition useless to me.


-- 
Rainer Deyke - rainerd@eldwood.com
November 06, 2009
Re: safety model in D
== Quote from Leandro Lucarella (llucax@gmail.com)'s article
> Andrei Alexandrescu, el  5 de noviembre a las 09:57 me escribiste:
> > Leandro Lucarella wrote:
> > >Andrei Alexandrescu, el  5 de noviembre a las 08:48 me escribiste:
> > >>First off: _all_ languages except C, C++, and assembler are or at
> > >>least claim to be safe. All. I mean ALL. Did I mention all? If that
> > >>was some ideology that is not realistic, is extremely difficult to
> > >>achieve, and ends up too painful to use, then such theories would be
> > >>difficult to corroborate with "ALL". Walter and I are in agreement
> > >>that safety is not difficult to achieve in D and that it would allow
> > >>a great many good programs to be written.
> > >
> > >I think the problem is the cost. The cost for the programmer (the subset
> > >of language features it can use is reduced) and the cost for the compiler
> > >(to increase the subset of language features that can be used, the
> > >compiler has to be much smarter).
> > >
> > >Most languages have a lot of developers, and can afford making the
> > >compiler smarter to allow safety with a low cost for the programmer (at
> > >least when writing code, that cost might be higher performance-wise).
> >
> > D is already a rich superset of Java. So the cost of making the
> > language safe and useful was already absorbed.
> That's an unfair comparison. Java has a very efficient GC (partially
> because of safety), so using D as it were Java yields very inefficient
> programs (using classes and new all over the places).

Why does safety have to do w/ Java's GC quality?  IMHO it's more a language
maturity and money thing.  The only major constraint on D GC is unions and even in
that case, all we need is one bit that says that stuff in unions needs to be
pinned.  I think we already agree that storing the only pointer to GC allocated
memory in non-pointer types, xor linked lists involving GC allocated memory, etc.
are undefined behavior.  Other than that and lack of manpower, what prevents a
really, really good GC from being implemented in D?
November 06, 2009
Re: safety model in D
dsimcha, el  6 de noviembre a las 02:13 me escribiste:
> == Quote from Leandro Lucarella (llucax@gmail.com)'s article
> > Andrei Alexandrescu, el  5 de noviembre a las 09:57 me escribiste:
> > > Leandro Lucarella wrote:
> > > >Andrei Alexandrescu, el  5 de noviembre a las 08:48 me escribiste:
> > > >>First off: _all_ languages except C, C++, and assembler are or at
> > > >>least claim to be safe. All. I mean ALL. Did I mention all? If that
> > > >>was some ideology that is not realistic, is extremely difficult to
> > > >>achieve, and ends up too painful to use, then such theories would be
> > > >>difficult to corroborate with "ALL". Walter and I are in agreement
> > > >>that safety is not difficult to achieve in D and that it would allow
> > > >>a great many good programs to be written.
> > > >
> > > >I think the problem is the cost. The cost for the programmer (the subset
> > > >of language features it can use is reduced) and the cost for the compiler
> > > >(to increase the subset of language features that can be used, the
> > > >compiler has to be much smarter).
> > > >
> > > >Most languages have a lot of developers, and can afford making the
> > > >compiler smarter to allow safety with a low cost for the programmer (at
> > > >least when writing code, that cost might be higher performance-wise).
> > >
> > > D is already a rich superset of Java. So the cost of making the
> > > language safe and useful was already absorbed.
> > That's an unfair comparison. Java has a very efficient GC (partially
> > because of safety), so using D as it were Java yields very inefficient
> > programs (using classes and new all over the places).
> 
> Why does safety have to do w/ Java's GC quality?

Because you don't have unions and other things that prevents the GC from
being fully precise.

> IMHO it's more a language maturity and money thing.

That's another reason, but the Boehm GC is probably one of the more
advanced and state of the art GCs and I don't think it's close to what the
Java GC can do (I didn't see recent benchmarks though, so I might be
completely wrong :)

> The only major constraint on D GC is unions and even in that case, all
> we need is one bit that says that stuff in unions needs to be pinned.
> I think we already agree that storing the only pointer to GC allocated
> memory in non-pointer types, xor linked lists involving GC allocated
> memory, etc.  are undefined behavior.  Other than that and lack of
> manpower, what prevents a really, really good GC from being implemented
> in D?

Having a precise stack and registers. Java has a VM that provides all that
information. Maybe the distance between a good Java GC and a good D GC can
be narrowed a lot, but I don't think D could ever match Java (or other
languages with full precise scanning).

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
I always get the feeling that when lesbians look at me, they're thinking,
'*That's* why I'm not a heterosexual.'
	-- George Constanza
November 06, 2009
Re: the List example
On Thu, 5 Nov 2009 21:29:43 -0300, Leandro Lucarella
<llucax@gmail.com> wrote:

>See my other response about efficiency of D when using new/classes a lot.
>You just can't do it efficiently in D, ask bearophile for some benchmarks
>;)

This is in part because D doesn't have a compacting GC. A compacting
GC implies allocation speeds comparable with the speed of allocation
on stack. I guess many bearophile's benchmarks do not account for GC
collection cycles, which should be slower in C#/Java because of the
need to move objects. I think, fair benchmarks should always include
garbage collection times.
November 06, 2009
Re: the List example
Max Samukha:

>I guess many bearophile's benchmarks do not account for GC
> collection cycles,

I have not explored this well yet. From what I've seen, D is sometimes dead slow at the end program, when many final deallocations happen. In the Java versions of the tests this doesn't happen. A lot of time ago someone has even written a patch for the D1 GC to reduce that problem.

Bye,
bearophile
4 5 6 7 8 9
Top | Discussion index | About this forum | D home