Hi Zelphir,
Zelphir Kaltstahl <zelphirkaltst...@posteo.de> writes:
> At first I had the macro use `define`, but then I thought: "What if I
> want to conditionally define a route procedure?". My guess is, that then
> the define form would be inside some `cond` or `if` form and then it
> would not work
You're right, it would not work. Nonetheless, I would strongly
discourage you from doing this kind of thing unless there's a very
compelling reason for it.
Note that we have 'cond-expand' from SRFI-0 for conditional inclusion of
definitions, if you need it. 'cond-expand' is roughly analogous to #if
in C. It's less general than plain 'if', but there's an important
reason for that, and it has to do with the distinction between compile
time and run time.
If you use 'cond-expand', the condition is checked at compile time, and
consequently it is known at compile time which branch was taken and
therefore which definitions were chosen.
If you use 'cond', then the condition will be checked at run time, which
will normally rule out the possibility of optimization opportunities
such as inlining and partial evaluation. At present, Guile is not able
to perform these optimizations for toplevel level definitions in any
case, but it might be possible in the future, at least for modules that
are not explicitly mutated using low-level operations like this.
Also, it's possible that a future version of Guile may be more
disciplined in its handling of phases, i.e. expand-time
(i.e. compile-time) vs run-time phases. See section 7.2 (Import and
export levels) of the R6RS for details on one approach, which would
bring many advantages. It's been a while since I looked at this
closely, and at this point I would need some time to refresh my memory
of the details, but it seems to me that the code you've written would
likely cause problems with such an approach.
Both the R6RS and R7RS have more declarative module systems, which bring
many benefits. Added freedom in one area often implies a loss of
freedom somewhere else. In this case, the freedom to treat modules as
arbitrarily mutable objects implies a loss of freedom in the compiler to
make any assumptions about what's in the module or even its set of
bindings. That freedom carries a very significant cost.
Mark
