^^ limitation

[Marco Leise]

Am Wed, 25 Apr 2012 06:00:31 +0900
schrieb "Tyro[17]" <nospam at home.com>:

> I believe the following two lines of code should produce the same 
> output. Is there a specific reason why doesn't allow this? Of course the 
> only way to store the result would be to put in into a BigInt variable 
> or convert it to string but I don't that shouldn't prevent the compiler 
> from producing the correct value.
> 
> (101^^1000).to!string.writeln;
> (BigInt(101)^^1000).writeln;
> 
> Regards,
> Andrew

Well... what do you want to hear? I like to know that the result of mathematical operations doesn't change its type depending on the ability to  compile-time evaluate it and the magnitude of the result. Imagine the mess when the numbers are replaced by constants that are defined else where. This may work in languages that are not strongly typed, but we rely on the exact data type of an expression. You are calling a function called to!string with the overload that takes an int. A BigInt or a string may be handled entirely differently by to!string. The compiler doesn't know what either BigInt is or what to!string is supposed to do. It cannot make the assumption that passing a string to it will work the same way as passing an int. What you would need is that int and BigInt have the same semantics everywhere. But once you leave the language by calling a C function for example you need an explicit 32-bit int again.
If you need this functionality use a programming language that has type classes and seamlessly switches between int/BigInt types, but drops the systems language attribute. You'll find languages that support unlimited integers and floats without friction. Or you use BigInt everywhere. Maybe Python or Mathematica.

-- 
Marco