www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Count your blessings!

reply Paul D. Anderson <paul.d.removethis.anderson comcast.andthis.net> writes:
If you think it is difficult to persuade Walter to adopt your latest idea for
improved syntax or new language features -- try getting a change into Java.

JavaOne 2009 is just concluded. The Java community is moving toward release of
JDK 7. It's overdue and underwhelming. Project Coin
(http://openjdk.java.net/projects/coin/) exists "to determine what set of small
language changes should be added to JDK 7". Joe Darcy
(http://blogs.sun.com/darcy/) is the lead on Project Coin. He has posted the
slides for his presentation at JavaOne:
http://blogs.sun.com/darcy/resource/JavaOne/J1_2009-TS-4060.pdf.

A couple of quick impressions:

1. The list of changes is small and shrinking. Only five will make the cut.

2. Many of the requested syntax changes already exist in D. (Of course.)

3. He explains (repeatedly) the amount of work required to make a "small"
change. This is the primary justification for the shortness of the list.

4. His stance with regard to changes is this: Don't explain why a change
shouldn't be kept out ("It's trivial.", "Everybody does it.", "It's
intuitive."), but rather why it should be put in. Give a clear statement of
what's proposed, how to implement it, and a list of reasons why it should be
included.

There are some lessons for us there, I think. (I don't mean to criticize anyone
or any suggestions that have been made. Just to point out some of the things we
all ought to consider. And to remind us that having a forum where we can
discuss changes and have them considered by a lot of intelligent, interested
people is a rare thing.)

Paul


Paul
Jun 10 2009
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Paul D. Anderson wrote:

 2. Many of the requested syntax changes already exist in D. (Of
 course.)


I'm not a bit surprised that Java is adopting D features!
Jun 10 2009
prev sibling next sibling parent ponce <aliloko gmail.com> writes:
"I would like Java to run native, have x86 inline assembly and powerful
generics" :)
Jun 10 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Paul D. Anderson wrote:

 If you think it is difficult to persuade Walter to adopt your latest
 idea for improved syntax or new language features -- try getting a
 change into Java.
 
 JavaOne 2009 is just concluded. The Java community is moving toward
 release of JDK 7. It's overdue and underwhelming. Project Coin
 (http://openjdk.java.net/projects/coin/) exists "to determine what
 set of small language changes should be added to JDK 7". Joe Darcy
 (http://blogs.sun.com/darcy/) is the lead on Project Coin. He has
 posted the slides for his presentation at JavaOne:
 http://blogs.sun.com/darcy/resource/JavaOne/J1_2009-TS-4060.pdf.
 
 A couple of quick impressions:
 
 1. The list of changes is small and shrinking. Only five will make
 the cut.
 
 2. Many of the requested syntax changes already exist in D. (Of
 course.)
 
 3. He explains (repeatedly) the amount of work required to make a
 "small" change. This is the primary justification for the shortness
 of the list.
 
 4. His stance with regard to changes is this: Don't explain why a
 change shouldn't be kept out ("It's trivial.", "Everybody does it.",
 "It's intuitive."), but rather why it should be put in. Give a clear
 statement of what's proposed, how to implement it, and a list of
 reasons why it should be included.
 
 There are some lessons for us there, I think. (I don't mean to
 criticize anyone or any suggestions that have been made. Just to
 point out some of the things we all ought to consider. And to remind
 us that having a forum where we can discuss changes and have them
 considered by a lot of intelligent, interested people is a rare
 thing.)


Pretty cool slides. Some highlights I found interesting:

* split() should be the inverse of join() as Brad suggested

* that "why don't we" is the right thing to ask instead of "why don't 
you" :o)

* there is a strong momentum of lightweight iterators

* finally they seem to have heard of the STL in slides 36 and 37

* they finally see the naked emperor on slide 56 yet incredibly they 
still manage to continue doing precisely the wrong thing on slide 57; 
this one is enormously vexing to me

* what can we do about the feature on slide 33?

* as always enums are more complicated than they seem

* dangerously close to auto on slide 64; you'd wonder what would it take 
to make that penny drop :o)

* error text on slide 68 is longer than the error text on slide 67 that 
it's supposed to improve on

* there is nothing to improve threads, further demotivating support for 
Deadlock-Oriented Programming (DOP) in D


Andrei
Jun 10 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Paul D. Anderson:

 1. The list of changes is small and shrinking. Only five will make
 the cut.


It's a very small list. So I ask myself why they have chosen some of the few
things thay have chosen.

One of those five precios things is the "Elvis" operator:
Exp1 ?: Exp2

That means:
If Exp1 is non-null, use that, otherwise evaluate and use Exp2

Adding it to D looks easy, but is such operator so important to be in the list
of the only 5 things to add? I don't currently feel the need of it.



 2. Many of the requested syntax changes already exist in D. (Of course.)<



different form.
We'll not see that soon in D.

-------------------------

This is a nice thing they have added:
Annotations on types: enable pluggable type systems like null-checkers
"Preventing Bugs with Pluggable Type Checking", (TS-3798) Michael Ernst, Today,
4:40-5:40

But there's a better solution for this problem, that I hope to see into the D
typesystem someday (and sooner the better, because it requires a significant
change in how the D2 language is used and written).

-------------------------

Andrei Alexandrescu:


what can we do about the feature on slide 33?<


You are talking about catching more than an exception in the same catch(),
discussed here (it also has improved checking for rethrown exceptions):
http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000003.html

This is useful and handy, but I think it's not an essential feature, there are
more important things to think&discuss about (like a type system where object
references are non-null by default, and able to avoid most null exceptions in
programs).

They propose:

try {
    doWork(file);
} catch (final Except1 | Except2 ex) {
    logger.log(ex);
    throw ex;
}


They also say:

To avoid the need to add support for general disjunctive types, but leaving
open the possibility of a future extension along these lines, a catch parameter
whose type has more than one disjunct is required to be declared * final*.<


(Very recently they have fixed the Python syntax to allow a tidier catch of
multiple exceptions, but the syntax is not compatible to D, so I don't show it
here).

But using a comma in some way is better than a bitwise or. A possible D syntax:

import std.stdio: writefln;

class Except1 : Exception {
    this() { super(this.classinfo.name); }
}
class Except2 : Exception {
    this() { super(this.classinfo.name); }
}

void main() {
    try {
        throw new Except2();
    } catch (Except1, Except2 ex) {
        writefln(ex.classinfo.name);
    }
}

I don't like that syntax because the list of exceptions before "ex" isn't a
gestalt separated enough from "ex".

A possible alternative:
} catch ([Except1, Except2] ex) {

Bye,
bearophile
Jun 10 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:

 Paul D. Anderson:

 1. The list of changes is small and shrinking. Only five will make 
 the cut.


 
 It's a very small list. So I ask myself why they have chosen some of
 the few things thay have chosen.
 
 One of those five precios things is the "Elvis" operator: Exp1 ?:
 Exp2
 
 That means: If Exp1 is non-null, use that, otherwise evaluate and use
 Exp2
 
 Adding it to D looks easy, but is such operator so important to be in
 the list of the only 5 things to add? I don't currently feel the need
 of it.


I agree. D has it already by the way:

Exp1 && Exp2;


 2. Many of the requested syntax changes already exist in D. (Of
 course.)<


 
 Some people have asked for invokedynamic, that is already present in



What is invokedynamic?



Andrei
Jun 10 2009
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Wed, Jun 10, 2009 at 4:09 PM, Andrei
Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:

 I agree. D has it already by the way:

 Exp1 && Exp2;


Doesn't that evaluate to a bool rather than typeof(Exp1)?

--bb
Jun 10 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 On Wed, Jun 10, 2009 at 4:09 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:

 I agree. D has it already by the way:

 Exp1 && Exp2;


 
 Doesn't that evaluate to a bool rather than typeof(Exp1)?


Sorry, I'd forgotten that.

Andrei
Jun 10 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Wed, Jun 10, 2009 at 4:35 PM, Andrei
Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:

 Bill Baxter wrote:

 On Wed, Jun 10, 2009 at 4:09 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:

 I agree. D has it already by the way:

 Exp1 && Exp2;


 Doesn't that evaluate to a bool rather than typeof(Exp1)?


 Sorry, I'd forgotten that.


You musta been thinking of Perl.

--bb
Jun 10 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 On Wed, Jun 10, 2009 at 4:35 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:

 Bill Baxter wrote:

 On Wed, Jun 10, 2009 at 4:09 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:

 I agree. D has it already by the way:

 Exp1 && Exp2;


 Doesn't that evaluate to a bool rather than typeof(Exp1)?


 Sorry, I'd forgotten that.


 
 You musta been thinking of Perl.


I am. I'd suggested to Walter to did the same but he mentioned the 
ensuing incompatibility with C and C++ expressions.

Andrei
Jun 10 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 I am. I'd suggested to Walter to did the same but he mentioned the 
 ensuing incompatibility with C and C++ expressions.


This is one of the cases where breaking C compatibility is useless, you can
just add the Elvis operator to D2 if it's important. (There are other
situations where breaking C compatibility may be more important).

Bye,
bearophile
Jun 10 2009
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Andrei Alexandrescu wrote:

 Bill Baxter wrote:

 On Wed, Jun 10, 2009 at 4:35 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:

 Bill Baxter wrote:

 On Wed, Jun 10, 2009 at 4:09 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:

 I agree. D has it already by the way:

 Exp1 && Exp2;


 Doesn't that evaluate to a bool rather than typeof(Exp1)?


 Sorry, I'd forgotten that.


 You musta been thinking of Perl.


 
 I am. I'd suggested to Walter to did the same but he mentioned the 
 ensuing incompatibility with C and C++ expressions.
 
 Andrei


As well as the incompatibility with intuition. If anything, I'd think 
the Elvis operator is more of an "or" since "x ?: y" means "x !is null ? 
x : y". Doesn't && evaluate both arguments unless the first is false (or 
in this case, null)?
Jun 10 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Robert Fraser:

 As well as the incompatibility with intuition. If anything, I'd think 
 the Elvis operator is more of an "or" since "x ?: y" means "x !is null ? 
 x : y". Doesn't && evaluate both arguments unless the first is false (or 
 in this case, null)?


