The Strange Loop conference

[Timon Gehr]

On 09/21/2011 10:20 PM, Andrei Alexandrescu wrote:
> On 9/21/11 2:29 PM, Timon Gehr wrote:
>> On 09/21/2011 06:55 PM, Andrei Alexandrescu wrote:
>>> I'm back from the Strange Loop conference. It's been an interesting
>>> experience. The audience was very diverse, with interest in everything
>>> functional (you'd only need to say "Haskell" or "monad" to get positive
>>> aahs), Web/cloud/tablet stuff, concurrent and distributed systems.
>>> Mentioning C++ non-mockingly was all but a faux pas; languages like
>>> Scala, Haskell, Clojure, and Erlang got attention. The quality of talks
>>> has been very variable, and unfortunately the
>>> over-confident-but-clueless-speaker stereotype was well represented.
>>>
>>> I gave a talk there
>>> (https://thestrangeloop.com/sessions/generic-programming-galore-using-d)
>>> which has enjoyed moderate audience and success. I uploaded the slides
>>> at http://erdani.com/d/generic-programming-galore.pdf and the video may
>>> be available soon.
>>
>> I am looking forward to it!
>>
>>>
>>> There was a very strong interest in D's CTFE abilities, which we should
>>> consider a strategic direction going forward.
>>
>> One milestone would be to make DMD GC enabled. CTFE string manipulation
>> sucks up too much memory.
>>
>>> Also finalizing D's
>>> concurrency language and library infrastructure is essential. These two
>>> features are key differentiators. Also, capitalizing on D's functional
>>> features (which are e.g. better than Scala's but less known) would add
>>> good value.
>>>
>>
>> Where D still loses when compared to Scala is functional code syntax:
>>
>> val newcol = collection filter {x=>x<5} map {x=>2*x}
>
> Yoda this wrote.

Actually it is the order in which it will (conceptually at least) be 
executed =). D can do similar things on arrays with UFCS.

>
>> or maybe
>>
>> val newcol = for(x<-collection if(x<5)) yield 2*x
>
> Too baroque.
>
>> vs
>>
>> auto newrange = filter!((x){return x<5;})(map!((x){return 2*x;})(range));
>
> auto newrange = filter!"a<5"(map!"2*a"(range));
>
> At first some people get the heebiejeebies when seeing string-based
> lambda and the implicit naming convention for unary and binary
> functions.

Yes, I have seen it happen multiple times. There are even people who 
consider strings-as-code an evil concept entirely :o). How are CTFE and 
string mixins best introduced to people who think they might be too lazy 
to bother about learning more about the language?

> More importantly, there's the disadvantage you can't access
> local functions inside a string lambda.

I often want to do that. We could replace the 5 and 2 constants by stack 
variables, and then the point would be made.

> We should probably add a
> specialized lambda syntax.

It would probably be a simple addition as it is restricted mostly to the 
parser.

Like this? Or is there a better lambda syntax around?

int u,v;
auto newrange=map!(x=>u*x)(filter!(x=>v<x)(range));

auto newrange = range.filter!(x=>v<x).map!(x=>u*x);


>
>> I believe that is part of the reason why it is less known. If I write
>> functional style code in D I unfortunately usually get feedback that it
>> is "extremely hard to read". Furthermore, Scala has built-in tuples, and
>> eg delimited continuations, which enable some more functional
>> programming idioms. std.algorithm/std.range are also considerably (and
>> as I understand, deliberately) underpowered for FP when compared to eg
>> Haskell's standard set of libraries, and writing a good range from
>> scratch is usually a serious undertaking.
>
> I wonder what Scala/Haskell idioms we should borrow for D.

In my opinion these are worth looking into:

Haskell: This might not happen, but having a tiny little function with a 
literate name for most common tasks is very convenient. I think other 
Haskell idioms not already in D are hard to translate because the type 
system and execution model of the two languages are so different. I have 
managed to use D for haskell-lookalike toy examples nonetheless. (it 
leads to extremely obfuscated code because of many nested lambdas and a 
bug in the lazy storage class that needs to be worked around)

Both: (Concise expression-based lambdas.) Pattern matching, if it can be 
incorporated in a good way. (dynamic) lazy evaluation. Scala has lazy 
val. It would play very nicely with Ds purity, but maybe suboptimally 
with immutable (for immutable structures, the lazy fields would have to 
be computed eagerly)

Generators? (those are implicit in Haskell) Something like this example 
would automatically create a compile-time lazy range to compute a power 
set efficiently.

auto powerset(T)(T[] x) {
     foreach(i;0..1<<x.length) {
         yield (size_t i){
             while(i){
                 yield x[bsf(i)];
                 i &= i-1;
             }
         }(i);
     }
}

Equivalent code that spells out the nested structs with all the 
front/popFront/empty etc contains considerable boilerplate. I am not 
sure how powerful it could be, but it should be possible to 
automatically let the following example propagate random access iff fun 
is pure, based on the observation that it does not have state:

auto map(alias fun, R)(R m){
     foreach(x; m) yield unaryFun!fun(x);
}

The range concept is very important in D code, some syntactic sugar like 
this would help a lot.

>
>> Another big advantage that Scala has is that it supports pattern
>> matching. It is usually about the first feature functional programmers
>> care about.
>>
>> What do you think is the biggest advantage that Ds functional
>> programming has in comparison to Scala's?
>
> 1. True immutability
>
> 2. True purity

Compiler-enforced immutability and purity.

>
> 3. Pass by alias
>

It is extremely nice how templates are automatically instantiated in the 
correct scope. The fact that delegates are constrained to one context 
pointer and that static function literals don't decay to delegates tends 
to be annoying though. (also, that there is no inference if a context 
pointer is needed)

> For a language that has so firmly branded itself as functional, Scala
> has a surprisingly poor handling of immutability and referential
> transparency aka purity. My understanding is that Scala's immutability
> merely consists of final values and a web of conventions. (Please
> correct me if I'm wrong.)
>

I think you are right. But in Scala, much of the language semantics are 
actually implemented in the library. The immutable collections could be 
considered truly immutable by some.