Hi, Kevin Ryde <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Ludovic Courtès) writes: >> >> Performing this kind of optimization somehow breaks the >> compilation/execution boundary (see the links Rob posted): `provide?' is >> just a regular procedure, and as such its invocations should not be >> evaluated at compilation-time (the same goes for `defined?'). > > It's generally a good thing for a compiler to look into constant > expressions and reason based on them. In fact I'd much rather have > the compiler thinking about my constants than have macros. Macros > seem like a good idea but 9 times out of 10 they're not really. Maybe, but for the problem at hand, why leave that burden to the compiler when we could ease its life? Quoting SRFI-0: Another issue is the binding time of this construct (i.e. the moment when it operates). It is important that the binding time be early so that a compiler can discard the sections of code that are not needed, and perform better static analyses. Expressing this construct through a procedure returning a boolean, such as (feature-implemented? 'srfi-5), would not achieve this goal, as its binding time is too late (i.e. program run-time). Thanks, Ludovic. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
