nomennescio

> I don't see how we can use more precise types if the C libraries don't. If the C header uses `int` and `long` and similar types in its prototypes,...

https://docs.factorcode.org/content/article-c-types.primitives.html ``` char | always 1 byte uchar |   short | always 2 bytes ushort |   int | always 4 bytes long | same size as CPU word size and ...

(To be clear, there's only exceptional situations where it's not safe to assume the width of C's char (=`CHAR_BIT`) to be 8 bits. Other types' sizes are always multiples of...

An example from @mrjbq7 recent presentation: ``` HOOK: rdtsc cpu ( -- n ) M: x86.64 rdtsc longlong { } cdecl [ RAX 0 MOV RDTSC RDX 32 SHL RAX...

It might not be a fashionable opinion, but in many typical cases using 'nullptr' is overkill over the literal '0', which has been and still is the ISO C++ standard's...

> Some discussion here, it suggests the opposite: > > > Code will become more safe, intuitive, and expressive. `if (ptr == nullptr);` rather than `if (ptr == 0);` >...

> That's a fair point -- in that I really dislike `if (foo == false)` or `if (foo == true)` when foo has an implied truthiness. > > So if...

As a user, one can image to be able to inspect an error object with: ``` : whence ( error-object -- throw-location/f ) ... ; ```

I was thinking of slightly modifying `throw` to annotate that during parsing. To make that useful, that would also require a slightly different implementation of `ERROR:`, which now implicitly compiles...

(C++ example of a similar technique to annotate the location of a "call" to `FACTOR_ASSERT` in the VM; ``` #define FACTOR_ASSERT(condition) \ ((condition) \ ? (void)0 \ : (::fprintf(stderr, "assertion...