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

The high level is that the predicate with identifier given by build-struct-names should have the same purity/predicate properties of something like string?. As for not, it's just an alias for false?, so it should have the same info again.
-Ian
----- Original Message -----
From: "Sam Tobin-Hochstadt" <samth at ccs.neu.edu>
To: "J. Ian Johnson" <ianj at ccs.neu.edu>
Cc: "dev" <dev at racket-lang.org>, "Neil Toronto" <neil.toronto at gmail.com>
Sent: Tuesday, October 2, 2012 10:02:50 AM GMT -05:00 US/Canada Eastern
Subject: Re: [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