[racket-dev] syntax-property guards? (was: Re: The Stepper strikes again)

10 minutes ago, Sam Tobin-Hochstadt wrote:
> 
> Is this just an argument about how to name these syntax properties?

Yes -- and that leads to more than "just the name".


> If so, I'm happy with whatever you think I should name it.  That
> doesn't seem to get us anywhere on the other questions, though.

Sure it does.  Here's an attempt to clarify how:

Currently, there's a weird `typechecker:called-in-tail-position' name
that means nothing to anyone other than the people who know what the
`typechecker' is.  If it's changed from that into just
`called-in-tail-position', then you get a bunch of good results:

* Above all, it means that it's now an extension for (macros in) the
  core language -- it's properly documented in a way that makes it
  possible for me to use it as both a client of such macros and as a
  writer of them.

* This would be documented in a section of the core reference that
  lists all kinds of properties that I should be aware of when I'm
  writing macros.  The `disappeared-use' property should be documented
  there too (I see that it's not documented at all now), as well as
  the stepper property that Stephen added would be there too.  The
  `inferred-name' property is part of the same thing.  (Obviously,
  adding such things should be minimized, so that "simple" macros
  don't need to deal with any of them, and it's only certain kinds of
  macros that don't get the "it just work" property.)

* As a client, I can now write additional tools that can tell when
  something is intended only for tail calls.  I can imagine a bunch of
  uses for such a thing.  The benefit here is obvious.

* As an author, it's clear now that if I write a macro that binds a
  function that is called only in tail position, then I should signal
  that intention via specifying this property.  The benefit here is
  that TR can now work better since there are additional macros that
  it will know how to deal with.

But it can then go beyond those benefits:

* At the level of core design, you've essentially identified a feature
  that you need to use in TR, and that you cannot get without explicit
  marking done by macro authors.  A weak point in this is that you're
  allowing random marks made by random macros -- my guess is that this
  makes for an easy way to break TR.

* This means that there's benefit for having this done in a reliable
  way, which means that it's a good argument for the core language to
  make that information available automatically, in a way that cannot
  be faked by random macros.  Either that, or if it's not possible,
  have the core verify it in some way -- like throwing a syntax error
  when such expressions are used in non-tail positions.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!