<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 16, 2014 at 12:06 PM, Paul Bone <span dir="ltr"><<a href="mailto:paul@bone.id.au" target="_blank">paul@bone.id.au</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">On Fri, Jul 04, 2014 at 01:36:33PM +1000, Julien Fischer wrote:<br>

> On Fri, Jul 4, 2014 at 11:52 AM, Peter Wang <<a href="mailto:novalazy@gmail.com">novalazy@gmail.com</a>> wrote:<br>
><br>
</div><div class="">> > If users of the non-C backends really want to use embedded null characters<br>
> > > we can provide that facility some other way (on the understanding that<br>
> > > programs that use such a facility won't work with the C backends).<br>
> ><br>
> > I've been thinking about a "binary string" type for arbitrary 8-bit<br>
> > sequences, mainly for non-Unicode strings, or potentially non-Unicode<br>
> > strings.  They might differ from a general byte array type in being<br>
> > immutable and having string-like operations defined on them.  OTOH<br>
> > it would be better not to introduce many similar types.<br>
><br>
><br>
> I've not wanted such a thing myself, but if you think it would be<br>
> sufficiently useful ...<br>
><br>
> We also need a float array type where the elements of the array are always<br>
> unboxed,<br>
> the performance of the normal arrays containing floats (doubles) on 32-bit<br>
> machines<br>
> being particularly bad for some programs (e.g. the nbody benchmark).<br>
><br>
<br>
</div>Some time ago we talked about introducing kinds to Mercury.  </blockquote><div><br></div><div>Mercury already has kinds; it just happens that that the only one supported is '*'.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
And storing in<br>
them the optional width of a type.  For example list(T) would always have<br>
kind *, but this allows us to create multiple array(T)-like types, with<br>
kinds such as *(8bit) *(32bit) *(64bit).  At least that was how I<br>
interpreted the discussion.</blockquote><div><br></div><div>IIRC, the idea was an extension of Haskell's # kind -- see: <a href="http://www.haskell.org/haskellwiki/Unboxed_type">http://www.haskell.org/haskellwiki/Unboxed_type</a>.</div>
<div>We would use the kind system to encode the size of the representation and allow type variables to</div><div>to be annotated with kinds.  So you could for example have the kinds</div><div><br></div><div>   8bit</div><div>
   16bit</div><div>   32bit</div><div>   64bit</div><div><br></div><div>and have declarations like:</div><div><br></div><div>    array8bit(T `with_kind` 8bit)</div><div><br></div><div>where the only allowed instantiations of the type variable T would be types with the kind '8bit'.</div>
<div>None of this has been through through in any great detail.</div><div><br></div><div>So far as float and byte arrays are concerned it's not really relevant since neither of those</div><div>things will be polymorphic anyway.</div>
<div><br></div><div>Cheers,</div><div>Julien.</div><div><br></div></div></div></div>