ow Integers Should Work

[bcs]

On 12/08/2011 04:15 AM, Don wrote:
> On 08.12.2011 05:46, bcs wrote:
>> On 12/06/2011 11:50 PM, Don wrote:
>>>
>>> He's talking about system languages. A system language has to have a
>>> close relationship to the architecture.
>>>
>>> By contrast, if you don't care about performance, it's easy -- just use
>>> BigInts for everything. Problem solved.
>>>
>>> Looks like I have to put it more bluntly: I don't think he knows what
>>> he's talking about. (On this particular topic).
>>
>> I know exactly what you have been saying I just think you are wrong, not
>> because I don't think you knows what you are talking about but because I
>> think you are evaluating his conclusion based on a different criteria
>> than he is.
>
> HE PROPOSES CHANGING INSTRUCTION SETS.
>

[citation needed]

I just re-scanned both posts. The closest thing I found to suggesting 
that instruction sets be changed is proposing iNaN be used and that (if 
you scan futher up) is listed as one possibility (late trapping) along 
side another (early trapping) that (if you scan even further up) isn't 
even being suggested for every operation but only for non-intermediate 
values.

>> More specifically, I think we are dealing with a differing order of
>> priories for system languages. Mine would put safety (i.e. NO undefined
>> behaviour) over performance. I think he is going the same way.
>> Personally, if I could only have one, I think I'd (first) go with
>> defining overflow semantics rather than trapping but I'm not sure which
>> is more useful in a systems context.
>>
>> Can we at least agree that if you are only going to have one signed
>> integer semantic, that undefined overflow is the worst possible choice?
>
> Yes, but D doesn't have undefined overflow. So it's irrelevant.

I'm not talking about D. Well, not directly anyway. So that irrelevant. 
And I think we have concluded that there isn't a single bit of this back 
and forth that we both care about.