On Sunday, 21 August 2022 at 05:03:43 UTC, Ali Çehreli wrote:
> On 8/20/22 20:44, Walter Bright wrote:
>
> > I.e. a "payload" can be put in the mantissa bits of a NaN,
> which can be
> > used to provide more information about the NaN.
>
> I think it is called "nan boxing."
>
> > I've never seen anyone
> > use this, though, but someone might
>
> I heard about it either at a meetup or at a DConf. The speaker was explaining that exact technique.

Just learnt from here:

https://github.com/Robert-van-Engelen/tinylisp/issues/12#issuecomment-1752142467

> > Another question I want ask is: the NaN boxing trick is OK, but why it's needed here (for education purpose Lisp implementation, this trick I think actually distracted learners from learning Lisp)? Why cannot we just use bit fields or a small struct as tagged union? Also by using NaN boxing, are we actually wasting 13 bits for each double?
> 
> Lots of modern PL implementations use NaN boxing instead of tagged structs/unions. Nothing gets wasted, because a cell has to be a fixed size anyway, which is the larger size of all possible values it can hold. Adding a tag therefore makes the cell structure larger by a byte, at least, to hold a tag. That also makes addressing less efficient, since cells are no longer guaranteed to be 32 bit aligned (or the tag has to be 32 bits, which wasts more bits).


I think I understand it now, the benefits of using NaN boxing is that: in a 64-bit double

all the doubles are still fully represented
use 48 bit as pointer can still address 262,144 GB memory, that is good enough for any computer today
only integer's range gets shrunk: from 64-bit to 48-bit (49 with sign bit depends on if we choose to use it), that's good for most purpose, and if one really need > 48-bit integer type, then use the fat BigInt (class / struct) then (which will be treated as object pointer type).
(1) and (3) means all the scalar types are stored as scalar, not pointers to some other representations.

That's very compact design indeed.

On 8/21/22 16:09, Dark Hole wrote:
> 
> My point is making this by default for all primitive types. This will be consistent and simple:
> ```d
> bool x; // Error, use bool? or init it something meaningful
> struct Foo { bool x; } // Error too
> ```
> So we have no problem "programmers make meaningless 0" and have no problem to determine init for most of types.

I think a better way to approach this problem is to have a language where people are not tempted to declare a variable into which they have no sensible value to put in the first place. If you have no value at a given point in the program, you should not need a variable to hold one.

On Monday, 9 October 2023 at 00:03:24 UTC, Timon Gehr wrote:
> On 8/21/22 16:09, Dark Hole wrote:
>> 
>> My point is making this by default for all primitive types. This will be consistent and simple:
>> ```d
>> bool x; // Error, use bool? or init it something meaningful
>> struct Foo { bool x; } // Error too
>> ```
>> So we have no problem "programmers make meaningless 0" and have no problem to determine init for most of types.
>
> I think a better way to approach this problem is to have a language where people are not tempted to declare a variable into which they have no sensible value to put in the first place. If you have no value at a given point in the program, you should not need a variable to hold one.

~~definitely not bumping this thread to keep it alive~~

Im pretty sure that declaration before use needs to be a thing cause compilers are still bad at knowing where memory sure go and I need my goto and global scope variables.

On 10/8/2023 12:47 PM, mw wrote:
> That's very compact design indeed.


Interestingly, the nan boxing in tinylisp exposed a subtle code gen problem with dmd (fixed now).