Re: Dylan 2016: Evolving Dylan

--===============0526776672==
Content-type: multipart/alternative;
 boundary="Boundary_(ID_lwhhViA3V42zc493c8s7pw)"


--Boundary_(ID_lwhhViA3V42zc493c8s7pw)
Content-type: text/plain; charset=windows-1252
Content-transfer-encoding: quoted-printable

Yeah, it is past time we did some of this stuff.


On Apr 15, 2014, at 5:00 AM, Bruce Mitchener <[email protected]> =
wrote:

> Hello everyone.
>=20
> 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.
>=20
> No language is born perfect and we have our DEP process to deal with =
this.
>=20
> I'd like to consider a period where we look at larger changes =
presented as a larger evolution of Dylan.
>=20
> My current thoughts on things that I'd like to see proposed and =
implemented:
>=20
> 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?
Let=92s get some metrics on this. As far as implementations go, Java and =
C# have StringBuilder classes that are just a resizable vector of =
characters, and Objective C=92s NSMutableString seems to be the same =
(with different subclasses for internal encodings). I don=92t see any =
fancy gap arrays or anything like that. Using that as our model, we can =
implement our mutable string class (if we do one) as a thin wrapper =
around a <stretchy-vector>.

> 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=94.
There are a number of atomic operations: read, write, test-and-set, =
compare-and-exchange, etc. By declaring a variable as =93atomic=94, or =
declaring a variable specialized as something like C++=92s =93atomic<T>=94=
, the compiler can automatically make read and write operations (or, in =
Dylan terms, read and rebind operations) atomic. However, you=92d still =
need functions for the other atomic operations. I would rather be =
consistent and only provide atomicity via atomic function calls, =
avoiding all implicit atomicity.

As far as memory ordering goes, C and C++ define several levels of =
increasingly relaxed memory ordering opportunities, but I think we =
shouldn=92t over-optimize here. I am fine with enforcing sequential =
consistency like Java does. We can always add more relaxed ordering =
options as optional arguments to the atomic functions later.

> Greater immutability for local bindings. We should have a form that =
complements "let x =3D y" to specify that the binding can't be modified. =
One suggestion is "constant x =3D y=94.
I like =93let constant x =3D y=94 or =93let const x =3D y=94 for this. =
It is still a =93let=94, just one with an additional protection =
preventing the bindings from being rebound.

> 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.
I=92ve thought about this while daydreaming about a new Dylan =
implementation.

For the case of integers, I think there is only one real option:

We should define boxed integer types as subclasses or limited subtypes =
of <integer>: <int32>, <uint32>, etc. We should also have <int28> and =
<int62> for your standard unboxed integers. The problem here is that a =
function defined on <integer> needs to accommodate the boxed and unboxed =
case, possibly resulting in additional dispatch. But this is already =
true to an extent. Functions defined on <integer> already need (or =
should have) slow-path code to accommodate bounds-checking against =
limited integers.

An alternative would have <int32>, etc., as separate subclasses of =
<rational> disjoint from <integer>. This is mostly what we have now, =
with <machine-word>, except that if we put it under <rational>, we at =
least have the option of doing arithmetic. It really isn=92t much of an =
improvement over the current situation, since they still wouldn=92t be =
<integer>, and no one specializes on <rational>.

It would be totally sweet, and also really cool, to have <integer> be an =
abstract integer type thing and have operations on <integer> =
automatically promote an overflow result to a larger type such as =
<int64> or <big-integer>. Unfortunately, this would wreak havoc with =
type inferencing and I think we have to leave that feature out.

For the case of floating point numbers and arithmetic, we do need to =
think more about NaN and +/-Inf and things like that.

> 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.
Perhaps it would be possible to support spaces for this. If not, I vote =
for 1=92000=92000. You should be able to put the separator anywhere in =
the literal, not just groups of 3, because different locales use =
different groupings. According to Wikipedia, East Asian countries group =
by 4, and the Indian system groups start at the third digit but every =
two digits thereafter (e.g. 15,00,000), and some locales group =
fractional digits and others don=92t.


>=20
> 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.
>=20
> 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.
>=20
> What do you all think? Are there other things that people are =
interested in proposing and helping to implement?
>=20
>  - Bruce
>=20
> _______________________________________________
> hackers mailing list
> [email protected]
> https://lists.opendylan.org/mailman/listinfo/hackers


