Add `#:eager` options to `stream-cons` to control whether the head
and/or tail expression is delayed. Also add `stream-lazy` to
explicitly construct a lazy stream and `stream-force` (normally not
needed) to force a stream.
Delayed expressions in `stream-cons` are now non-reentrant, like
promises created by `delay`. This is a change in behavior, but I'm
hoping that no one relied on the old behavior, which has the bad
property that the delayed expression is retained until its result is
received.
For consistency, this commit also changes `stream*` to delay the
stream-construction expression when its the only one expression that
is given.
Internally, changes to the stream implementation reduce allocation.
The `stream-lazy` form would be more natrally called `stream-delay`,
but that creates a conflict with existing packages.
Although setting `PLT_SETUP_OPTIONS` as an environment variable works
for the makefile created by `configure` in a source distribution, it's
better used/described as a makefile variable.
Closes#3735
Another try at the commit reverted by 471f18c02d, but this time with a
`SINGLE_BRANCH_FLAG` makefile variable that can be set to turn it off
for the rare system that has Git older than version 1.7.10.
The cross-library inlining improvement in commit 6020b944ef did not
manage internal names correctly, and it could mix up bindings that
have the same printed form.
Closesracket/ChezScheme#35
In this example, after the check with eq? or eqv? the value of
the variables x and y are known, so cptypes replaced the
reference to the variable with it. But it can interact badly
with the eq? test, for example in this case the first (eq? x y)
can be #f and the second be reduced by the compiler to #t.
In spite eq? cannot be used to compare numbers reliably, this
behavior is too confusing and it's better to avoid it.
(define (one)
(let ([r (random 2)])
(if (= r 0) (one) r)))
(define (f x y)
(define first-comparison (eq? x y))
(when (and (eqv? x 7.0)
(eqv? y 7.0))
(define second-comparison (eq? x y))
(eq? first-comparison second-comparison)))
(f (+ 6.0 (one)) (+ 6.0 (one)))))
BC did not take a lock for `hash-clear!`. Maybe the intent was that a
lock isn't needed from the perspective of `hash-clear!` when it isn't
traversing the table, but failing to take a lock before modifying the
table can break other operations (that do take a lock) in progress.
Furthermore, some iterations that intentionally did not take a lock
also did not guard against changes well enough. Various repairs here
avoid crashes, and now `hash-clear!` consistently takes a lock.
CS had a similar (but more subtle and more limited) instance of the
problem in `hash-map` and `hash-for-each`. That problem is corrected
(without adding any new lock acquisitions).
The existing CS implementation of `equal-hash-code` for hash tables
takes a lock more than the BC implementation. A possibly surprising
result: when attempting to add a mutable hash table to itself as part
of a key, the `hash-set!` can block forever on the hash table's lock,
instead of doing something more random as a result of having a mutated
key. The documentation now notes that possibility.
Related to #3738
With list-assuming-immutable? and the internal construct
immutable-list the compiler can assume that some lists will
not be mutated.
Also, change the definition of interned-char?, because in CS all chars
are interned.
This commit partly reverts c305dba649 and 88fc9a979f, which was
discusssed in #366.
The original discussion was about allowing an extra argument to
`member` to pick the equality predicate. That change is still in place
in the same (private) Racket module.
The `memq` and `memv` functions are in Scheme for Racket CS and back
to being and in C for Racket BC. The old motivation for moving `memv`
and `memq` --- to get them out of C --- is subsumed by the switch to
CS (granting that some C code got added back to BC meanwhile). The
advantage of moving `memq` and `memv` back to the runtime core is that
the compiler can do more with them, at least in CS.
When `memq` and `memv` were moved previously, they lost checking for
cyclic lists. That wasn't discussed and presumably wasn't on purpose;
check is restored here, including for `member`.
There's no significant performance change in CS, except in cases like
`(memq x '(a b c))` that the compiler unpacks into a combination of
`eq?`s. For BC, the C version is a little faster (10-40%, depending on
the length of the list), but still slower than CS (probably because
`pair?` is slower, which due to representation differences).
This change makes
(begin-encourage-inline
(define-values (f g h) (values e1 e2 e3)))
equivalent to
(begin-encourage-inline
(define f e1)
(define g e2)
(define h e3))
Fixes#3730.
By running inside a container we avoid CI breakages caused by changes
in the VM base image. In any case, lso update to use base image
ubuntu-20.04.
The `current-place` place-local variable was initialized relatively
late in the set of place-creation steps. It was possible for the
thread scheduler to get involved before `current-place` was set ---
and in that case, it was possible for semaphores and Racket threads to
end up being used in the wrong place.
Register allocation needs fresh machine-register state for each
compilation, and that was previously implemented by allocating a new
register record and indirecting references through a parameter. Move
the indirection to the places where conflict-set, index, and precolor
state is manipulated, and pass a state vector though to keep access
efficient. This change makes compilation slightly faster, and it makes
registers easier to work with by not having to introduce
indirections/delays in various places for register references.
Moving the np-expand-primtives pass to a separately compiled source
file reduces peak memory use when compiling Chez Scheme from about 1.3
GB to about 0.7 GB on a 64-bit platform. It's also nice from a
code-navigation perspective to split a 19k-line file to a 10k-line
file plus 8k-line file (and some additional small files).
The overall time for Chez Scheme to compile itself is only slightly
affected, even though some support functions, macros, and record
declarations end up getting compiled twice.
More generally, make the path-fixup step insensitive to specific
filenames in the "lib" directory, making it more like the handling of
the "bin" directory.
The logic was added in the previous commits, but it's necesary to add
the mapping from the names in primdata to cptypes.
Also add a few subsets of fixnum.
Running a `starter`-based executable with an argv[0] different
than the executable's path can make sense in various situations, but
it doesn't work for finding code embedded in the enxecutable. On
platforms where it's possible to get the current process's executable
(not looking at you, OpenBSD), then use that instead of argv[0] for
the purposes of loading embedded code.
Related to #3685
