|
Archives
D Programming
digitalmars.D
digitalmars.D.bugs
digitalmars.D.dtl
digitalmars.D.ide
digitalmars.D.dwt
digitalmars.D.announce
digitalmars.D.learn
digitalmars.D.debugger
D.gnu
D
C/C++ Programming
c++
c++.announce
c++.atl
c++.beta
c++.chat
c++.command-line
c++.dos
c++.dos.16-bits
c++.dos.32-bits
c++.idde
c++.mfc
c++.rtl
c++.stl
c++.stl.hp
c++.stl.port
c++.stl.sgi
c++.stlsoft
c++.windows
c++.windows.16-bits
c++.windows.32-bits
c++.wxwindows
digitalmars.empire
digitalmars.DMDScript
electronics
|
digitalmars.D - Count your blessings!
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
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!
"I would like Java to run native, have x86 inline assembly and powerful
generics" :)
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
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.)<
Some people have asked for invokedynamic, that is already present in C#4 in a
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
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
C#4 in a different form. We'll not see that soon in D.
What is invokedynamic?
Andrei
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)
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
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;
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
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
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;
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)?
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
b or a
a and b
b and a
a and c
c and a
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
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
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
Reply to bearophile,
Andrei Alexandrescu:
I guess this would work better:
CommonType!(Tx, Ty) lazyOr(Tx, Ty)(Tx x, lazy Ty y) { ... }
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
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).
C#4 solves the same problem in a more drastic and generic way (and probably
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
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
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/
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
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/
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
|
|
C & C++
DMDScript
Walter Bright <newshound1 digitalmars.com> 