--Boundary_(ID_lwhhViA3V42zc493c8s7pw)
Content-type: text/html; charset=windows-1252
Content-transfer-encoding: quoted-printable

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><div>Yeah, it is past time we did some of this =
stuff.</div><div><br></div><br><div><div>On Apr 15, 2014, at 5:00 AM, =
Bruce Mitchener &lt;<a =
href=3D"mailto:[email protected]">[email protected]</a>&gt=
; wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div dir=3D"ltr">Hello everyone.<div><br></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, =
Fortran 90, Fortran 95, Fortran 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'd like to consider =
a period where we look at larger changes presented as a larger evolution =
of Dylan.</div>
<div><br></div><div>My current thoughts on things that I'd like to see =
proposed and implemented:</div><div><br></div><div><ul><li>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?<br></li></ul></div></div></blockquote><div>Let=92s get some =
metrics on this. As far as implementations go, Java and C# have =
StringBuilder classes that are just a resizable vector of characters, =
and Objective C=92s NSMutableString seems to be the same (with different =
subclasses for internal encodings). I don=92t see any fancy gap arrays =
or anything like that. Using that as our model, we can implement our =
mutable string class (if we do one) as a thin wrapper around a =
&lt;stretchy-vector&gt;.</div><div><br></div><blockquote =
type=3D"cite"><div dir=3D"ltr"><div><ul><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 simplify this =
work.</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=94.</li></ul></div></div></blockquote><div>There are a number =
of atomic operations: read, write, test-and-set, compare-and-exchange, =
etc. By declaring a variable as =93atomic=94, or declaring a variable =
specialized as something like C++=92s =93atomic&lt;T&gt;=94, the =
compiler can automatically make read and write operations (or, in Dylan =
terms, read and rebind operations) atomic. However, you=92d still need =
functions for the other atomic operations. I would rather be consistent =
and only provide atomicity via atomic function calls, avoiding all =
implicit atomicity.</div><div><br></div><div>As far as memory ordering =
goes, C and C++ define several levels of increasingly relaxed memory =
ordering opportunities, but I think we shouldn=92t over-optimize here. I =
am fine with enforcing sequential consistency like Java does. We can =
always add more relaxed ordering options as optional arguments to the =
atomic functions later.</div><br><blockquote type=3D"cite"><div =
dir=3D"ltr"><div><ul>
<li>Greater immutability for local bindings. We should have a form that =
complements "let x =3D y" to specify that the binding can't be modified. =
One suggestion is "constant x =3D =
y=94.</li></ul></div></div></blockquote><div>I like =93let constant x =3D =
y=94 or =93let const x =3D y=94 for this. It is still a =93let=94, just =
one with an additional protection preventing the bindings from being =
rebound.</div><br><blockquote type=3D"cite"><div =
dir=3D"ltr"><div><ul><li>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.</li></ul></div></div></blockquote></div><div><blockquote =
type=3D"cite"><div dir=3D"ltr"><div><ul><li>Improvements to the numeric =
tower. This needs some serious thought. Lacking an easy to use 64 bit =
integer type is pretty =
painful.</li></ul></div></div></blockquote><div>I=92ve thought about =
this while daydreaming about a new Dylan =
implementation.</div><div><br></div><div>For the case of integers, I =
think there is only one real option:</div><div><br></div><div>We should =
define boxed integer types as subclasses or limited subtypes of =
&lt;integer&gt;: &lt;int32&gt;, &lt;uint32&gt;, etc. We should also have =
&lt;int28&gt; and &lt;int62&gt; for your standard unboxed integers. The =
problem here is that a function defined on &lt;integer&gt; needs to =
accommodate the boxed and unboxed case, possibly resulting in additional =
dispatch. But this is already true to an extent. Functions defined on =
&lt;integer&gt; already need (or should have) slow-path code to =
accommodate bounds-checking against limited =
integers.</div><div><br></div><div>An alternative would have =
&lt;int32&gt;, etc., as separate subclasses of &lt;rational&gt; disjoint =
from &lt;integer&gt;. This is mostly what we have now, with =
&lt;machine-word&gt;, except that if we put it under &lt;rational&gt;, =
we at least have the option of doing arithmetic. It really isn=92t much =
of an improvement over the current situation, since they still wouldn=92t =
be &lt;integer&gt;, and no one specializes on =
&lt;rational&gt;.</div><div><br></div><div>It would be totally sweet, =
and also really cool, to have &lt;integer&gt; be an abstract integer =
type thing and have operations on &lt;integer&gt; automatically promote =
an overflow result to a larger type such as &lt;int64&gt; or =
&lt;big-integer&gt;. Unfortunately, this would wreak havoc with type =
inferencing and I think we have to leave that feature =
out.</div><div><br></div><div>For the case of floating point numbers and =
arithmetic, we do need to think more about NaN and +/-Inf and things =
like that.</div><br><blockquote type=3D"cite"><div =
dir=3D"ltr"><div><ul><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.gi=
thub.io/james-thesis.pdf</a>) on adding parameterized types to Goo that =
may be worth examining.</li>
<li>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.</li></ul></div></div></blockquote><div>Perhaps =
it would be possible to support spaces for this. If not, I vote for =
1=92000=92000. You should be able to put the separator anywhere in the =
literal, not just groups of 3, because different locales use different =
groupings. According to Wikipedia, East Asian countries group by 4, and =
the Indian system groups start at the third digit but every two digits =
thereafter (e.g. 15,00,000), and some locales group fractional digits =
and others don=92t.</div><div><br></div><br><blockquote type=3D"cite"><div=
 dir=3D"ltr"><div><div><br></div></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>What do you all think? Are there other things that =
people are interested in proposing and helping to =
implement?</div><div><br></div><div>&nbsp;- =
Bruce</div><div><br></div></div>
_______________________________________________<br>hackers mailing =
list<br><a =
href=3D"mailto:[email protected]">[email protected]</a=
><br>https://lists.opendylan.org/mailman/listinfo/hackers<br></blockquote>=
</div><br></body></html>=

--Boundary_(ID_lwhhViA3V42zc493c8s7pw)--

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

--===============0526776672==--