summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorKaz Kylheku <kaz@kylheku.com>2020-05-03 09:11:33 -0700
committerKaz Kylheku <kaz@kylheku.com>2020-05-03 09:11:33 -0700
commitc86387b60babe9805c2873f47b2e3d0d2948ec9f (patch)
tree5a3fdc8fa1e626360b8933c2672c90a1929e0c4f
parent542f3e3bb66011d8041af5684ed64ed581ece635 (diff)
downloadtxr-c86387b60babe9805c2873f47b2e3d0d2948ec9f.tar.gz
txr-c86387b60babe9805c2873f47b2e3d0d2948ec9f.tar.bz2
txr-c86387b60babe9805c2873f47b2e3d0d2948ec9f.zip
compiler: honor load-time in parts of loop.
* share/txr/stdlib/compiler.tl (compiler comp-for): If a for loop occurs in the top level, or inside a load-time, then we don't want to suppress the semantics of load-time for any parts of the loop that are repeatedly evaluated. The programmer may be doing that specifically to hoist those calculations out of the loop. We thus bind *load-time* to nil after compiling the initializing and test expressions. * txr.1: New paragraph in Notes for load-time, mentioning compiler treatment of loops and lambda. The language is deliberately general rather than being specifically about the for loop, because several loop constructs compile to the for loop, and that is also subject to future changes.
-rw-r--r--share/txr/stdlib/compiler.tl1
-rw-r--r--txr.114
2 files changed, 15 insertions, 0 deletions
diff --git a/share/txr/stdlib/compiler.tl b/share/txr/stdlib/compiler.tl
index 88792259..8b8baa20 100644
--- a/share/txr/stdlib/compiler.tl
+++ b/share/txr/stdlib/compiler.tl
@@ -1087,6 +1087,7 @@
(mac-param-bind form (op inits (: (test nil test-p) . rets) incs . body) form
(let* ((treg me.(alloc-treg))
(ifrag me.(comp-progn treg env inits))
+ (*load-time* nil)
(tfrag (if test-p me.(compile oreg env test)))
(rfrag me.(comp-progn oreg env rets))
(nfrag me.(comp-progn treg env incs))
diff --git a/txr.1 b/txr.1
index c8da18f7..bc9096c4 100644
--- a/txr.1
+++ b/txr.1
@@ -71539,6 +71539,20 @@ closure which is returned. Invoking the closure doesn't cause the
.code load-time
expressions to be evaluated.
+The
+.code load-time
+form is subject to compiler optimizations. A top-level expression is assumed to
+be evaluated in load time, so
+.code load-time
+does nothing in a top-level expression. It becomes active inside forms
+embedded in a
+.code lambda
+expressions. Since
+.code load-time
+may be used to hoist calculations outside of loops,
+.code load-time
+is also active in those parts of loops which are repeatedly evaluated.
+
The use of
.code load-time
is similar to defining a variable and then referring to the variable.