The previous for/fold/derived examples in the docs
incorrectly expanded, placing the entire body of the
user defined for loop into a let expression inside of
for/fold/derived. This meant that break clauses (i.e. #:break
or #:final) that appeared in the body of the user-defined
for loop were not visible to the underlying for/fold/derived
macro after expansion and therefore usages of #:break or #:final
incorrectly resulted in syntax errors (since with the incorrect
expansion, they were seemingly misplaced keywords inside of a let).
With this PR the for/fold/derived examples in the docs now
expand correctly into a form that mirrors the actual
expected syntax of for loops:
(user-defined-for (for-clause ...) body-or-break ... body)
==(now expands more or less into)==>
(for/fold/derived (for-clause ...) body-or-break ... body)
Or in other words, the body of the user defined for loop now correctly
expands directly into the body of for/fold/derived.
The expr/c syntax class, as well as its underlying implementation
function, wrap-expr/c, previously produced misleading error messages.
The main purpose of these tools is to ensure a user-provided expression
conforms to a macro-provided contract. However, contract errors produced
by these forms were consistent with situations where both value and
contract were provided by the same party.
This fixes the discrepancy by changing how these forms assign blame to
emulate contract errors that arise from improper function arguments,
since most expressions provided to macros are semantically similar to
function arguments. All examples within the documentation itself
reflect this use case.
These changes alter the contents of error messages raised by expr/c and
wrap-expr/c, which could theoretically break some test suites, but it’s
extremely unlikely that any non-test code would depend on the precise
wording of contract error messages, and the interface is otherwise
completely backwards-compatible.
fixes#1412
When the second argument to `bytes-set!` is a reference to a
module-level variable that is definitely defined but not a known
constant, then an incorrect reordering was used that would cause
the third argument value to get overwritten before the call.
Closes#1601
The primitive `read` uses a shortcut --- a private "ungetc"
implementation --- that did not count position correctly for
non-ASCII characters.
Closes#1599
The documentation says that it should work on any output port,
although there's special treatment of ports that originate
from `pretty-print` itself.
Closes#1579.
Allow the directory for GUI executables to be specified as different
from console executables. The defaults for those two are different
on Mac OS, and configuring them differently might be useful to
address #1575.
Although there is probably no demand on Windows or Unix for splitting
the console and GUI bin directories, this patch tries to make things
work sensible there. On Windows, there's a corner case where a
launcher that starts GRacket (especially with `-z`) is intended to be
a console executable. The launcher creator can be told that via a
`subsystem` option, but a new `#:console?` argument was needed for
`make-gracket-launcher-path` lets the path selector know.
After some reductions, the new rator advance less the effect
clocks than the original rator. For example in
(equal? x 7) ==> (eq? x 7)
(my-struct? x) ==> #t or #f
The lambdas can be marked as single valued and/or mark preserving.
With this information is possible to remove unnecessary wrapping
like the `values` in
(let ([f (lambda () '(1))])
(display f f)
(values (f)))
or in reductions like
(car (list (f))) ==> (values (f)) ==> (f)
Moreover, this is useful to test that the optimizer has marked
correctly the function f as single valued and mark preserving.
If a module has any sort of complex bindings, such as a definition of
a macor-introduced identifiers, then `module->namespace` and variants
(like `variable-reference->namespace`) need to recreate suitable
bindings. Make sure that the module-path index for recreated bindings
is the run-time one, not the compile-time one.
Closes#1584
To avoid moving expressions that may have a side effect, the optimizer must
recognize that in this position this will cause an error and advance
the virtual clock.
Currently the only primitive that is flagged as SCHEME_PRIM_IS_OMITABLE and
may have multiple return values is `values`.
Thanks to Robby for finding the original version of the test.
we don't want an actual dependency from at-exp-lib to those libraries,
so when they aren't present, don't just crash, but instead fall back
to the defaults passed to the get-info procs
When a hash table or other special value appears immediately on the
right-hand side of `define-values`, it needs to be protected by an
explicit quote when writing to bytecode.
Closes#1580
* byte-regexp? values should not be considered 3D syntax.
* hash? values are now allowed in serialized syntax properties with (template … #:properties (…))
* marshalling properties which were prefab structs called map on the result of struct->vector, changed it to struct->list as the struct "name" is always serializable.
Continuing the saga that includes 8190a7730d and d1ba9fbb6e, it turns
out that a 0-binding clause as the last one isn't so special after
all. A little later in the optimizer, now that we're sometimes moving
an error to the body, we can't assume that the body can be discard
if an error was detected.
