<br><br><div class="gmail_quote">On Thu, May 14, 2009 at 8:54 PM, Don Stewart <span dir="ltr">&lt;<a href="mailto:dons@galois.com">dons@galois.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">&gt; I&#39;m speaking specifically of the encode/decode functions.  I have no idea how<br>
&gt; they&#39;re implemented.<br>
&gt;<br>
&gt; Are you saying that encode is doing something really simple and the default<br>
&gt; encodings for things just happen to be big endian?  If so, then I understand<br>
&gt; the pain.... but it still means I have to roll my own :-)  I guess if one must<br>
&gt; choose, big endian kind of makes sense, except that the whole world is little<br>
&gt; endian now, except for networks :-)  (No one *really* cares about anything but<br>
&gt; x86 anyway these days right?)<br>
<br>
</div>Oh, &#39;encode&#39; has type:<br>
<br>
    encode :: Binary a =&gt; a -&gt; ByteString<br>
<br>
it just encodes with the default instances, which are all network order:<br>
<br>
    <a href="http://en.wikipedia.org/wiki/Endianness#Endianness_in_networking" target="_blank">http://en.wikipedia.org/wiki/Endianness#Endianness_in_networking</a><br></blockquote><div><br></div><div>Yeah I understand that Big Endian == Network Byte Order... which would be true, if I wasn&#39;t talking about Plan 9&#39;s 9P protocol which specifies little endian bytes on the wire (as far as I can tell anyway from the man page).</div>
<div><br></div><div>Dave</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
-- Don<br>
</font></blockquote></div><br>