[Swift-devel] numeric types still

[Mihael Hategan]

I believe ML uses B and requires explicit conversion.
For example, it only defines +:int*int->int and +:real*real->real. So 1
+ 0.5 causes an error. You'd have to either do real(1) + 0.5 (or
presumably 1.0 + 0.5) or 1 + int(0.5).

Which doesn't look bad to me.

On Fri, 2008-06-20 at 10:41 +0000, Ben Clifford wrote:
> Numeric types bother me still. Substantially moreso now that my gsoc 
> student Milena has been working on typechecking and has reached the point 
> where the somewhat vague definitions of numerical types and implicit 
> casting are causing trouble.
> 
> Option A:
> 
> I'm very much in favour of a single numeric type, represented internally 
> by a java.lang.Double.
> 
> This is very much in line with what the implementation does at the moment 
> (for example the thread Tibi started the other day, where @extractint 
> actually uses java.lang.Double and can be used in either an int or a float 
> context in SwiftScript).
> 
> This would change (though not necessarily make worse) the behaviour of 
> integers when trying to go out of the range of what can be represented to 
> the accuracy of 1.
> 
> With integer representation, max_int+1 would roll round to min_int, those 
> being (respectively) +/- 2^31.
> 
> With double representation, the largest accurate integer is around 2^52 
> (which is larger than integer can store, though not as long as if we used 
> a long); after that I think that the problem will be that 2^52 + 1 = 2^52 
> (so incrementing will get stuck rather than rolling round). (give or take 
> a few orders of magnitude here, and assuming IEEE754 representation)
> 
> These numbers are sufficiently large to probably not cause problems any 
> time soon in real usage of SwiftScript; should accuracy prove a problem, 
> there is a clear path to move from double to some other more accuracte 
> general purpose numerical representation that does not massively change 
> the language (for example, switching to java.lang.BigDecimal).
> 
> On the downside, it changes type names - float and int both become 
> 'number' or some such. However, float and int could be deprecated and 
> internally aliases to 'number'.
> 
> I think that the actual use of numbers in SwiftScript, as counters and 
> things like that, that a rich numerical type system is not needed; and 
> that this requires straightforward code change to implement.
> 
> Option B:
> 
> We could instead define when it is appropriate to implicitly cast between 
> different types of numbers and in which direction.
> 
> I think this is more difficult to implement - it needs someone who is 
> interested in thinking about and defining the casting rules, which I think 
> no one is.
> 
> I think this also would increase, rather than decrease, the complexity of 
> the code base.
> 
> As you can probably tell, I am not in favour of option B.
> 
> I'm going offline this weekend; but Milena is lurking on this list and 
> might even come out of hiding to discuss further.
>