I've had the honor of rubbing shoulders for a week at http://laser.inf.ethz.ch/2012/ with Roberto Ierusalimschy, Ivar Jacobson, Erik Meijer, Bertrand Meyer, Martin Odersky, Simon Peyton-Jones, and Guido van Rossum. It was awesome, and I got many good tips on how to grow our community.

In particular, I've enjoyed a few good discussions with Simon and Martin about D's approach to doing things. In particular, Martin has been quite impressed with our approach to purity and immutability. We are considering a collaboration with one of his students on a paper to formalize the approach and possibly adapt it to Scala.

So, these are the slides I've used (though of course they don't tell much of the story).

http://laser.inf.ethz.ch/2012/slides/Alexandrescu/2-D%20course%20parts%201%20and%202.pdf


Andrei

On Thu, 20 Sep 2012 14:57:45 +0200, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> I've had the honor of rubbing shoulders for a week at http://laser.inf.ethz.ch/2012/ with Roberto Ierusalimschy, Ivar Jacobson, Erik Meijer, Bertrand Meyer, Martin Odersky, Simon Peyton-Jones, and Guido van Rossum. It was awesome, and I got many good tips on how to grow our community.
>
> In particular, I've enjoyed a few good discussions with Simon and Martin about D's approach to doing things. In particular, Martin has been quite impressed with our approach to purity and immutability. We are considering a collaboration with one of his students on a paper to formalize the approach and possibly adapt it to Scala.
>
> So, these are the slides I've used (though of course they don't tell much of the story).
>
> http://laser.inf.ethz.ch/2012/slides/Alexandrescu/2-D%20course%20parts%201%20and%202.pdf

Cool. And now the inevitable: Will there be video?


-- 
Simen

Le 20/09/2012 14:57, Andrei Alexandrescu a écrit :
> I've had the honor of rubbing shoulders for a week at
> http://laser.inf.ethz.ch/2012/ with Roberto Ierusalimschy, Ivar
> Jacobson, Erik Meijer, Bertrand Meyer, Martin Odersky, Simon
> Peyton-Jones, and Guido van Rossum. It was awesome, and I got many good
> tips on how to grow our community.
>
> In particular, I've enjoyed a few good discussions with Simon and Martin
> about D's approach to doing things. In particular, Martin has been quite
> impressed with our approach to purity and immutability. We are
> considering a collaboration with one of his students on a paper to
> formalize the approach and possibly adapt it to Scala.
>
> So, these are the slides I've used (though of course they don't tell
> much of the story).
>
> http://laser.inf.ethz.ch/2012/slides/Alexandrescu/2-D%20course%20parts%201%20and%202.pdf
>
>
>
> Andrei

What is Sininimp-Mulinint object-oriented style ?

Andrei Alexandrescu:

> In particular, Martin has been quite impressed with our approach to purity and immutability. We are considering a collaboration with one of his students on a paper to formalize the approach and possibly adapt it to Scala.

Formalizing D purity is probably possible, but it already has many special cases, and few more are coming (see Bugzilla on this)!

Regarding cross pollination with Scala: despite I generally don't like lazy lists in high-performance code, in many other kinds of code they are very handy, as in Haskell, Perl6 and Scala (in Scala they are named purely functional lazy streams).

If you take a look at Python/Scala/C# code that generates values lazily, the Range-based version in D is sometimes several times longer, much more easy to get wrong, harder to write, etc.

This is Haskell code to test if just the leaves of two binary trees contain the same data, this code is lazy:

data Tree a = Leaf a | Node (Tree a) (Tree a)

fringe :: Tree a -> [a]
fringe (Leaf x) = [x]
fringe (Node n1 n2) = fringe n1 ++ fringe n2

sameFringe :: (Eq a) => Tree a -> Tree a -> Bool
sameFringe t1 t2 = fringe t1 == fringe t2


Doing the same thing in D, using ranges, is possible, but the code is ten times longer or more:
http://rosettacode.org/wiki/Same_Fringe#Strong_Lazy_Version

Similar code is possible in Scala (and in this case most of the saving of lines of code doesn't come from pattern matching and algebraic data types, but from the good support for lazy lists/streams). This kind of code is very common, even when you aren't coding in functional style.

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

> So, these are the slides I've used (though of course they don't tell much of the story).
>
> http://laser.inf.ethz.ch/2012/slides/Alexandrescu/2-D%20course%20parts%201%20and%202.pdf

