Re: So far, so good.

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

Dirk Herrmann <dirk@ida.ing.tu-bs.de> writes:

> Here's some good news:  Guile is very close to compile with strict
> typing.  To give a little more detail:
> 
> * On march, 27th there were 3330 compilation errors.  Now there are only
>   143 compilation errors left.
> * Of these 143 compilation errors,
>   - 83 are due to the 'SCM value as case label' problem
>   - 24 are due to errors in numbers.c, which are easy to fix, but I want
>     to wait with it until the performance degradation problem is solved.
>   - 20 are due to the 'SCM value as initializer' problem
>   - 6 are in options.c.  The options code needs some cleanup, IMHO.
>   - 5 are due to the fact, that generic functions are initialized
>     with zero. (lines: eval.c 3573, objects.c 152, print.c 358, 613,
>     procs.c 141)
>   - 2 are tests of a SCM value agains zero in read.c (lines 203, 217).  I
>     don't know if these tests make sense.
>   - 2 pass C zero values as SCM parameters to narrow_stack in stacks.c
>     (lines 497, 499).  Maybe it would be possible to use some valid scheme
>     value here?
>   - 1 is due to plain sick code in eval.c, line 1380.

Great!  Good work!

> 1)
> To solve the 'SCM value as case label' problem, it would be necessary to
> provide a corresponding raw (i. e. unpacked) value for each SCM
> value.  This could look as follows:
> 
> #define SCM_BOOL_T_WORD		SCM_MAKIFLAG (17)
> #define SCM_BOOL_T 		SCM_PACK (SCM_MAKIFLAG (17))
> 
> In case labels, the SCM_BOOL_T_WORD macro would have to be used.  I don't
> know if we want to go that way, or simply accept that we can not actually
> produce an executable with strict typing enabled.

What about using SCM_UNPACK (or some shorter form specially dedicated
for this use) both in the switch expression and in each label?  (Am I
being stupid now?)

> 3)
> The generic function issue:  As long as there is no generic function
> defined, the corresponding SCM value is set to zero.  However, I have the
> impression, that always if this value is tested and found to be zero, an
> error is signalled.  Wouldn't it be better, to _always_ initialize the
> generic function, such that the default if nothing fits would be the error
> message?  Then, a lot of code like
>   if (gf)
>     scm_apply_generic (gf, scm_cons (proc, args));
>   else
>     scm_wrong_type_arg (who, i + 2, ve[i]);
> would simply reduce to
>   scm_apply_generic (gf, scm_cons (proc, args));
> and there is always at least _one_ method for which the parameters fit,
> namely the function which then signals the wrong type argument error.  It
> shouldn't be a performance issue, since for the cases when no generic
> function was defined, an error would be signalled anyway.
> 
> Just a (possibly stupid) idea.

No, I think this is the right way.  The major reason why I didn't do
this already is that GOOPS was not a part of Guile, and it felt bad to
include the quite large amount of redundant code which would be
required to create GFs.  (Also, I didn't code under the strict typing
constraint.)

But as soon as I've put GOOPS in libguile, this is solved.

> 4) Except for the numbers.c errors, it would be kind if others who are
> more familiar with the corresponding parts of guile could take a look at
> those.

It would be grate if you could deal with numbers.c.  I promise to have
a look at (at least some of) the rest after 10/5.

Best regards,
/mdj