more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2

[Ken Raeburn <raeburn@MIT.EDU>]

Compiling with SCM_DEBUG_TYPING_STRICTNESS=2 causes SCM to be defined  
as a union type (though the comments say a struct type), which  
enhances the type checking by making random conversions and casts to  
and from pointer and integer types not work without going through the  
correct conversion macros/functions.

Problem is, we're doing some of those.

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.

I can clean some of this up trivially -- SCM_PACK/SCM_UNPACK as  
needed, change == to scm_is_eq.  The initializers make it slightly  
less trivial, and I can imagine different courses of action.

#1: We continue to not support static initialization.  Move most of  
the initializations in the library to the per-file init functions, and  
for stuff like the ra_iproc tables in array-map.c we may want *one*  
internal initializer macro (SCM_I_UNSPECIFIED_INIT or  
SCM_I_UNDEFINED_INIT? maybe even something zero-valued) for filling in  
slots in static structures without getting compiler warnings about  
missing initializers.

#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.  I  
believe a use of a comma expression will suffice, but finding a form  
that doesn't generate compiler warnings and doesn't generate run-time  
code could be tricky.  (Though, it becomes easier if we require only  
no performance impact when optimizing and with ... what, inline  
function support? gcc?)

#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, and where there isn't a significant  
performance impact.  Probably selected via cpp macros in __scm.h,  
since an autoconf feature test would be difficult at best, and still  
specific to the compiler used for building libguile and not the one  
used to build the application.  This helps us avoid the "==" and  
random casting part of the problem better in the future.  Mac OS X  
(10.5, Intel) seems to use the same calling convention both ways in  
one simple test, though I haven't tried performance testing.

#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.

Thoughts?  My preference is for #1 now, and #1a/b/c when convenient or  
needed.

Ken