Re: Dylan 2016: Evolving Dylan
Bruce Hoult <[email protected]> Wed, 16 Apr 2014 09:37:01 +1200
| Newsgroups | gmane.comp.lang.dylan.gwydion.devel |
|---|---|
| Message-ID | <CAMU+EkwLRXvy=-dbWc=-TQDMmOL-t5Cgx3UR4fBru6dkfWBq4A@mail.gmail.com> |
--===============1836098048== Content-Type: multipart/alternative; boundary=047d7bea3606ae6bd404f71b99ac --047d7bea3606ae6bd404f71b99ac Content-Type: text/plain; charset=UTF-8 Remember that most of the changes you suggest can be implemented as a library "use dylan-2016" in the existing language, retaining 100% compatibility for "use common-dylan" or "use dylan" programs. In fact at first glance it is only numeric literals that can't as it's a change to the lexer. But that's going to be backward compatible with existing code anyway. 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). WindowsNT and did this (but UCS2) twenty years ago. OS X did this (with UCS4) 15 years ago. Java was somewhere between. Convert to UTF8 or other external encodings on I/O. Programs that handle truly huge amounts of text in memory can convert to and from UTF8 in byte buffers if they want. But simple naive programs can happily use UCS4 strings and not worry about a thing. On Wed, Apr 16, 2014 at 12:00 AM, Bruce Mitchener <[email protected] > 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 (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 > [email protected] > https://lists.opendylan.org/mailman/listinfo/hackers > > --047d7bea3606ae6bd404f71b99ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Remember that most of the changes you suggest can be imple= mented as a library "use dylan-2016" in the existing language, re= taining 100% compatibility for "use common-dylan" or "use dy= lan" programs.<div> <br></div><div>In fact at first glance it is only numeric literals that can= 't as it's a change to the lexer. But that's going to be backwa= rd compatible with existing code anyway.</div><div><br></div><div>I agree t= hat strings should be immutable. However I also believe that you should hav= e constant time random access to elements. Most programs use so little stri= ng 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).</div> <div><br></div><div>WindowsNT and did this (but UCS2) twenty years ago. OS = X did this (with UCS4) 15 years ago. Java was somewhere between.</div><div>= <br></div><div>Convert to UTF8 or other external encodings on I/O. Programs= that handle truly huge amounts of text in memory can convert to and from U= TF8 in byte buffers if they want. But simple naive programs can happily use= UCS4 strings and not worry about a thing.</div> <div><br></div><div><br></div></div><div class=3D"gmail_extra"><br><br><div= class=3D"gmail_quote">On Wed, Apr 16, 2014 at 12:00 AM, Bruce Mitchener <s= pan dir=3D"ltr"><<a href=3D"mailto:[email protected]" target=3D"= _blank">[email protected]</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hello everyone.<div><br></d= iv><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 cons= tant 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 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'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 "atomic" adjective, su= ch as slots and "define atomic variable".</li> <li>Greater immutability for local bindings. We should have a form that com= plements "let x =3D y" to specify that the binding can't be m= odified. One suggestion is "constant x =3D y".</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" target=3D"_blank">http://googoogaga= .github.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 liter= als along the lines of 1_000_000 or 1'000'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'm interested in working on and helping to refi= ne. I'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'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'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><span class= =3D"HOEnZb"><font color=3D"#888888"><div><br></div><div>=C2=A0- Bruce</div>= <div><br> </div></font></span></div> <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> --047d7bea3606ae6bd404f71b99ac-- --===============1836098048== 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 --===============1836098048==--