View mode: basic / threaded / horizontal-split · Log in · Help
September 20, 2012
Slides from LASER 2012
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
September 20, 2012
Re: Slides from LASER 2012
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
September 20, 2012
Re: Slides from LASER 2012
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 ?
September 20, 2012
Re: Slides from LASER 2012
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
September 20, 2012
Re: Slides from LASER 2012
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.
September 20, 2012
Re: Slides from LASER 2012
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
September 20, 2012
Re: Slides from LASER 2012
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
September 20, 2012
Re: Slides from LASER 2012
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
September 20, 2012
Re: Slides from LASER 2012
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
September 20, 2012
Re: Slides from LASER 2012
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.
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home