Yes, it's a relative of "or". In Python the Elvis operator is the "or" itself:


 a, b, c = 10, 0, 5
 a or b






10

 b or a






10

 a and b






0

 b and a






0

 a and c






5

 c and a






10

In my dlibs there's a lazyOr() that takes any number of arguments and returns
the first one that's true (where true is defined by a standard function
boolean() that returns false for 0, null, objects/structs that have a length
and where such length is zero).

A reduced (and untested) version that works with two arguments only, that is (I
think) the Elvis operator:

Tx lazyOr(Tx, Ty)(Tx x, lazy Ty y) {
    static assert(CastableTypes!(Tuple!(Tx, Ty)), "lazyOr: all items must be
castable to the same type.");
    if (boolean(x))
        return x;
    return y();
}

A difference is that the Elvis operator is more efficient because it doesn't
need to create a lazy delegate as in the D code (I don't know if LDC is able to
optmize away such y delegate).

Bye,
bearophile
Jun 11 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:

 In my dlibs there's a lazyOr() that takes any number of arguments and returns
the first one that's true (where true is defined by a standard function
boolean() that returns false for 0, null, objects/structs that have a length
and where such length is zero).
 
 A reduced (and untested) version that works with two arguments only, that is
(I think) the Elvis operator:
 
 Tx lazyOr(Tx, Ty)(Tx x, lazy Ty y) {
     static assert(CastableTypes!(Tuple!(Tx, Ty)), "lazyOr: all items must be
castable to the same type.");
     if (boolean(x))
         return x;
     return y();
 }


I guess this would work better:

CommonType!(Tx, Ty) lazyOr(Tx, Ty)(Tx x, lazy Ty y) { ... }


Andrei
Jun 11 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 I guess this would work better:
 CommonType!(Tx, Ty) lazyOr(Tx, Ty)(Tx x, lazy Ty y) { ... }


What's the improvement?
(And I think that code of mine gives a better error message.)

Bye,
bearophile
Jun 11 2009
parent BCS <ao pathlink.com> writes:
Reply to bearophile,


 Andrei Alexandrescu:
 

 I guess this would work better:
 CommonType!(Tx, Ty) lazyOr(Tx, Ty)(Tx x, lazy Ty y) { ... }


 What's the improvement?


class C {}
class D1 : C {}
class D2 : C {}

D1 d1;
D2 d2;

auto r = lazyOr(d1, d2);


 (And I think that code of mine gives a better error message.)
 Bye,
 bearophile
Jun 11 2009
prev sibling next sibling parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Andrei Alexandrescu wrote:

 bearophile wrote:

 One of those five precios things is the "Elvis" operator: Exp1 ?:
 Exp2

 That means: If Exp1 is non-null, use that, otherwise evaluate and use
 Exp2

 Adding it to D looks easy, but is such operator so important to be in
 the list of the only 5 things to add? I don't currently feel the need
 of it.


 
 I agree. D has it already by the way:
 
 Exp1 && Exp2;


You may want to re-read the spec on that. "The result type of an 
AndAndExpression is bool, unless the right operand has type void, when the 
result is type void."
So the result will never be a pointer or object reference.

http://www.digitalmars.com/d/1.0/expression.html#AndAndExpression (The text 
appears to be identical for D2)
Jun 10 2009
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

