Dylan 2016: Evolving Dylan

--===============0232671931==
Content-Type: multipart/alternative; boundary=089e0102e4f090161004f7138b72

--089e0102e4f090161004f7138b72
Content-Type: text/plain; charset=UTF-8

Hello everyone.

Ada has Ada 95. Ada 2005. Ada 2012. Algol had Algol 60 and Algol 68. C has
C99 and C11. C++ has C++03, C++11 and C++14. Fortran has Fortran 77,
Fortran 90, Fortran 95, Fortran 2003, Fortran 2008. Haskell has seen
constant revision. Java has as well.

No language is born perfect and we have our DEP process to deal with this.

I'd like to consider a period where we look at larger changes presented as
a larger evolution of Dylan.

My current thoughts on things that I'd like to see proposed and implemented:


   - Immutable strings: Strings become an immutable object. Do we need some
   sort of string builder API to support existing use cases? How often do we
   actually modify strings inside of Open Dylan?
   - Unicode: A single string type with UTF8 encoding internally. A byte
   vector is used instead for binary data and encoders handle converting
   between the UTF8 string and the byte vector. Immutable strings can help
   simplify this work.
   - Atomic operations. We should specify atomic operations similar to
   C++11 and C11. Atomic operations should either be available on anything of
   the right type or on bindings that have an "atomic" adjective, such as
   slots and "define atomic variable".
   - Greater immutability for local bindings. We should have a form that
   complements "let x = y" to specify that the binding can't be modified. One
   suggestion is "constant x = y".
   - More immutable types or better implementations of immutable types. We
   can learn a lot from Clojure and other languages to provide better
   implementations of core types that are immutable.
   - Improvements to the numeric tower. This needs some serious thought.
   Lacking an easy to use 64 bit integer type is pretty painful.
   - Improvements to the type system. There are ideas that can be borrowed
   from the work that Hannes did. There is also a thesis by James Knight (
   http://googoogaga.github.io/james-thesis.pdf) on adding parameterized
   types to Goo that may be worth examining.
   - An improvement to numeric literals. Some languages permit numeric
   literals along the lines of 1_000_000 or 1'000'000. This is a nice
   readability improvement.


All of the above proposals are things that I'm interested in working on and
helping to refine. I'm sure there are other things as well that would go
well in a Dylan 2016 effort.

The goal is to have enough stuff with enough meat that we're looking at a
substantial improvement on the language and something that can be talked
about as an evolution in Dylan to make it clear that we're advancing beyond
a language from the past.

What do you all think? Are there other things that people are interested in
proposing and helping to implement?

 - Bruce

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

<div dir=3D"ltr">Hello everyone.<div><br></div><div>Ada has Ada 95. Ada 200=
5. Ada 2012. Algol had Algol 60 and Algol 68. C has C99 and C11. C++ has C+=
+03, C++11 and C++14. Fortran has Fortran 77, Fortran 90, Fortran 95, Fortr=
an 2003, Fortran 2008. Haskell has seen constant revision. Java has as well=
.</div>
<div><br></div><div>No language is born perfect and we have our DEP process=
 to deal with this.</div><div><br></div><div>I&#39;d like to consider a per=
iod where we look at larger changes presented as a larger evolution of Dyla=
n.</div>
<div><br></div><div>My current thoughts on things that I&#39;d like to see =
proposed and implemented:</div><div><br></div><div><ul><li>Immutable string=
s: Strings become an immutable object. Do we need some sort of string build=
er API to support existing use cases? How often do we actually modify strin=
gs inside of Open Dylan?<br>
</li><li>Unicode: A single string type with UTF8 encoding internally. A byt=
e vector is used instead for binary data and encoders handle converting bet=
ween the UTF8 string and the byte vector. Immutable strings can help simpli=
fy this work.<br>
</li><li>Atomic operations. We should specify atomic operations similar to =
C++11 and C11. Atomic operations should either be available on anything of =
the right type or on bindings that have an &quot;atomic&quot; adjective, su=
ch as slots and &quot;define atomic variable&quot;.</li>
<li>Greater immutability for local bindings. We should have a form that com=
plements &quot;let x =3D y&quot; to specify that the binding can&#39;t be m=
odified. One suggestion is &quot;constant x =3D y&quot;.</li><li>More immut=
able types or better implementations of immutable types. We can learn a lot=
 from Clojure and other languages to provide better implementations of core=
 types that are immutable.</li>
<li>Improvements to the numeric tower. This needs some serious thought. Lac=
king an easy to use 64 bit integer type is pretty painful.</li><li>Improvem=
ents to the type system. There are ideas that can be borrowed from the work=
 that Hannes did. There is also a thesis by James Knight (<a href=3D"http:/=
/googoogaga.github.io/james-thesis.pdf">http://googoogaga.github.io/james-t=
hesis.pdf</a>) on adding parameterized types to Goo that may be worth exami=
ning.</li>
<li>An improvement to numeric literals. Some languages permit numeric liter=
als along the lines of 1_000_000 or 1&#39;000&#39;000. This is a nice reada=
bility improvement.</li></ul><div><br></div></div><div>All of the above pro=
posals are things that I&#39;m interested in working on and helping to refi=
ne. I&#39;m sure there are other things as well that would go well in a Dyl=
an 2016 effort.</div>
<div><br></div><div>The goal is to have enough stuff with enough meat that =
we&#39;re looking at a substantial improvement on the language and somethin=
g that can be talked about as an evolution in Dylan to make it clear that w=
e&#39;re advancing beyond a language from the past.</div>
<div><br></div><div>What do you all think? Are there other things that peop=
le are interested in proposing and helping to implement?</div><div><br></di=
v><div>=C2=A0- Bruce</div><div><br></div></div>

--089e0102e4f090161004f7138b72--

--===============0232671931==
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

--===============0232671931==--