Re: Dylan 2016: Evolving Dylan
Robert Roland <[email protected]> Tue, 15 Apr 2014 16:44:32 +0000
| Newsgroups | gmane.comp.lang.dylan.gwydion.devel |
|---|---|
| Message-ID | <1e2e63ceccea4d9384fedc71d077016b@SN2PR07MB080.namprd07.prod.outlook.com> |
--===============0157131865== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_1e2e63ceccea4d9384fedc71d077016bSN2PR07MB080namprd07pro_" --_000_1e2e63ceccea4d9384fedc71d077016bSN2PR07MB080namprd07pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'll definitely agree with the immutability idea. I like the "constant x = =3D y" idea, or, "let constant x =3D y" - I just don't want to end up in a = situation with Scala, val/var, where I can never seem to remember which is = which. Java's java.util.concurrent offers some really powerful collection types, l= ike BlockingQueues, that would be really worth investigating. ________________________________ From: [email protected] <[email protected].= org> on behalf of Benjamin Pollack <[email protected]> Sent: Tuesday, April 15, 2014 7:17 AM To: [email protected] Subject: Re: [hackers] Dylan 2016: Evolving Dylan 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 thre= ad 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 d= irectly sharing data between threads safe--incredibly important for high-pe= rformance code. Even something as simple as .NET's Immutable Collections s= tack (http://msdn.microsoft.com/en-us/library/dn385366(v=3Dvs.110).aspx) wo= uld 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, Fortra= n 90, Fortran 95, Fortran 2003, Fortran 2008. Haskell has seen constant rev= ision. 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 som= e 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 v= ector is used instead for binary data and encoders handle converting betwee= n 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 a= nd "define atomic variable". * Greater immutability for local bindings. We should have a form that c= omplements "let x =3D y" to specify that the binding can't be modified. One= suggestion is "constant x =3D y". * More immutable types or better implementations of immutable types. We= can learn a lot from Clojure and other languages to provide better impleme= ntations of core types that are immutable. * Improvements to the numeric tower. This needs some serious thought. L= acking 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 (htt= p://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 lit= erals 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 w= ell in a Dylan 2016 effort. The goal is to have enough stuff with enough meat that we're looking at a s= ubstantial improvement on the language and something that can be talked abo= ut 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]<mailto:[email protected]> https://lists.opendylan.org/mailman/listinfo/hackers --_000_1e2e63ceccea4d9384fedc71d077016bSN2PR07MB080namprd07pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <style type=3D"text/css" style=3D"display:none"><!--P{margin-top:0;margin-b= ottom:0;} .ms-cui-menu {background-color:#ffffff;border:1px rgb(171, 171, 1= 71) solid;font-family:'Segoe UI WPC', 'Segoe UI', Tahoma, 'Microsoft Sans S= erif', Verdana, sans-serif;font-size:11pt;color:rgb(51, 51, 51);} .ms-cui-m= enusection-title {display:none;} .ms-cui-ctl {vertical-align:text-top;text-= decoration:none;color:rgb(51, 51, 51);} .ms-cui-ctl-on {background-color:rg= b(223, 237, 250);opacity: 0.8;} .ms-cui-img-cont-float {display:inline-bloc= k;margin-top:2px} .ms-cui-smenu-inner {padding-top:0px;} .ms-owa-paste-opti= on-icon {margin: 2px 4px 0px 4px;vertical-align:sub;padding-bottom: 2px;dis= play:inline-block;} .ms-rtePasteFlyout-option:hover {background-color:rgb(2= 23, 237, 250) !important;opacity:1 !important;} .ms-rtePasteFlyout-option {= padding:8px 4px 8px 4px;outline:none;} .ms-cui-menusection {float:left; wid= th:85px;height:24px;overflow:hidden}.wf {speak:none; font-weight:normal; fo= nt-variant:normal; text-transform:none; -webkit-font-smoothing:antialiased;= vertical-align:middle; display:inline-block;}.wf-family-owa {font-family:'= o365Icons'}@font-face { font-family:'o365IconsIE8'; src:url('https://r4.r= es.outlook.com/owa/prem/15.0.913.9/resources/styles/office365icons.ie8.eot?= #iefix') format('embedded-opentype'), url('https://r4.res.outlook.c= om/owa/prem/15.0.913.9/resources/styles/office365icons.ie8.woff') format('w= off'), url('https://r4.res.outlook.com/owa/prem/15.0.913.9/resource= s/styles/office365icons.ie8.ttf') format('truetype'); font-weight:normal; = font-style:normal;}@font-face { font-family:'o365IconsMouse'; src:url('h= ttps://r4.res.outlook.com/owa/prem/15.0.913.9/resources/styles/office365ico= ns.mouse.eot?#iefix') format('embedded-opentype'), url('https://r4.= res.outlook.com/owa/prem/15.0.913.9/resources/styles/office365icons.mouse.w= off') format('woff'), url('https://r4.res.outlook.com/owa/prem/15.0= .913.9/resources/styles/office365icons.mouse.ttf') format('truetype'); fon= t-weight:normal; font-style:normal;}.wf-family-owa {font-family:'o365Icons= Mouse'}.ie8 .wf-family-owa {font-family:'o365IconsIE8'}.ie8 .wf-owa-play-la= rge:before {content:'\e254';}.notIE8 .wf-owa-play-large:before {content:'\e= 054';}.ie8 .wf-owa-play-large {color:#FFFFFF/*$WFWhiteColor*/;}.notIE8 .wf-= owa-play-large {border-color:#FFFFFF/*$WFWhiteColor*/; width:1.4em; height:= 1.4em; border-width:.1em; border-style:solid; border-radius:.8em; text-alig= n:center; box-sizing:border-box; -moz-box-sizing:border-box; padding:0.1em;= color:#FFFFFF/*$WFWhiteColor*/;}.ie8 .wf-size-play-large {width:40px; heig= ht:40px; font-size:30px}.notIE8 .wf-size-play-large {width:40px; height:40p= x; font-size:30px}--></style> </head> <body dir=3D"ltr"> <div style=3D"font-size:10pt;color:#000000;background-color:#FFFFFF;font-fa= mily:Arial,Helvetica,sans-serif;"> <p>I'll definitely agree with the immutability idea. <span style=3D"fo= nt-size: 10pt;">I like the "constant x =3D y" idea, or,= "let constant x =3D y" - I just don't want to end up in a situat= ion with Scala, val/var, </span><span style=3D"font-size: 10pt;">where I can never seem to remember = which is which.</span></p> <p><br> </p> <p>Java's java.util.concurrent offers some really powerful collection types= , like BlockingQueues, that would be really worth investigating.<br> </p> <p><br> </p> <div style=3D"color: rgb(40, 40, 40);"> <hr tabindex=3D"-1" style=3D"display:inline-block; width:98%"> <div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" co= lor=3D"#000000" style=3D"font-size:11pt"><b>From:</b> hackers-bounces@lists= .opendylan.org <[email protected]> on behalf of Ben= jamin Pollack <[email protected]><br> <b>Sent:</b> Tuesday, April 15, 2014 7:17 AM<br> <b>To:</b> [email protected]<br> <b>Subject:</b> Re: [hackers] Dylan 2016: Evolving Dylan</font> <div> </div> </div> <div> <div>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.<br> </div> <div> </div> <div>The more things that can become immutable by default in Dylan, the bet= ter. 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 for high-performance code. Even s= omething as simple as .NET's Immutable Collections stack (<a href=3D"http:/= /msdn.microsoft.com/en-us/library/dn385366(v=3Dvs.110).aspx">http://msdn.mi= crosoft.com/en-us/library/dn385366(v=3Dvs.110).aspx</a>) would be really useful.<br> </div> <div> </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> </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+&#= 43;14. Fortran has Fortran 77, Fortran 90, Fortran 95, Fortran 2003, Fortra= n 2008. Haskell has seen constant revision. Java has as well.<br> </div> <div> </div> <div>No language is born perfect and we have our DEP process to deal with t= his.<br> </div> <div> </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> </div> <div>My current thoughts on things that I'd like to see proposed and implem= ented:<br> </div> <div> </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 a= ctually modify strings 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 anyt= hing of the right type or on bindings that have an "atomic" adjec= tive, such as slots and "define atomic variable".<br> </li><li>Greater immutability for local bindings. We should have a form tha= t complements "let x =3D y" to specify 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 types.= We can learn a lot from Clojure and other languages to provide better impl= ementations 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 borro= wed 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> </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 readabil= ity improvement.<br> </li></ul> <div> </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> </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> </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> </div> <div> - Bruce<br> </div> <div> </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> </div> </div> </div> </body> </html> --_000_1e2e63ceccea4d9384fedc71d077016bSN2PR07MB080namprd07pro_-- --===============0157131865== 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 --===============0157131865==--