Re: Dylan 2016: Evolving Dylan

--===============1505128279==
Content-Type: multipart/alternative; boundary=001a11c20810556cc204f74dbba2

--001a11c20810556cc204f74dbba2
Content-Type: text/plain; charset=UTF-8

I absolutely agree that UTF-16 as used by Windows, C#, Java is wrong. And
that UTF-8 is best in files and  streams and in plain C programs.

What I don't see addressed there (or anywhere I've seen) is how one
recognises a combining character or grapheme cluster.

It seems to me that if such things can be recognised on decoding an input
file/stream then a representation in which a character is the same size as
a pointer allows complex beasts to be implemented as a pointer to a
sequence of code points, interned and shared by all strings using them.
Simpler characters (the vast vast majority) can be stored as their code
point munged in the traditional dynamic language way to distinguish
pointers from immediate values.


On Fri, Apr 18, 2014 at 8:49 PM, Tim Pritlove <[email protected]> wrote:

>
> On 15.04.2014, at 23:37, Bruce Hoult <[email protected]> wrote:
>
> > I agree that strings should be immutable. However I also believe that
> you should have constant time random access to elements. Most programs use
> so little string data (relative to current memory sizes) that I can't see
> any reason not to use UCS4 (or even bigger) as the only element type for
> strings (and certainly StringBuffer/Builder).
> >
>
> I found this enlightening in that context:
>
>   http://www.utf8everywhere.org
>
> Greetings
> Tim
>
> _______________________________________________
> hackers mailing list
> [email protected]
> https://lists.opendylan.org/mailman/listinfo/hackers
>
>

--001a11c20810556cc204f74dbba2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I absolutely agree that UTF-16 as used by Windows, C#, Jav=
a is wrong. And that UTF-8 is best in files and =C2=A0streams and in plain =
C programs.<div><br></div><div>What I don&#39;t see addressed there (or any=
where I&#39;ve seen) is how one recognises a combining character or graphem=
e cluster.</div>
<div><br></div><div>It seems to me that if such things can be recognised on=
 decoding an input file/stream then a representation in which a character i=
s the same size as a pointer allows complex beasts to be implemented as a p=
ointer to a sequence of code points, interned and shared by all strings usi=
ng them. Simpler characters (the vast vast majority) can be stored as their=
 code point munged in the traditional dynamic language way to distinguish p=
ointers from immediate values.</div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Fri,=
 Apr 18, 2014 at 8:49 PM, Tim Pritlove <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:[email protected]" target=3D"_blank">[email protected]</a>&gt;</span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">
<div class=3D""><br>
On 15.04.2014, at 23:37, Bruce Hoult &lt;<a href=3D"mailto:[email protected]"=
>[email protected]</a>&gt; wrote:<br>
<br>
&gt; I agree that strings should be immutable. However I also believe that =
you should have constant time random access to elements. Most programs use =
so little string data (relative to current memory sizes) that I can&#39;t s=
ee any reason not to use UCS4 (or even bigger) as the only element type for=
 strings (and certainly StringBuffer/Builder).<br>

&gt;<br>
<br>
</div>I found this enlightening in that context:<br>
<br>
=C2=A0 <a href=3D"http://www.utf8everywhere.org" target=3D"_blank">http://w=
ww.utf8everywhere.org</a><br>
<br>
Greetings<br>
<span class=3D"HOEnZb"><font color=3D"#888888">Tim<br>
</font></span><br>_______________________________________________<br>
hackers mailing list<br>
<a href=3D"mailto:[email protected]">[email protected]<=
/a><br>
<a href=3D"https://lists.opendylan.org/mailman/listinfo/hackers" target=3D"=
_blank">https://lists.opendylan.org/mailman/listinfo/hackers</a><br>
<br></blockquote></div><br></div>

--001a11c20810556cc204f74dbba2--

--===============1505128279==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
hackers mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/hackers

--===============1505128279==--