Thank you for the slides.
I hope we'll have the range-based min(), and argmin/argmax in Phobos :-)

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

At page 33:

auto m = s.argmin!((x) => x.length);

This isn't compiled with -property. So what's the right way to write D code?

In Python to avoid that lambda there is a len() global function, that just calls the __len__ attribute/property of collections and objects. So an equivalent Python version is:

auto m = s.argmin!len;

Bye,
bearophile

On Thursday, 20 September 2012 at 14:15:22 UTC, deadalnix wrote:
> What is Sininimp-Mulinint object-oriented style ?

I believe it's some weird way of saying:

SINgle INheritance of IMPlementation
MULtiple INheritance of INTerfaces

As opposed to C++ where you can multiply inherit implementations.

Bummer that they didn't hold the event in Zurich – maybe I would have managed to sneak in… ;)

On Thursday, 20 September 2012 at 12:56:44 UTC, Andrei Alexandrescu wrote:
> http://laser.inf.ethz.ch/2012/slides/Alexandrescu/2-D%20course%20parts%201%20and%202.pdf

The code on slide 6 contains an issue resp. inaccuracy: Not all random access ranges are sliceable. Sometimes I wonder (and this is not at all intended as a snide remark!) if it is too easy to make mistakes regarding template constraints, if even you as the (co-?) designer of std.range get them wrong occasionally.

David

On 09/20/2012 04:23 PM, bearophile wrote:
> Andrei Alexandrescu:
>
>> In particular, Martin has been quite impressed with our approach to
>> purity and immutability. We are considering a collaboration with one
>> of his students on a paper to formalize the approach and possibly
>> adapt it to Scala.
>
> Formalizing D purity is probably possible, but it already has many
> special cases, and few more are coming (see Bugzilla on this)!
>

Formalising it is not hard, but the D implementation will have to be
fixed. Just decouple 'immutable' and 'pure' completely,

int foo()pure{
    int x;
    immutable int y;
    void bar()pure{
        x++; // ok
    }
    int baz()pure immutable{
        return y; // ok
    }
    int foo()pure immutable{
        return x; // error
    }
}

then rename pure to somethingother and make pure a synonym for
somethingother immutable and add that to Scala.


> Regarding cross pollination with Scala: despite I generally don't like
> lazy lists in high-performance code, in many other kinds of code they
> are very handy, as in Haskell, Perl6 and Scala (in Scala they are named
> purely functional lazy streams).
>
> If you take a look at Python/Scala/C# code that generates values lazily,
> the Range-based version in D is sometimes several times longer, much
> more easy to get wrong, harder to write, etc.
>
> This is Haskell code to test if just the leaves of two binary trees
> contain the same data, this code is lazy:
>
> data Tree a = Leaf a | Node (Tree a) (Tree a)
>
> fringe :: Tree a -> [a]
> fringe (Leaf x) = [x]
> fringe (Node n1 n2) = fringe n1 ++ fringe n2
>
> sameFringe :: (Eq a) => Tree a -> Tree a -> Bool
> sameFringe t1 t2 = fringe t1 == fringe t2
>
>
> Doing the same thing in D, using ranges, is possible, but the code is
> ten times longer or more:
> http://rosettacode.org/wiki/Same_Fringe#Strong_Lazy_Version
>

The translation is (spaces added for your convenience, you won't get me
to use parens though):

mixin ADT!q{ Tree(T): Leaf(T x), Node(Tree a, Tree b) };

DynRange!T fringe(T)(Tree!T t){
    return t.match!(
        (Leaf l) => cons(l.x, empty),
        (Node n) => chain(n.a.fringe, n.b.fringe).dynRange,
    );
}

bool sameFringe(T)(Tree!T t1, Tree!T t2){
    return equal(t1.fringe, t2.fringe);
}

for suitable definitions of ADT, DynRange/dynRange, cons and empty.  So
those would be nice additions to Phobos. Obviously this would look even
better:

mixin ADT!q{ Tree(T): Leaf(T x), Node(Tree a, Tree b) };

DynRange!T fringe(T)(Tree!T t) => t.match!(
    (Leaf l) => cons(l.x, empty),
    (Node n) => chain(n.a.fringe, n.b.fringe).dynRange,
);

