chicken-hackers
[Top][All Lists]
Advanced

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

Re: [Chicken-hackers] [PATCH 0/1] Split eval.scm into chicken.eval and c


From: Evan Hanson
Subject: Re: [Chicken-hackers] [PATCH 0/1] Split eval.scm into chicken.eval and chicken.load modules
Date: Sat, 6 May 2017 11:03:45 +1200

Hi Peter,

On 2017-05-04 22:10, Peter Bex wrote:
> Nice, I've pushed this.  I noticed that we still have "eval-handler",
> which wasn't in core-libraries-reorg AFAIK.  I guess we need to keep
> that, and the only place that makes any sense for this would be in a
> "chicken.eval" module.
> 
> If we decide to keep a module like that after all, it makes less sense
> to have only one export.  So let's make eval/meta an official API.  It
> is a clean API that doesn't need to be internal/hidden at all; it could
> make sense for user code.  This allows us to get rid of another ##sys#
> prefix.

I'm not opposed to this, although I also don't see much problem with
having a module that only exports one thing either. The procedure will
probably be useful for some, and it offers users a new feature without
making the eval unit any heavier, so it makes sense to me.

However, I suggest we call this newly-exported procedure
"eval-for-syntax" instead. We already use the "for-syntax" convention
across the board, whereas "meta" is entirely absent from the standard
libraries so we'd be introducing a new term, unnecessarily, I think.

If that's agreeable, I'm happy to apply this and then fix up the name.

Cheers,

Evan

Attachment: signature.asc
Description: PGP signature


reply via email to

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