Re: Another macro/module question related to implementing srfis.

[Rob Browning <rlb at cs dot utexas dot edu>]

Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:

> I was thinking about something like:
> 
> (define-syntax define/guile ...)
> 
> (define-syntax define/rscheme ...)
>
> (let ()
>   (define/guile (check-args ...) ...)
>   (define/rscheme (check-args ...) ...))

Right, but with this approach, when you don't have a module system,
you still publish those macros in the global namespace rather than
hiding them in the closure.  Also, since we don't really have a macro
system that's common across the implementations yet, it will be hard
to find a suitable way to even write those macros so that the don't
choke any of the implementations.

> But, I do agree that it can be useful to have local cond-expand.  It's
> just that I'm not sure it is useful enough in the general case to
> motivate an extension of the basic language.

Well if you want to be able to have a "single file" implementation of
things like these srfi's that works across a number of scheme
implementations, shares common code, uses natural lanugage constructs,
can take advantage of a module system (or whatever) when it's
available, but doesn't suffer when it's not, and if you don't want to
have to automatically generate these files per-implementation at build
time, then it seems like that in a fair number of cases, cond-expand
isn't going to cut it.  However, I understand that augmenting it might
not be feasible.

In any case, I guess I'm going to try the "break the implementation up
into multiple files" approach.  Then I'll either splice the right
files together at "install time" (with cat, or perl, or guile, or
whatever) for a particular implementation, or I'll see if I can manage
to solve the problem by "load"ing the appropriate pieces.  I think
this'll probably make the source a little less readable/managable, but
it'll be OK.

Thanks

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930