Re: Introducing `cond-feature'

[Ludovic Courtès]

Hi,

Kevin Ryde <address@hidden> writes:

> address@hidden (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.