[racket] TR - Syntax Entailing Syntax

As a quick follow up.  These days pretty much any of the stuff I do in TR
has all been working flawlessly.  Performance of TR programs at runtime and
the time of static type-checking has improved markedly and simply isn't an
issue any more. DR tools work nicely with TR code.

Current #1 chafing issue these days is in strength of inferencing.  In some
code I end up doing substantial explicit annotation.  And you'd have to put
a gun to my head to get me to use a (Pair .. ..) with car and cdr in any TR
code!

But the overall pace of improvements in TR has been breathtaking.  It's
really something special.



On Mon, Nov 5, 2012 at 4:14 PM, Ray Racine <ray.racine at gmail.com> wrote:

> The current (and only) use-case I have for this is embellishing expansion
> with type annotations to assist with inferencing.  When the inferencing
> improves this use-case vanishes.  The current example at hand is the
> expansion of racket/place's (place ch body ...) - to roughly ->  (lambda
> (ch) body ...) and with `ch' now as Any, where (lambda: ((ch :
> Place-Channel)) body ...) would assist TR.  But I understand and agree with
> avoid conditional code.
>
>
>
>
> On Mon, Nov 5, 2012 at 3:43 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu>wrote:
>
>> On Mon, Nov 5, 2012 at 3:28 PM, Ray Racine <ray.racine at gmail.com> wrote:
>> > On syntax expansion.  Is there a way to determine in the macro whether
>> I'm
>> > expanding in a typed/racket environment vs regular racket.? Say for
>> example
>> > in place.rkt conditionally embellish the syntax templates with
>> additional TR
>> > annotations if the syntax is being expanded in TR vs R.
>>
>> Jay is correct about how to do this, but you shouldn't need to.  In
>> particular, the TR annotations are all ignored by other tools, so it's
>> safe to add them unconditionally.
>>
>> >
>> > Thanks,
>> >
>> >
>> > On Mon, Nov 5, 2012 at 3:14 PM, Ray Racine <ray.racine at gmail.com>
>> wrote:
>> >>
>> >> OK, so it is a little bit of red herring on the unbound identifer
>> >> `place?', i.e. there is an unexported identifier(s) in the expansion of
>> >> `place?' which is the true issue.   For what it's worth is yet another
>> level
>> >> of syntax explosion below `place?'.  But if I get the full explosion
>> graph
>> >> of these these internal procedures situated into base-special-env.rkt
>> it
>> >> will all clear up is what I'm taking away.  A quick glance leads me to
>> >> believe it is less than a dozen, which means doable in finite time.
>> >>
>> >> Time to saddle up and start charging them windmills.
>> >>
>> >> Thanks,
>> >>
>> >>
>> >> On Mon, Nov 5, 2012 at 2:50 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu
>> >
>> >> wrote:
>> >>>
>> >>> On Mon, Nov 5, 2012 at 1:58 PM, Ray Racine <ray.racine at gmail.com>
>> wrote:
>> >>> > Consider the innocuous appearing snippit below from
>> >>> > collects/racket/place/distributed/examples/hello-world.rkt
>> >>> >
>> >>> > #lang typed/racket
>> >>> >
>> >>> > (require racket/place/distributed
>> >>> >          racket/place)
>> >>> >
>> >>> > (provide hello-world)
>> >>> >
>> >>> > (: hello-world (-> Place))
>> >>> > (define (hello-world)
>> >>> >   (place ch
>> >>> >          (printf "hello-world received: ~a\n"
>> >>> >                  (place-channel-get (assert ch place-channel?)))
>> >>> >          (define HW "Hello World")
>> >>> >          (place-channel-put (assert ch place-channel?) (format
>> "~a\n"
>> >>> > HW))
>> >>> >          (printf "hello-world sent: ~a\n" HW)))
>> >>> >
>> >>> >
>> >>> > First issue is:
>> >>> > `place' is syntax entailing 2 closed over procs `place/proc' and
>> >>> > `start-place defined in racket/place.  No prob. I know the secret
>> >>> > incantation.
>> >>> >
>> >>> > So I add a couple of strawman typings base-special-env.rkt and these
>> >>> > immediate undefined identifier errors magically go away.
>> >>> >
>> >>> >  ;; from the expansion of `place'
>> >>> >   [(make-template-identifier 'place/proc 'racket/place)
>> >>> >    (-> -Variable-Reference -Symbol -Symbol (-> -Symbol
>> >>> > -Resolved-Module-Path
>> >>> > -Symbol (-opt -Input-Port) (-opt -Output-Port) (-opt -Output-Port)
>> >>> > -Place)
>> >>> >        (-opt -Input-Port) (-opt -Output-Port) (-opt -Output-Port)
>> >>> >        -Place)]
>> >>> >   [(make-template-identifier 'start-place 'racket/place)
>> >>> >    (-> -Symbol -Resolved-Module-Path -Symbol (-opt -Input-Port)
>> (-opt
>> >>> > -Output-Port) (-opt -Output-Port)
>> >>> >        -Place)]
>> >>> >
>> >>> > The next one in the conga line is an unknown identifier error for
>> >>> > `place?',
>> >>> > which _is_ publicly exported by racket/place.  But `place?' is
>> itself
>> >>> > syntax, so I donno, we have some sort of require-syntax-for-syntax
>> sort
>> >>> > of
>> >>> > thing going on.
>> >>> >
>> >>> > Just for laughs I tossed the below into base-special-env.rkt. and
>> now
>> >>> > hello-world.rkt has errors on duplicate definition of `place?'.
>> >>> >  [(make-template-identifier 'place? 'racket/place)
>> >>> >    (-> Univ -Boolean)]
>> >>>
>> >>> If `place?` is indeed exported by `racket/place`, then the above won't
>> >>> work.  You'll need to give a type to the internal identifier that
>> >>> `place?` expands into.
>> >>>
>> >>> However, looking at the expansion of the hello-world.rkt program, it
>> >>> doesn't seem to contain `place?`.  So I'm confused as to where that's
>> >>> coming from.
>> >>>
>> >>> Finally, the way the `place` form works means that it would be better
>> >>> to give a type annotation to `ch` using the #{ch : Place} form.
>> >>>
>> >>> > Any ideas on how move forward?  The idea was to take a run at TRing
>> the
>> >>> > collects/racket/place/distributed/examples/hello-world.rkt
>> >>> >
>> >>> > Thanks in advance,
>> >>> >
>> >>> > Ray
>> >>> >
>> >>> >
>> >>> > ____________________
>> >>> >   Racket Users list:
>> >>> >   http://lists.racket-lang.org/users
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> sam th
>> >>> samth at ccs.neu.edu
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> sam th
>> samth at ccs.neu.edu
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20121105/b0ec6c01/attachment-0001.html>