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: Peter Bex
Subject: Re: [Chicken-hackers] [PATCH] Drop now-unnecessary exports from the "chicken.export" module
Date: Sat, 17 Jun 2017 16:57:41 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

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)?

Cheers,
Peter

Attachment: signature.asc
Description: Digital signature


reply via email to

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