Actually, I would probably do what Matthew did and coerce to a float with exact->inexact, which would error instead of crashing. [Although a complex value, for example, would get through that and still crash.] But, the idea of having unchecked/unsafe operations is to ONLY call them when the data has already been through some contract check already.
On Sat, Oct 3, 2009 at 12:40 PM, Robby Findler <ro...@eecs.northwestern.edu>wrote: > If the operations in the science collection have the loops inside > them, then it probably wouldn't hurt to add a check at boundary and > you can make them safe, even thought the depend on the unsafe > operations. > > Robby > > On Sat, Oct 3, 2009 at 11:33 AM, Doug Williams > <m.douglas.willi...@gmail.com> wrote: > > And, given your post on the JIT optimizations for unsafe operations, I > can > > see where they are truly unsafe (in terms of possibly crashing instead of > > just erroring.) When I make the changes to use the unsafe-fl/unsafe-fx > > operations, I'll change to using unsafe- as a prefix for the science > > collection operations. > > > > Doug > > > > On Sat, Oct 3, 2009 at 10:33 AM, Matthew Flatt <mfl...@cs.utah.edu> > wrote: > >> > >> At Sun, 6 Sep 2009 18:59:01 -0600, Doug Williams wrote: > >> > Would it be better to call > >> > the operations 'unchecked-<whatever>' instead of 'unsafe-<whatever>'? > >> > Generally, we are calling the function because we know it is safe to > >> > avoid > >> > some constraint check - not because it is unsafe. Just a nit. > >> > >> Despite the distinction between unsafety for performance and unsafety > >> to get at new things, I like having all unsafe operations marked the > >> same way. Also, "unchecked" doesn't sound dangerous enough to me. > >> > >> So, you make a good point, but I'm still in favor of "unsafe". > >> > > > > >
_________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
