Re: Dylan 2016: Evolving Dylan
Carl Gay <[email protected]> Tue, 15 Apr 2014 16:38:46 -0400
| Newsgroups | gmane.comp.lang.dylan.gwydion.devel |
|---|---|
| Message-ID | <CALekcH01SNAuLLBQ=eDG=MCRd5s5VASS+rpQHy-K-AxhcuADWw@mail.gmail.com> |
--===============1983161771== Content-Type: multipart/alternative; boundary=001a113430306489ca04f71ac985 --001a113430306489ca04f71ac985 Content-Type: text/plain; charset=UTF-8 I agree with most of what you listed. I think we should be extremely cautious before adding complexity to the type system though. There be dragons there. Of what you listed I would put "constant x = y" at the bottom of the priority list. It just wouldn't improve my life much. A couple other things we might consider... Raw string syntax. For writing code with regular expressions in it, raw strings (e.g. Python's r"..." syntax) is very nice. Dylan could use #r"...". Better multi-line string support. Ditto, plus reasons. On Tue, Apr 15, 2014 at 8: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 > > --001a113430306489ca04f71ac985 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>I agree with most of what you listed. =C2=A0I think w= e should be extremely cautious before adding complexity to the type system = though. =C2=A0There be dragons there.</div><div><br></div><div>Of what you = listed I would put "constant x =3D y" at the bottom of the priori= ty list. =C2=A0It just wouldn't improve my life much.</div> <div><br></div><div>A couple other things we might consider...</div><div><b= r></div><div>Raw string syntax. For writing code with regular expressions i= n it, raw strings (e.g. Python's r"..." syntax) is very nice.= Dylan could use #r"...".<br> </div><div><br></div><div>Better multi-line string support. =C2=A0Ditto, pl= us reasons.</div><div><br></div></div><div class=3D"gmail_extra"><br><br><d= iv class=3D"gmail_quote">On Tue, Apr 15, 2014 at 8:00 AM, Bruce Mitchener <= span 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> --001a113430306489ca04f71ac985-- --===============1983161771== 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 --===============1983161771==--