> On Sat, Jun 17, 2017 at 10:40:28AM -0400, John Cowan wrote: > > On Sat, Jun 17, 2017 at 10:25 AM, Peter Bex <[email protected]> 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 _______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
