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.
