[m-rev.] for post-commit review: fix string.from_char_list in C# and Java grades
Julien Fischer
jfischer at opturion.com
Wed Jul 16 14:20:24 AEST 2014
On Wed, Jul 16, 2014 at 12:06 PM, Paul Bone <paul at bone.id.au> wrote:
> On Fri, Jul 04, 2014 at 01:36:33PM +1000, Julien Fischer wrote:
> > On Fri, Jul 4, 2014 at 11:52 AM, Peter Wang <novalazy at gmail.com> wrote:
> >
> > > If users of the non-C backends really want to use embedded null
> characters
> > > > we can provide that facility some other way (on the understanding
> that
> > > > programs that use such a facility won't work with the C backends).
> > >
> > > I've been thinking about a "binary string" type for arbitrary 8-bit
> > > sequences, mainly for non-Unicode strings, or potentially non-Unicode
> > > strings. They might differ from a general byte array type in being
> > > immutable and having string-like operations defined on them. OTOH
> > > it would be better not to introduce many similar types.
> >
> >
> > I've not wanted such a thing myself, but if you think it would be
> > sufficiently useful ...
> >
> > We also need a float array type where the elements of the array are
> always
> > unboxed,
> > the performance of the normal arrays containing floats (doubles) on
> 32-bit
> > machines
> > being particularly bad for some programs (e.g. the nbody benchmark).
> >
>
> Some time ago we talked about introducing kinds to Mercury.
Mercury already has kinds; it just happens that that the only one supported
is '*'.
> And storing in
> them the optional width of a type. For example list(T) would always have
> kind *, but this allows us to create multiple array(T)-like types, with
> kinds such as *(8bit) *(32bit) *(64bit). At least that was how I
> interpreted the discussion.
IIRC, the idea was an extension of Haskell's # kind -- see:
http://www.haskell.org/haskellwiki/Unboxed_type.
We would use the kind system to encode the size of the representation and
allow type variables to
to be annotated with kinds. So you could for example have the kinds
8bit
16bit
32bit
64bit
and have declarations like:
array8bit(T `with_kind` 8bit)
where the only allowed instantiations of the type variable T would be types
with the kind '8bit'.
None of this has been through through in any great detail.
So far as float and byte arrays are concerned it's not really relevant
since neither of those
things will be polymorphic anyway.
Cheers,
Julien.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20140716/383fb3c9/attachment.html>
More information about the reviews
mailing list