Re: Dylan 2016: Evolving Dylan

This is a multi-part message in MIME format.

--===============2125566566==
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="_----------=_1397571461234641";
 charset="utf-8"

This is a multi-part message in MIME format.

--_----------=_1397571461234641
Content-Transfer-Encoding: 7bit
Content-Type: text/plain

The defining thing that is making a difference to me in my day-to-day
work is all about thread safety, and the thing that makes a difference
with thread safety is immutability.



The more things that can become immutable by default in Dylan, the
better.  Immutable strings and immutable types is a good first step,
but immutable/functional containers are where the real magic happens,
because they make directly sharing data between threads
safe--incredibly important for high-performance code.  Even something
as simple as .NET's Immutable Collections stack
([1]http://msdn.microsoft.com/en-us/library/dn385366(v=vs.110).aspx)
would be really useful.



On Tue, Apr 15, 2014, at 08:00 AM, Bruce Mitchener wrote:

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 ([2]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

_______________________________________________

hackers mailing list

[3][email protected]

[4]https://lists.opendylan.org/mailman/listinfo/hackers

References

1. http://msdn.microsoft.com/en-us/library/dn385366(v=vs.110).aspx
2. http://googoogaga.github.io/james-thesis.pdf
3. mailto:[email protected]
4. https://lists.opendylan.org/mailman/listinfo/hackers

--_----------=_1397571461234641
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html

<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>The defining thing that is making a difference to me in my day-t=
o-day work is all about thread safety, and the thing that makes a differenc=
e with thread safety is immutability.<br></div>
<div>&nbsp;</div>
<div>The more things that can become immutable by default in Dylan, the bet=
ter. &nbsp;Immutable strings and immutable types is a good first step, but =
immutable/functional containers are where the real magic happens, because t=
hey make directly sharing data between threads safe--incredibly important f=
or high-performance code. &nbsp;Even something as simple as .NET's Immutabl=
e Collections stack (<a href=3D"http://msdn.microsoft.com/en-us/library/dn3=
85366(v=3Dvs.110).aspx">http://msdn.microsoft.com/en-us/library/dn385366(v=
=3Dvs.110).aspx</a>) would be really useful.<br></div>
<div>&nbsp;</div>
<div>On Tue, Apr 15, 2014, at 08:00 AM, Bruce Mitchener wrote:<br></div>
<blockquote type=3D"cite"><div dir=3D"ltr">Hello everyone.<div>&nbsp;</div>
<div>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, F=
ortran 90, Fortran 95, Fortran 2003, Fortran 2008. Haskell has seen constan=
t revision. Java has as well.<br></div>
<div>&nbsp;</div>
<div>No language is born perfect and we have our DEP process to deal with t=
his.<br></div>
<div>&nbsp;</div>
<div>I'd like to consider a period where we look at larger changes presente=
d as a larger evolution of Dylan.<br></div>
<div>&nbsp;</div>
<div>My current thoughts on things that I'd like to see proposed and implem=
ented:<br></div>
<div>&nbsp;</div>
<div><ul><li>Immutable strings: Strings become an immutable object. Do we n=
eed some sort of string builder API to support existing use cases? How ofte=
n do we actually modify strings inside of Open Dylan?
<br></li><li>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 si=
mplify 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 "atomic" adjective, such as =
slots and "define atomic variable".<br></li><li>Greater immutability for lo=
cal bindings. We should have a form that complements "let x =3D y" to speci=
fy that the binding can't be modified. One suggestion is "constant x =3D y"=
.<br></li><li>More immutable types or better implementations of immutable t=
ypes. We can learn a lot from Clojure and other languages to provide better=
 implementations of core types that are immutable.<br></li><li>Improvements=
 to the numeric tower. This needs some serious thought. Lacking an easy to =
use 64 bit integer type is pretty painful.<br></li><li>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 (<a href=3D"http://googoogaga.=
github.io/james-thesis.pdf">http://googoogaga.github.io/james-thesis.pdf</a=
>) on adding parameterized types to Goo that may be worth examining.<br></l=
i><li>An improvement to numeric literals. Some languages permit numeric lit=
erals along the lines of 1_000_000 or 1'000'000. This is a nice readability=
 improvement.<br></li></ul><div>&nbsp;</div>
</div>
<div>All of the above proposals are things that I'm interested in working o=
n and helping to refine. I'm sure there are other things as well that would=
 go well in a Dylan 2016 effort.<br></div>
<div>&nbsp;</div>
<div>The goal is to have enough stuff with enough meat that we're looking a=
t a substantial improvement on the language and something that can be talke=
d about as an evolution in Dylan to make it clear that we're advancing beyo=
nd a language from the past.<br></div>
<div>&nbsp;</div>
<div>What do you all think? Are there other things that people are interest=
ed in proposing and helping to implement?<br></div>
<div>&nbsp;</div>
<div>&nbsp;- Bruce<br></div>
<div>&nbsp;</div>
</div>
<div><u>_______________________________________________</u><br></div>
<div>hackers mailing list<br></div>
<div><a href=3D"mailto:[email protected]">[email protected]=
.org</a><br></div>
<div><a href=3D"https://lists.opendylan.org/mailman/listinfo/hackers">https=
://lists.opendylan.org/mailman/listinfo/hackers</a><br></div>
</blockquote></body>
</html>

--_----------=_1397571461234641--

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

--===============2125566566==--