www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D affects others

reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
Mike Hearn has started a thread on the Kotlin (*) mailing list extolling
the virtues of D's transitive const.  Andrey Breslav (the leader of the
Kotlin team at JetBrains) has made a couple of replies that I think may
be interesting here:


"As C++ and D show, const is not that easy. We'd like to have something
like it, but it's hard to implement in a useful way"

"D's approach is useful, but to make it work in Kotlin we'd need to know
what's const in JDK and what's not. We are exploring the possible ways
of knowing that, but it's not straightforward.
Also, D's approach does not support lazy evaluation, caches of all sorts
etc, that we think are crucial in application software.
 
BTW, note that const does not come alone, but together with immutable,
which we also would like to have in Kotlin, and which needs some more
careful design wrt Java libearies, memory model etc"




(*) Kotlin is a statically-typed language being created by JetBrains as
a successor to Java. http://kotlin.jetbrains.org/ (**) Scala and Ceylon
(and indeed Groovy) are other players in this game.

(**) Kotlin, like Scala and Ceylon, is full open source. One day Java
may also be, cf. OpenJDK.
-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
May 28 2014
next sibling parent reply "Wanderer" <no-reply no-reply.org> writes:
It's very hard to keep up-to-date with all these successors to 
Java. Every half a year a new language appears, and it's always 
"better than all previous". :-(

D's const feature is nice and clear. But what made me "fall in 
love" with D, is 'immutable' modifier. No inner mutable pieces 
possible, no need to copy defensively (or copy at all), no risk 
of data corruption, no matter how complex your data is. Very 
clever idea.
May 28 2014
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2014-05-28 at 16:31 +0000, Wanderer via Digitalmars-d wrote:
 It's very hard to keep up-to-date with all these successors to 
 Java. Every half a year a new language appears, and it's always 
 "better than all previous". :-(
I am not sure which languages you are thinking of here, there really are not that many languages seriously proposed in the Java-verse. cf. http://en.wikipedia.org/wiki/List_of_JVM_languages Of course in academia everyone involved in programming language research has to propose a couple of new languages a year to get funding. A very sad system and state of affairs.
 D's const feature is nice and clear. But what made me "fall in 
 love" with D, is 'immutable' modifier. No inner mutable pieces 
 possible, no need to copy defensively (or copy at all), no risk 
 of data corruption, no matter how complex your data is. Very 
 clever idea.
We definitely like immutable :-) -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
May 28 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/28/14, 10:05 AM, Russel Winder via Digitalmars-d wrote:
 On Wed, 2014-05-28 at 16:31 +0000, Wanderer via Digitalmars-d wrote:
 D's const feature is nice and clear. But what made me "fall in
 love" with D, is 'immutable' modifier. No inner mutable pieces
 possible, no need to copy defensively (or copy at all), no risk
 of data corruption, no matter how complex your data is. Very
 clever idea.
We definitely like immutable :-)
Well it's quite a change of tenor compared to the early reaction. Immutable has improved a frakton since, mainly thanks to Kenji's amazing work. -- Andrei
May 29 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/28/2014 1:49 AM, Russel Winder via Digitalmars-d wrote:
 Also, D's approach does not support lazy evaluation, caches of all sorts
 etc, that we think are crucial in application software.
Yes, that's so-called "logical const". This has come up several times here, and many have argued strongly to support it. My view is that logical const is not mechanically checkable, and therefore is a convention. D's const'ness is about guarantees, not conventions. Of course, D offers an escape from anything. You can do logical constness by using unsafe casts, but the onus is then on you to get it right.
May 28 2014
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 28 May 2014 at 18:08:42 UTC, Walter Bright wrote:
 On 5/28/2014 1:49 AM, Russel Winder via Digitalmars-d wrote:
 Also, D's approach does not support lazy evaluation, caches of 
 all sorts
 etc, that we think are crucial in application software.
Yes, that's so-called "logical const". This has come up several times here, and many have argued strongly to support it. My view is that logical const is not mechanically checkable, and therefore is a convention. D's const'ness is about guarantees, not conventions. Of course, D offers an escape from anything. You can do logical constness by using unsafe casts, but the onus is then on you to get it right.
It is probably a good idea to provide such escape in a safe interface somewhere in the library, no ?
May 28 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/28/2014 1:49 PM, deadalnix wrote:
 It is probably a good idea to provide such escape in a safe
 interface somewhere in the library, no ?
If anyone wants to design such a module, please do so.
May 28 2014
parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 28 May 2014 at 21:22:36 UTC, Walter Bright wrote:
 On 5/28/2014 1:49 PM, deadalnix wrote:
 It is probably a good idea to provide such escape in a safe
 interface somewhere in the library, no ?
If anyone wants to design such a module, please do so.
i have to say i'm not sure what people actually want :D I'll end up putting something together the day i need it, for sure.
May 28 2014
prev sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 28 May 2014 at 20:49:31 UTC, deadalnix wrote:
 It is probably a good idea to provide such escape in a safe
 interface somewhere in the library, no ?
I am not sure it is possible to design such module so that it will be both sufficiently generic and reliably type safe. Can be an interesting challenge though.
May 28 2014
prev sibling parent "w0rp" <devw0rp gmail.com> writes:
On Wednesday, 28 May 2014 at 18:08:42 UTC, Walter Bright wrote:
 On 5/28/2014 1:49 AM, Russel Winder via Digitalmars-d wrote:
 Also, D's approach does not support lazy evaluation, caches of 
 all sorts
 etc, that we think are crucial in application software.
Yes, that's so-called "logical const". This has come up several times here, and many have argued strongly to support it. My view is that logical const is not mechanically checkable, and therefore is a convention. D's const'ness is about guarantees, not conventions. Of course, D offers an escape from anything. You can do logical constness by using unsafe casts, but the onus is then on you to get it right.
I'm a big fan of D's const, and strong static checking is one of the reasons I picked up D a while ago. I think putting a little violation of the type system to accomplish something you really, really need, say in a trusted function, is a good way to do things. Most of the time, you don't *really* need to do those things.
May 28 2014