Hi Ken,
Ken Raeburn <raeb...@raeburn.org> 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'.
