One could, concievably, still do that without boxing/unblocking by passing "wide enough" arguments. And it does seem like TR could help with that, but IIUC the untyped portion of the compiler needs significant work to support that before TR's knowledge of the program would help (But doing a better job with structs is, iiuc, a long standing "something could be much better here" type of thing.) On Saturday, August 18, 2012, Matthias Felleisen wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> But don't you need the 'tag' from the struct to distinguish .4 in p from .4 in 1-p? They may be the same number but they denote distinct ideas. -- Matthias ' On Aug 18, 2012, at 2:40 PM, Neil Toronto wrote: > Is TR's optimizer eventually going to unbox structs in the same way it unboxes rectangular flonums? > > I have a design choice right now: how to represent probabilities. Floats are good because of their speed, but because of floating-point limitations, *four different representations* are typically used. (For the curious: p, 1-p, log(p), and log(1-p).) I'd like to make functions that accept any one of these representations, denoted by this type: > > (define-type Probability > (U probability 1-probability log-probability log-1-probability)) > > The types are simply struct types that tag Float. > > Of course, manually boxing flonums ruins any chance of the compiler emitting code that keeps the flonums unboxed. If TR's optimizer unboxed structs, though, everything could be speedy. > > FWIW, by "eventually," I mean "within the next n years", where "n" is a smallish number. > > Neil ⊥ > _________________________ > Racket Developers list: > <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a> </blockquote>