Re: more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2

[Ludovic Courtès]

Hi Ken,

Ken Raeburn <address@hidden> writes:

> Compiling with SCM_DEBUG_TYPING_STRICTNESS=2 as discussed in __scm.h

Another compilation flag that must be rarely used.  :-)

Do you find it useful?

> It also means constant values for static initializers ("{ { BITS } }")
> have a different form from run-time expressions generating certain
> values ("scm_pack (BITS)" calls an inline function), and comparisons
> can't be done with "==" and "!=".  (In fact, tags.h already says "SCM
> values can not be compared by using the operator ==", right above the
> definition of scm_is_eq.)
>
> Guess what we're also doing? :-)
> And I haven't even tried compiling Ludovic's bdw-gc-static-alloc
> branch yet, just master.

Indeed, we're in trouble.

> #1: We continue to not support static initialization.
[...]

> #1a: Extend #1 later with whatever internal macros are needed to
> provide the right initialization syntax for constructs used in bdw-gc- 
> static-alloc based on the STRICTNESS setting.
>
> #1b: Try to supplement #1 with changes to SCM_PACK or SCM_MAKIFLAG to
> make it not considered a compile-time constant even with STRICTNESS<2
> and thus SCM_UNSPECIFIED, SCM_BOOL_F, etc are never suitable for
> static initialization, catching this problem earlier in the future.
[...]

> #1c: Try to supplement #1 by defaulting to STRICTNESS=2 on platforms
> where the union is passed and returned the same way as the pointer or
> integer in function calls
[...]

> #2: Drop STRICTNESS=2 support and really support static initialization
> with the current macros.
>
> #3: Keep STRICTNESS=2 support, and support static initialization, even
> for application code, with a bunch of new macros.

My preference is for #2 because: (1) I've never used it ;-), and
(2) we're moving away from C anyway.  Hmm, weak arguments maybe.

Anyway, in the meantime, we can conditionalize static initialization
stuff from bdw-gc-static-alloc on STRICTNESS == 0 and keep everyone
happy.

Does that sound reasonable?

> It looks like the eval code is going to be annoying too

I wouldn't worry much about this one either as its probably doomed, once
Andy's eval cleanup work is mature.

Things have been moving too fast lately!

Thanks,
Ludo'.