[racket-dev] Math library initial commit almost ready; comments on issues welcome

On Tue, Oct 2, 2012 at 9:55 AM, J. Ian Johnson <ianj at ccs.neu.edu> wrote:
> This surprises me, since not and make-struct-type are in '#%kernel, they should have this kind of information baked in, without a purity analysis.

If you're suggesting that the Racket compiler should perform the
purity analysis, then that would be nice, but it would be harder,
since it would require recording information for the output of
`make-struct-type`. Typed Racket has information about structures at a
higher level.

> -Ian
> ----- Original Message -----
> From: "Sam Tobin-Hochstadt" <samth at ccs.neu.edu>
> To: "Neil Toronto" <neil.toronto at gmail.com>
> Cc: "<dev at racket-lang.org>" <dev at racket-lang.org>
> Sent: Tuesday, October 2, 2012 9:44:13 AM GMT -05:00 US/Canada Eastern
> Subject: Re: [racket-dev] Math library initial commit almost ready; comments on issues welcome
>
> On Mon, Oct 1, 2012 at 9:44 PM, Neil Toronto <neil.toronto at gmail.com> wrote:
>> The only bit that bothers me is the (begin (not (flonum-wrapper? x)) ...)
>> stuff left lying around after TR's optimizer eliminates the branches in the
>> expansions of `fw+'. IIRC, they cause futures to sync, but I'm going to
>> believe that they won't always - or will be optimized away - just so I can
>> have a decent solution to the typed macro problem.
>
> This code is left around because TR can't prove that `not` and
> `flonum-wrapper?` are pure functions.  Eventually, TR should include a
> purity analysis that can fix this, but it can't do that now.
>
> The fact that basically all structure operations are future-unsafe is
> a bigger issue.  I talked to James about it at ICFP, but I don't know
> what would be required to improve the situation.
> --
> sam th
> samth at ccs.neu.edu
> _________________________
>   Racket Developers list:
>   http://lists.racket-lang.org/dev



-- 
sam th
samth at ccs.neu.edu