Then I suppose the obvious thing to do is move the optimizations up to
the macro level? :)
It's also for debugging, by the way. Having to mentally or manually
substitute bindings to understand fully expanded code annoys me and
wastes time.
Neil ⊥
On 08/25/2012 10:24 AM, Robby Findler wrote:
This is definitely a macro writer bill of rights situation. Too bad
that TR's optimizer cannot take advantage of all these kinds of things
that are already happening in the optimizer one level down.
Robby
On Sat, Aug 25, 2012 at 11:19 AM, Neil Toronto <neil.toro...@gmail.com> wrote:
A lot of macros start by renaming some syntax that's assumed to eventually
represent a runtime value, like the `or' macro does:
(syntax->datum (expand-syntax #'(or #t #f)))
'(let-values (((or-part) '#t)) (if or-part or-part '#f))
But it's not always a good thing, particularly when the output will be
processed by another macro, and parts will be tested using an `identifier=?'
function. For example, my `inline-sort' takes `<' as an argument. So
(inline-sort < a b)
expands to
(let ([lt? <] [temp1 a] [temp2 b])
(if (lt? temp1 temp2) (values temp1 temp2) (values temp2 temp1)))
Well, it did at first. When I discovered that Typed Racket's optimizer would
never detect that `lt?' is actually `<' and replace it with `unsafe-fl<', I
altered the macro to detect when the `<' is an identifier, and not rename it
with a `let'.
I know that I should assert my rights under the Macro Bill. But I like to
program defensively. So what's safe to not rename? I think the following
are:
symbol
number
string
bytes
null
character
regexp
prefab struct key
Also, should I ever have to intern syntax that's one of these kinds of
things?
Neil ⊥
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
