Re: [BDW-GC] Static allocation of subrs

[ludo@gnu.org (Ludovic Courtès)]

Hi Neil,

Note: I reply to messages in order of least difficulty.  ;-)

Neil Jerram <neil@ossau.uklinux.net> writes:

> ludo@gnu.org (Ludovic Courtès) writes:

>>      For these reasons, we may want to merge this patch in `master' as
>>      well.
>
> Yes, I think so.

Noted, will do.

>>   2. The second step does the actual work [1].  Currently, it only
>>      deals with subrs, i.e., primitive procedures with "relatively few"
>>      arguments (see `create_gsubr ()').
>
> Presumably that is in practice almost all of the primitives, though?

That's 200 gsubrs, vs. 873 "simple" subrs.

>>      To distinguish subrs (few arguments) from gsubrs (unrestricted
>>      arity, see `default:' in `create_gsubr ()'), a Dirty Hack(tm) was
>>      needed.  The hack is that `SCM_DEFINE' is an alias for a new macro
>>      `SCM_DEFINE_SUBR_reqX_optY_rstZ', where X, Y and Z are the number
>>      of required, optional and rest arguments.  If X, Y and Z are such
>>      that a raw subr can be used, then the macro is an alias for
>>      `SCM_DEFINE_SUBR', which does the actual static allocation;
>>      otherwise, it's an alias for `SCM_DEFINE_GSUBR', which is the same
>>      as `SCM_DEFINE' in `master'.
>
> Not so bad, IMO.

It breaks cases like primitive procedures with more than 16 arguments
(because I arbitrarily decided that `snarf-gsubr.h' would contain
definitions up to 16 req/opt args), and situations like:

  SCM_DEFINE (scm_foo, "foo", 0001, 0002, 0003, ...)

This is probably acceptable in practice.

>>      The dirtiest part of the hack is the generation of "snarf-gsubr.h"
>>      which contains definitions of `SCM_DEFINE_SUBR_reqX_optY_rstZ' for
>>      a "reasonable" number of combinations of X, Y and Z (C++ template
>>      specialization would solve this problem much more elegantly...).
>
> This part is quite dirty, as you say.  I'm not sure what's the
> advantage of the generation at make time.  Wouldn't it be simpler, and
> have the same function, just to hardcode all these definitions
> directly in snarf.h?

Given the size of `snarf-gsubr.h' (there are 16 * 16 * 2 = 512
combinations), I'd rather keep it separated.  The makefile rule is an
efficient way to compress it.  ;-)

>> [0] http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=2ee5aa25dbd679b175707762f5961585027e1397
>
> Should probably remove the comments about how many subrs there are,
> since it's no longer relevant.

Right.

> I see there's no NEWS in the commit; is that because there's no impact
> on the API?  Even if so, I imagine it might merit a line in the 2.0
> release notes.  If you agree, I'd encourage you to write the NEWS now,
> rather than adding it later.

Right.  It's just that I have not maintained any NEWS file for
BDW-GC-related changes, initially.

> +  meta_info = scm_gc_malloc (2 * sizeof (* meta_info),
> +                            "subr meta-info");
>
> I found the space between "*" and "meta_info" confusing for a few
> seconds, so would have a preference for "*meta_info".

Yes, I feel the same today (I probably felt differently that day).  :-)

>> [1] http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=46f9baf49a8ea4461e8494c75a88b87d0f5c5195
>
> Why does the macro code sometimes use scm_i_paste, and sometimes ##
> directly?

The `scm_i_paste ()' macro is needed so that macro-expansion of
definitions like those of `srfi-4.i.c' work as expected.  There are a
few cases where it isn't used (e.g., in `SCM_IMMUTABLE_DOUBLE_CELL ()'),
but I guess it didn't cause any problem because `scm_i_paste ()' was
properly used by callers.  We could unify that but `scm_i_paste ()' has
the drawback of having a long name.

> Finally SCM_SUBR_ARITY_TO_TYPE... The implementation feels a bit
> messy, but I don't have any alternative to suggest, so I guess that's
> OK.

The problem is that this information is shared among 3 places:
`SCM_SUBR_ARITY_TO_TYPE ()', `create_gsubr ()', and
`SCM_DEFINE_SUBR_reqX_optY_rstZ ()'.  Ideally, all 3 would be generated
from a single source.

Besides, I think we need to review the use of subr/gsubr tag in detail
to see whether we can make better use of them.

> But what about the fact that it's added to the libguile API?  I
> realize that this is necessary to some extent so that snarf.h can be
> used by application code - but can we somehow restrict
> SCM_SUBR_ARITY_TO_TYPE to being used in that context, so that it
> doesn't become on ongoing constraint for us?

I share your concern, but I have no idea of how to avoid it.  We could
add `_I_' in its name, perhaps.  Hopefully, it's too low-level for
anyone to try it.

Thanks,
Ludo'.