[Swift-devel] numeric types still

[Michael Wilde]

I lean to option A as well, as long as intergery kinds of things work as 
expected.

I also wonder if the solitary base scalar types can be String and File, 
and all arithmetic operations essentially implemented as if they are 
external functions - much like /bin/sh users would use expr for all 
calculations.

The type system needs to ensure that all operations on datasets are type 
correct, and this would make arithmetic follow the same conventions.

So just like a user can define "type Foo File"; then could also say 
"type Int String;",  "type Float String;", "type Number String;" etc. 
And we could use interpreter like dc, expr, awk, perl, or bash to do all 
arithmetic ops. Some built-in interpreter would be chosen as the base 
implementation. So the language could appear to have a flexible type 
system, but in fact it would be very simple and regular, and make no 
distinction between any kinds of numeric types as being special in any 
way. No implicit casting, etc. - that will remove much potential complexity.

This concept may or may not be feasible or desirable - I or others would 
need to explore it on paper a bit more.

But I think we all share the goal of keeping the Swift language as 
minimalist as possible, retaining its nature as a language with which to 
invoke chains of external programs.

- Mike



On 6/20/08 5:41 AM, 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.
>