chicken-hackers
[Top][All Lists]
Advanced

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

Re: [Chicken-hackers] [PATCH] Drop now-unnecessary exports from the "chi


From: felix . winkelmann
Subject: Re: [Chicken-hackers] [PATCH] Drop now-unnecessary exports from the "chicken.export" module
Date: Sat, 17 Jun 2017 19:22:39 +0200

> On Sat, Jun 17, 2017 at 10:40:28AM -0400, John Cowan wrote:
> > On Sat, Jun 17, 2017 at 10:25 AM, Peter Bex <address@hidden> wrote:
> > I can imagine those macros going into (chicken base) and/or some
> > > other modules, but a (chicken syntax) module with them in it makes
> > > sense too.  Then we could just rename (chicken syntax) on the
> > > c-l-r page to (chicken expand) and keep expand.scm as-is.
> >
> > That sounds right to me.  The R7RS Yellow Edition (next after the current
> > Orange Edition) will focus on syntax, and I plan to propose that all the
> > macros added to the large language be put in a single (scheme syntax)
> > library, possibly including SRFIs 2, 8, 17, 26, 31 ....  Keeping the macro
> > expansion machinery in (chicken expand) makes sense to me as well.
>
> Good to know, it makes sense to make CHICKEN's structure match R7RS.
> On the other hand, the (scheme base) library contains things like
> syntax-rules, and, or, define-record-type, all the "let" variants and
> so on, so it makes equal sense for us to include all the "standard"
> CHICKEN macros in (chicken base).
>
> Having them in (chicken base) feels a bit less arbitrary, too:
> otherwise users will need to (import (chicken base)) for things like
> add1 and error, while they need to (import (chicken syntax)) for
> and-let* and define-inline.  And define-record-type would probably
> go into (chicken base) too, since it's in R7RS (scheme base).
> So why have some macros in (chicken syntax) and others in (chicken base)?

WARNING: BIKESHEDDING ALERT!


felix




reply via email to

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