Re: Infinity (to the nearest integer)

On Thu, Oct 14, 2010 at 3:29 PM, Mark S. Miller <[email protected]> wrote:

> On Thu, Oct 14, 2010 at 3:12 PM, Jonathan S. Shapiro <[email protected]>wrote:
> On reflection, I meant two things:
>
>>
>> 1. The same computation should produce the same result when executed in
>> the same precision w.r.t. all methods of observing the result.
>>
>> 2. There needs to be a consistent way of [de]serializing NaN/infinity.
>>
>> Unfortunately, [1] means in practice that a specific bit pattern must be
>> selected. This is true because untagged unions of non-pointer scalars are
>> generally treated as "safe" by current runtimes. Consider explicit structure
>> layout in .Net.
>>
>
> This isn't true for Java. I know nothing about .Net. Could you explain?
> Thanks.
>

I can try. :-)

In .Net, a "struct" defines an unboxed type. There is also a concept of
programmer-controlled layout for structs. The three choices are "explicit"
(programmer can specify offset of each field), "sequential" (compiler cannot
re-order or interleave fields for packing purposes), or "automatic"
(compiler is in charge). The purpose of this feature is to allow untagged
union support, and also to support interop with native languages that use
sequential layout (notably C).

When using explicit layout, it is possible and legal to cause the
representations of two non-object-reference scalar fields to overlap. Such
structures are considered safe (in the eyes of the verifier) *provided* that
fields having reference type do not overlap any other fields. Instance
fields of non-static explicit layout structures are not guaranteed to be
concurrency-safe.

In practice, .NET structures having overlapping fields tend to confuse the
verifier's check of the "definite assignment" rule, and can run into
difficulties because the size of a reference is target-dependent and the
static compiler only checks safety for the current compilation target.

But the summary for our discussion is that the bit-pattern of NaN on .Net is
observable by exploiting the explicit layout feature. While this need not
impact the specification of E for other platforms, it does require that the
NaN representation (and so forth) be pinned down in .Net implementations.


shap

_______________________________________________
e-lang mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/e-lang