[cap-talk] definition of the term "safe language"

[Mike Samuel]

2010/4/8 Sandro Magi <naasking at higherlogics.com>:
> On 09/04/2010 12:24 AM, Mike Samuel wrote:
>> "A programmer using this language then expects that an array can be
>> changed only by using the update operation on it explicitly---and not,
>> for example, by writing past the end of some other data structure.
>> Similarly, one expects that lexically scoped variables can be accessed
>> only from within their scopes, that the call stack truly behaves like a
>> stack, etc."
>>
>> Pierce clearly considers unexpected results an abstraction violation.
>
> Not how you're using "unexpected results". If you take it to mean
> "results inconsistent with the safety properties guaranteed by the
> spec", then I agree, and in fact Java implements exactly these safety
> properties and thus is safe.

Nonsense.  As I pointed out earlier, if any implementation that agreed
with its spec were safe then C would be safe.

> You're using "unexpected results" to mean, "behaviour that someone
> unfamiliar with the spec disagrees with or does not understand".
>
>> And the case of arrays is not a case of one abstraction violating
>> another without any "abstraction boundary" violation -- only one
>> abstraction, arrays, need be involved in an out of bounds pointer
>> dereference.
>
> I assume you're referring to my C example. Local variables are indeed a
> completely separate abstraction from arrays, and yet you can set a local
> variable by setting an array slot. How is that not a case of one
> abstraction violating another?
>
>> Floating point in java violates expectations.
>
> Violating expectations is not a safety property, unless said
> expectations are explicitly specified as properties guaranteed by the
> spec. Non-strictfp code guarantees fewer properties than strictfp code,
> but is not inherently unsafe.
>
>> One reasonably expects that
>>     double[] arr = new double[100000];
>>     for (int i = arr.length; --i >= 0;) { arr = 12345678d / 87654321d; }
>> Programmers reasonably expect that floating point operations within a
>> platform are reproducible, but that is not the case when the JIT can
>> kick in at an arbitrary point and start using 80b registers where 64b
>> registers were used earlier in a loop.
>
> Assuming that can actually happen in the middle of a loop, then the
> property "Programmers reasonably expect that floating point operations
> within a platform are reproducible" is simply false for non-strictfp
> Java. In other words, an abstraction that you WANT is being violated,
> not an abstraction that Java PROVIDES. Big difference.
>
> What Java provides is a perfectly valid semantics for non-portable
> floating point code, and no abstraction is actually being violated. The
> absence of your property for non-strictfp code does not make Java
> unsafe, because determinism is not a property of Java. In order for you
> to demonstrate a safety violation, this semantics must contradict some
> other property guaranteed by the spec.
>
> If strictfp were specified and the 80b ops were used, THEN the floating
> point abstraction would be violated. If the Java spec guaranteed
> determinism for all value operations, THEN abstraction would be
> violated. As far as I can see, the floating point semantics are
> perfectly consistent and safe, albeit not very programmer friendly in
> non-stricfp mode.
>
> Sandro
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>