[Elvis operator]I agree.<


But note that I don't use much OOP in D. For people (like Java programmers)
that use OOP a lot that operator may be useful.



What is invokedynamic?<


A way to add some dynamic typing to the Java language (Java type system is
already a lot dynamic, but it has the rigidity of an old static type system and
just a bit more of the safety of a dynamic language. The worst of both worlds.
Java Generics have later increased safety some).


better), adding a "dynamic" keyword that transforms variables into dynamically
typed ones in a quite transparent way.

Now it's very easy (and efficient enough) to implement a mixed dynamic/static
language like Boo on the dotnet4.

Bye,
bearophile
Jun 10 2009
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-06-10 17:38:55 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:


 * there is nothing to improve threads, further demotivating support for 
 Deadlock-Oriented Programming (DOP) in D


On the contrary. I believe they're doing nothing because their hands are tied.

They cannot do much for multithreading at the language level without 
creating breaking changes. What's needed for DOP is a language and 
compiler with the proper restrictions, and good defaults. Changing any 
of this is a breaking change and thus gets rejected (like const) 
because they want to keep backward compatibility.

With D2, we have the liberty of breaking things to make them better. We 
already have, and I hope it continues.


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Jun 10 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michel Fortin wrote:

 On 2009-06-10 17:38:55 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:
 

 * there is nothing to improve threads, further demotivating support 
 for Deadlock-Oriented Programming (DOP) in D


 
 On the contrary. I believe they're doing nothing because their hands are 
 tied.
 
 They cannot do much for multithreading at the language level without 
 creating breaking changes.


