Henning Thielemann writes:
> As far as I understand, people can still use the Packet type, if they
> prefer case analysis to type distinction.
That's correct, however the cases must be re-written, ie:
case o of
Message ... -> ...
Bundle ... -> ...
would become:
case p of
P_Message (Message ...) -> ...
P_Bundle (Bundle ...) -> ...
Rather than that I'd suggest using 'packet_to_bundle', since Messages
can be properly lifted (ie. by adding an 'immediate' time tag), ie:
let Bundle t m = packet_to_bundle p
in case m of ...
> However, I think the transition would be easier if the names Packet
> and OSC are swapped and you provide smart constructors that emulate
> the behaviour of old Bundle and Message constructor.
There have always been 'message' and 'bundle' constructors (they do some
simple semantics checks) but they now have types:
message :: Address_Pattern -> [Datum] -> Message
bundle :: Time -> [Message] -> Bundle
In most cases I think it will be more likely that a type signature will
shift from OSC to Message since:
case o of
Message "a" ... -> ...
Message "b" ... -> ...
_ -> ...
remains a valid case analysis, but /o/ is of type Message.
> With OSC keeping its semantics, all existing type signatures can
> remain.
Unfortunately I don't think this is likely, because the old OSC and the
new Packet don't really have the same semantics?
I used OSC as the class name because, if anything, it may be possible
that the signature can be 'kept' by replacing:
f :: ... OSC ...
with:
f :: OSC o => ... o ...
> I don't think I have used nested bundles - how would the time stamp
> be interpreted?
The specification says:
When bundles contain other bundles, the OSC Time Tag of the enclosed
bundle must be greater than or equal to the OSC Time Tag of the
enclosing bundle. The atomicity requirement for OSC Messages in the
same OSC Bundle does not apply to OSC Bundles within an OSC Bundle.
However it really doesn't seem to make a lot of sense as there is
nothing gained and it complicates implementations, see 2004 osc_dev
thread ending at:
http://lists.create.ucsb.edu/pipermail/osc_dev/2004-September/000731.html
> But if people need it then you could provide it by a Bundle type with
> type parameter.
For clarity, and if no-one who is already using hosc is actually using
nested Bundles, I'd like to disallow them. I've never come across an
actual use case.
Thanks for the comments, and let me know if I've made any mistakes!
Rohan
___
haskell-art mailing list
haskell-art@lurk.org
http://lists.lurk.org/mailman/listinfo/haskell-art