Recently we have discussed a lot about the balance of putting things inside the language or outside of it. It's a subtle balance and it's dynamic too, with time it can change (for example the removal of complex numbers from D2?). Surely it will need more discussions in the future too.

In the past I have discussed about the uses of multi-precision integral numbers. They can be put inside the std lib (std.bigint) or inside the compiler (many other languages, etc).

But there's another intermediate solution regarding those multi-precision numbers: keep them outside the language but allow the language to manage them with a transparent syntax. So even if the compiler doesn't know how to add two of such numbers (and you have to load such operations from a module), the syntax of the language allows you to write:

import bigints: Bigint;
...
Bigint x = 71_459_266_416_693_160_362_545_788_781_600;

Instead of:
BigInt x = "71459266416693160362545788781600";

This keeps the implementation of the operations outside the compiler, keeping it simpler and allowing different implementations, for example using bindings to the GNU multiprecision, and allows the user to manage such numbers in a transparent way, as (or almost as) they were built-in in the language.

(Such strategy of putting just "transparent" syntax support into the language, and keeping the implementation outside it, can be used in other situations too, for example for a possible set data structure, etc).

-----------------------

In my structs/classes that support iteration I may have a method like:
int opApply(int delegate(ref string) dg) {...}

But I may also often want to iterate on such objects with a progressive index too, so I have to duplicate all the code like this:

int opApply(int delegate(ref int, ref string) dg) {...}

I think it can be useful to invent some way for the compiler to create such second method by itself, (only when the programmer asks so).

(There are alternative ways to solve this problem, for example creating an iterable struct like xenumerate() similar to the Python enumerate(), or iterating the single-argument opApply() inside the two argument opApply(), but such solutions slow down the code).

-----------------------

The recent discussions about numbers with double meaning have to address bugs-waiting-to-happen like this too:

long n = 1_000_000 * 1_000_000;
Now n == -727379968

And several other silly things like the following ones:

uint n2 = -100;
now n2 == 4294967196

writefln(050); // ==> 40

Bye,
bearophile

bearophile пишет:
> Recently we have discussed a lot about the balance of putting things inside the language or outside of it. It's a subtle balance and it's dynamic too, with time it can change (for example the removal of complex numbers from D2?). Surely it will need more discussions in the future too.
> 
> In the past I have discussed about the uses of multi-precision
> integral numbers. They can be put inside the std lib (std.bigint) or
> inside the compiler (many other languages, etc).
> 
> But there's another intermediate solution regarding those multi-precision numbers: keep them outside the language but allow the language to manage them with a transparent syntax. So even if the compiler doesn't know how to add two of such numbers (and you have to load such operations from a module), the syntax of the language allows you to write:
> 
> import bigints: Bigint; ... Bigint x = 71_459_266_416_693_160_362_545_788_781_600;
> 
> Instead of: BigInt x = "71459266416693160362545788781600";
> 
> This keeps the implementation of the operations outside the compiler, keeping it simpler and allowing different implementations, for example using bindings to the GNU multiprecision, and allows the user to manage such numbers in a transparent way, as (or almost as) they were built-in in the language.
> 

It is not enough to make Bigint the object?

Weed:
> It is not enough to make Bigint the object?

I think I have already answered your question (and at the moment BigInt is a struct, I think).

Bye,
bearophile

bearophile пишет:
> Weed:
>> It is not enough to make Bigint the object?
> 
> I think I have already answered your question (and at the moment BigInt is a struct, I think).


I did not understand the problem.

You can make an object Bigint. You can add, deduct the value BigInt. You can declare them as follows:

Bigint x = "71_459_266_416_693_160_362_545_788_781_600";

or even so (to avoid confusion with strings):

Bigint x = Bigint("71_459_266_416_693_160_362_545_788_781_600");

Only that it will be impossible to do so to declare x static :)

And another: where else can I apply it?

Weed schrieb:
> bearophile ÐÉÛÅÔ:
>> Weed:
>>> It is not enough to make Bigint the object?
>> 
>> I think I have already answered your question (and at the moment BigInt is a struct, I think).
> 
> 
> I did not understand the problem.
> 
> You can make an object Bigint. You can add, deduct the value BigInt. You
> can declare them as follows:
> 
> Bigint x = "71_459_266_416_693_160_362_545_788_781_600";
> 
> or even so (to avoid confusion with strings):
> 
> Bigint x = Bigint("71_459_266_416_693_160_362_545_788_781_600");
> 
> Only that it will be impossible to do so to declare x static :)
> 
> And another: where else can I apply it?

he just want to avoid the "..." around the number

Weed:
> And another: where else can I apply it?

Apply what to where?
(English isn't my first either).

Bye,
bearophile

dennis luehring:
> he just want to avoid the "..." around the number

I know it may seem a small thing, but it allows you to write generic code that works both with int numbers and Bigint ones, just changing one type, for example of an alias or a template :-)

Bye,
bearophile

bearophile пишет:
> Weed:
>> And another: where else can I apply it?

where else can I use that thing?

> 
> Apply what to where?

> (English isn't my first either).

and my too :)

Weed:
> where else can I use that thing?

I was talking about a built-in syntax for multi-precision integral numbers. I presume you can use it only when you want to use multi-precision integral number :-)
Do you feel the need to use it in other situations too?

Bye,
bearophile

bearophile пишет:
> Weed:
>> where else can I use that thing?
> 
> I was talking about a built-in syntax for multi-precision integral numbers. I presume you can use it only when you want to use multi-precision integral number :-)
> Do you feel the need to use it in other situations too?

I thought proposes a more advanced method for operators overloading :)

It seems to me, all operators working with values should correspond to processor instructions. Instruction like "Sum int [80] with int [30]" does not exist and it is not necessary to do for it the built-in-like syntax.