[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
signature.asc
Description: PGP signature