guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Confusing problems with (ice-9 syncase) and sc-expand3.


From: Rob Browning
Subject: Re: Confusing problems with (ice-9 syncase) and sc-expand3.
Date: 02 Jun 2001 15:06:52 -0500
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

Marius Vollmer <address@hidden> writes:

> I've got it, I think.  The problem was that `module-export!' (which
> underlies `export') always clones the exported variables.  Syncase
> keys important properties on variables, and it gets confused when
> variables are duplicated.
> 
> I fixed this by changing `module-export!' so that it doesn't clone
> variables any longer.

Ahh.  Wow, that actually makes some sense.  I'd seen the properties
stuff and wondered about it, but I'm not familiar enough with how the
module system works yet to have even been remotely likely to make the
connection :>

> I think we could extend the semantics of the module system so that it
> binds symbols not only to variables, but also to other things, like
> syntax transformers.  This is different from storing special #<macro>
> objects in variables, and would be the right thing IMO.

Hmm.  That sounds good, but what effect would it have on redefinitions
(not that I really know what happens now :>).

> This works now, but it does not work when you don't re-export
> syncase.  This is kind of right, since `eval-when' is defined in
> (ice-9 syncase), and you don't see it unless you use that module.
> Thus, it shouldn't be recognized as a special form either.

That's expected, though, right?  Isn't that just another side effect
of the fact that ATM you can't export macros that might expand into
other things that aren't also exported?

Anyway, thanks for figuring this out.  I'll see if I think having it
fixed affects my compilation plans, but I suspect not.  I still don't
like (presuming I haven't misunderstood it) the way that psyntaxes
eval-when works.  Though maybe I'll go re-read the CL reference again
and see if theirs is the same, and if so, if there's some
justification for it.

I think for now, I'll probably just fix up cond-expand as I proposed,
and in the long run, if we don't just stick with cond-expand, we might
want to see if moving in the direction of CL's eval-when is
appropriate (or perhaps a more limited version thereof).

-- 
Rob Browning <address@hidden> PGP=E80E0D04F521A094 532B97F5D64E3930



reply via email to

[Prev in Thread] Current Thread [Next in Thread]