Building racket 6.1, from racket-6.1-src.tgz, the debian build
calls make install twice,
the first time with PLT_EXTRA="--no-docs --no-zo", and the second time
with PLT_EXTRA="--no-launcher --no-install --no-post-install". This
second (main) call is crashing after some recent change in Debian
unst
A tiny note for Google... the source location information isn't part
of hygiene, it's like an orthogonal axis.
When a form like (syntax ) is used, it creates a new piece of
syntax where the origin is that particular file/line. When you use
syntax/loc, you create a new syntax object but you cop
That makes sense.
It turns out I need replace-context *and* quasisyntax/loc (and back to
absolute paths):
(define-require-syntax (gamelib stx)
(syntax-case stx ()
((_ name)
(replace-context stx (quasisyntax/loc stx (file #,(format
"~a/some/path/~a.dc" (current-directory) (syntax->datum #'name
Many of the changes are documentation, but there are some TR changes
that we may go back on; it's not clear yet.
Were there other changes that jumped out at you as worth double checking?
And yes, once Ryan announces a new build built, re-running tests is
always welcome!
Robby
On Wed, Oct 22, 20
If you have (require X) then the identifiers imported from X get the
lexical context of X. (Slight note: In something like (rename-in X [A
B]) then they get the context of A.)
If a macro made X, then the lexical context is equivalent to #f,
because every macro application gets a fresh lexical cont
So, yeah... that appears to work!
I use replace-context to give the resulting require syntax output the
context of the original argument. Here's what the change looks like, with
my old way commented (unrelated note: path is actually relative):
(define-require-syntax (gamelib stx)
(syntax-case s
Is anyone else nervous about the number of not-obviously-trivial changes
we're merging to the 6.1.1 release after the test bundles are out? I for
one wouldn't mind re-running my tests before the release.
John
_
Racket Developers list:
http://lists.racket-lang.org/dev
On Wed, Oct 22, 2014 at 10:20 AM, Matthew Flatt wrote:
> I agree that this is broken, but I'd like to put it on hold, because
> its another basic problem with the way the current macro expander
> represents lexical context.
>
> Adjusting the context of the expressions changes the result, because
>
At Wed, 22 Oct 2014 10:25:51 -0400, Sam Tobin-Hochstadt wrote:
> On Wed, Oct 22, 2014 at 10:20 AM, Matthew Flatt wrote:
> > Expansions that produce this bad `identifier-binding` result probably
> > happen up all the time. They don't bother the bytecode compiler,
> > because the compiler uses `free
I agree that this is broken, but I'd like to put it on hold, because
its another basic problem with the way the current macro expander
represents lexical context.
Adjusting the context of the expressions changes the result, because
its the macro-introduced nature of the `main` definition that trig
#lang racket/base
;; This module has a binding and an effect, so we can see that it was
;; required even when we can't get to it.
(module example racket/base
(define x 1)
(printf "I'm running here\n")
(provide x))
;; If you comment this in, you'll see the "normal" way to require it.
#;
(le
11 matches
Mail list logo
