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" <sa...@ccs.neu.edu> To: "J. Ian Johnson" <i...@ccs.neu.edu> Cc: "dev" <dev@racket-lang.org>, "Neil Toronto" <neil.toro...@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 <i...@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" <sa...@ccs.neu.edu> > To: "Neil Toronto" <neil.toro...@gmail.com> > Cc: "<dev@racket-lang.org>" <dev@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.toro...@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 > sa...@ccs.neu.edu > _________________________ > Racket Developers list: > http://lists.racket-lang.org/dev -- sam th sa...@ccs.neu.edu _________________________ Racket Developers list: http://lists.racket-lang.org/dev