bool sameFringe(T)(Tree!T t1, Tree!T t2) => t1.fringe == t2.fringe;

The number of lines equals the Haskell example in this case.
Interestingly, you have opened an enhancement request on this and then
argued against it.


> Similar code is possible in Scala (and in this case most of the saving
> of lines of code doesn't come from pattern matching and algebraic data
> types, but from the good support for lazy lists/streams). This kind of
> code is very common, even when you aren't coding in functional style.
>
> --------------------
>
>> So, these are the slides I've used (though of course they don't tell
>> much of the story).
>>
>> http://laser.inf.ethz.ch/2012/slides/Alexandrescu/2-D%20course%20parts%201%20and%202.pdf
>>
>
> Thank you for the slides.
> I hope we'll have the range-based min(), and argmin/argmax in Phobos :-)
>
> --------------------
>
> At page 33:
>
> auto m = s.argmin!((x) => x.length);
>
> This isn't compiled with -property. So what's the right way to write D
> code?
>

There is no 'right' way. But this is the pretty way, the way you use to
show off the language at a presentation (otherwise you'll get questions
like: "that is all well, but what on earth is that second pair of
parens for?")

> In Python to avoid that lambda there is a len() global function, that
> just calls the __len__ attribute/property of collections and objects. So
> an equivalent Python version is:
>
> auto m = s.argmin!len;
>
> Bye,
> bearophile

Timon Gehr:

> Formalising it is not hard,

I am not sure of this, given the amount of special cases it already has.


> The number of lines equals the Haskell example in this case.
> Interestingly, you have opened an enhancement request on this and then argued against it.

I am not against it, it's a nice syntax. But I think there are more useful things to change/add, like syntax to destructure tuples, that I need every 20 lines of code or so. When you put out many suggestions, I think it's important to specify what you think is more important and what's less important.


> There is no 'right' way.

So we don't agree even on what we have to agree :-)

And having multiple correct ways to do something is often bad :-(

Bye,
bearophile

Timon Gehr:

> mixin ADT!q{ Tree(T): Leaf(T x), Node(Tree a, Tree b) };
>
> DynRange!T fringe(T)(Tree!T t){
>     return t.match!(
>         (Leaf l) => cons(l.x, empty),
>         (Node n) => chain(n.a.fringe, n.b.fringe).dynRange,
>     );
> }
>
> bool sameFringe(T)(Tree!T t1, Tree!T t2){
>     return equal(t1.fringe, t2.fringe);
> }
>
> for suitable definitions of ADT, DynRange/dynRange, cons and empty.  So
> those would be nice additions to Phobos. Obviously this would look even
> better:
>
> mixin ADT!q{ Tree(T): Leaf(T x), Node(Tree a, Tree b) };
>
> DynRange!T fringe(T)(Tree!T t) => t.match!(
>     (Leaf l) => cons(l.x, empty),
>     (Node n) => chain(n.a.fringe, n.b.fringe).dynRange,
> );
>
> bool sameFringe(T)(Tree!T t1, Tree!T t2) => t1.fringe == t2.fringe;

And thank you for the code example.

Bye,
bearophile

Le 20/09/2012 18:39, Timon Gehr a écrit :
> On 09/20/2012 04:23 PM, bearophile wrote:
>> Andrei Alexandrescu:
>>
>>> In particular, Martin has been quite impressed with our approach to
>>> purity and immutability. We are considering a collaboration with one
>>> of his students on a paper to formalize the approach and possibly
>>> adapt it to Scala.
>>
>> Formalizing D purity is probably possible, but it already has many
>> special cases, and few more are coming (see Bugzilla on this)!
>>
>
> Formalising it is not hard, but the D implementation will have to be
> fixed. Just decouple 'immutable' and 'pure' completely,
>
> int foo()pure{
> int x;
> immutable int y;
> void bar()pure{
> x++; // ok
> }
> int baz()pure immutable{
> return y; // ok
> }
> int foo()pure immutable{
> return x; // error
> }
> }
>
> then rename pure to somethingother and make pure a synonym for
> somethingother immutable and add that to Scala.
>

I proposed something similar in the epic delegate thread. I observe that thing fall together nicely with it on several topics. It seems like the way to go.