Because paren-shape is a syntax property that can be lost? I’m still not clear on that bit. @lexi.lambda
more that (a) #%app should really only be modified by the provider of a #lang or module language, since different implementations of #%app do not compose and some languages may use #%app to enforce invariants, and (b) that macro seems a little weird and confusing.
I’d like it if #%app macros composed better
I don’t think they can compose in general, but you might be able to come up with a more restricted protocol that makes arbitrary composition more feasible
I’m comfortable with that
Hmmm. Should this work? Does it now?
(function-call-expression-with-special-app)
(require-special-app)How’s it work with local require?
it doesn’t work any more than (my-macro)
(require something-that-provides-my-macro) does. the fun part is that it will actually get partially expanded to (#%app my-macro), so it doesn’t produce an unbound identifier error… it produces bad syntax.
ah right that makes sense - custom app could introduce requires so partial expansion can’t delay it
actually
would #%expression change that?
the interactions between partial expansion, internal definitions, requires, and provides at the module body context are unclear to me
yes, if you wrapped it in something that deferred expansion of the form, it would produce something different! which is fun.
how do those rules differ between module body contexts and internal definition contexts?
#lang racket
(module quote-app racket
(require syntax/parse/define)
(provide #%app)
(define-simple-macro (#%app form ...)
(quote (form ...))))
(+ 1 2)
(#%expression (+ 1 2))
(require 'quote-app)
(+ 1 2)produces 3
'(+ 1 2)
'(+ 1 2)
and local-require in a (let () body ...) does the same thing?
(… can you local require syntax?)
(looks like it)
re: the differences between module contexts and intdef contexts, they’re mostly similar… but require isn’t allowed in an intdef context. I imagine local-require would do the same thing, though.
you can local-require syntax, just not lazy-require/dynamic-require syntax (for probably obvious reasons)
what happens if you local-require a require transformer? same rules as module context?
right that makes sense
yes, require transformers are essentially just ordinary expanders that require looks up with syntax-local-value.
require transformers aren’t special in any way. only provide transformers are.
right and local-provide is nonsensical so there’s no worries there
would it make sense to have some way of delaying provide expansion in the same way that #%expression delays things, so that provide transformers didn’t need their importing require to be in a particular place?
my guess is “probably not because complicated reasons”
that’s exactly what provide transformers already do. it’s provide pre-transformers that don’t.
provides and provide transformers are expanded as the very last step of module expansion.
and it’s the pre-transformers that can’t for complicated reasons
@asumu Can you make the PPA work for some older Ubuntu versions?
@samth if the older versions are supported on launchpad yeah. I think it should be possible on trusty & precise. Dunno why it didn’t build those actually.
Is there a default suite of tools for Racket performance testing?
@slack1 not yet, but there are loose sketches and notions to work on top of if you’re interested in working on that
@slack1 what type do you need?
Something for easy benchmarking?