Actually they could. For example, introducing qualifiers that add 
restrictions would be backwards-compatible. Besides, they are highly 
motivated because Java is DOP bonanza and has no solid alternatives. But 
they didn't.

Andrei
Jun 10 2009
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-06-10 20:14:25 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:


 Michel Fortin wrote:

 On 2009-06-10 17:38:55 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:
 

 * there is nothing to improve threads, further demotivating support for 
 Deadlock-Oriented Programming (DOP) in D


 
 On the contrary. I believe they're doing nothing because their hands are tied.
 
 They cannot do much for multithreading at the language level without 
 creating breaking changes.


 
 Actually they could. For example, introducing qualifiers that add 
 restrictions would be backwards-compatible.


Even if it is not a breaking change at the language level, to be really 
useful you have to update the standard library to use those restricting 
keywords where it makes sense, thus adding restrictions existing parts 
of the standard library and breaking things. See why they didn't 
implement 'const':

<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4211070>

* Adding const is too late now.  Had this been added from 1.0,
  the situation could have been different.
[...]
* Compatibility is a very important feature of the JDK.
  Arguably, the collection classes should be modified to
  indicate that the elements are const.  That would
  require all existing implementations to be updated in
  the same way, effectively breaking all existing non-JDK
  implementations of the collection interfaces.  Similarly,
  hashCode would have to be const, breaking the current
  implementation of String.


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Jun 12 2009