Re: typedef struct SCM

[Jim Blandy <jimb at red-bean dot com>]

> after squashing the umpteenth type conversion bug in Lily, I'm
> submitting the following proposal.
> 
> How about changing the type of SCM from
> 
>     typedef long SCM;
> 
> to
> 
> 	typedef struct {
> 		long object;
> 		} SCM;
> 
> Since this doesn't really change anything for compiler (afaict), this
> should not make a difference for the performance of GUILE.  Since SCM
> values are always accessed using functions and macros this should also
> not make a difference for the source code.

This is a great idea for typechecking, and it's been discussed before.

Making SCM a struct or union does have a performance impact.  The
ABI's on some architectures (including the x86) require aggregates, of
any size whatsoever, to be passed and returned using slower
conventions.  For example, on the x86, a function returning an
aggregate expects an invisible first argument from the caller telling
it where to put the return value.  The value is not returned in a
register, even if it fits in a single word.

The proper approach, in my opinion, is to make it a compile-time
option.  You'd never actually install the Guile libraries or run your
application with the code produced; you'd just compile with it,
correct your type errors, and then "make clean" and recompile without
it.

GCC actually has a hack called transparent unions which almost gives
us the best of both worlds --- it allows you to define union types
which are passed to functions as if they were an instance of their
first element.  But it only applies to values passed, not values
returned.  If someone wrote patches for GCC that extended transparent
unions to influence return values as well, then we could have strict
type checking and efficient code at the same time.