> > 440.0 is still an exact integer > Hunh? What Scheme is this? The Scheme spec says > "It [a numerical constant] is inexact if it contains a decimal point..."
Yes, my mistake, I meant to say that 440.0 is still an integer. Welcome to MzScheme version 205.8, Copyright (c) 1995-2003 PLT > (integer? 440.0) #t > It also says "inexactness is a contagious property of a number". Welcome to MzScheme version 205.8, Copyright (c) 1995-2003 PLT > (exact? (* 0 440.0)) #t This is explicitly mentioned in R5RS, and exact zeroes turn up all the time in controller input streams, from midi controllers for example. > In any case, type checks are trivial. Well yes, it is the the type check that determines the OSC encoding, but without explicit type tagging there is no way of knowing if 1.0 should be encoded as a single or double precision value? Or in fact if it is a 'proper' integer that has been contaminated somewhere along its journey? My actual argument regards all this is that OSC is a good thing to have in user space, and that in user space 440 should be a valid frequency input, and 1.0 a valid index input. I think it is an amazing contribution of SuperCollider that composers find the language and the environment approachable. The 'scsynth' OSC implementation is part of this contribution, we should live up to it's example. Regards, Rohan An aside: I bought up scheme as a counterexample to Lua to show that just because a language has a lot of numerical types does not help with getting OSC encoding `correct'. (integer? 1.0) => #t (integer? 1) => #t (exact? 1.0) => #f (exact? 1) => #t (= 1 1.0) => #t (eq? 1 1) => #t (eq? 1.0 1.0) => #f (eq? 1 1.0) => #f These questions are interesting, and of course not peculiar to lisps, but implementors should bend over backwards trying to make sure that composers don't *need* to ponder the mysteries of inexact integers to tune an instrument.
