DConf 2014 Keynote: High Performance Code Using D by Walter Bright

[Andrei Alexandrescu via Digitalmars-d-announce]

On 7/16/14, 3:22 AM, bearophile wrote:
> Andrei Alexandrescu:
>> http://www.reddit.com/r/programming/comments/2aruaf/dconf_2014_keynote_high_performance_code_using_d/
>>
>
> Despite Walter is used to "pipeline programming", so the next step is to
> also handle failures and off-band messages in a functional way (without
> exceptions and global error values) with two "parallel pipelines", here
> named "Railway-Oriented Programming". This is one of the simplest
> introductions (and he can skip the slides 19-53) that I have found of
> this topic (that in the Haskell community is explained on the base of
> monads):
>
> http://www.slideshare.net/ScottWlaschin/railway-oriented-programming

Just read the slides, very interesting. I think it would be interesting 
to experiment with an Expected!T that holds an Algebraic!(T, Exception) 
as state, and a template like this (warning no slides no understanding, 
this is very sketchy):

template bind(alias fun) { ... }

such that given a function e.g.

int fun(string a, double b);

bind!fun is this function:

Expected!int bind!fun(Expected!string a, Expected!double b) {
   if (a.sux || b.sux) return composeExceptions(a, b);
   return fun(a.rox, b.rox);
}

There would also be bindNothrow:

Expected!int bindNothrow!fun(Expected!string a, Expected!double b) {
   if (a.sux || b.sux) return composeExceptions(a, b);
   try return fun(a.rox, b.rox);
   catch (Exception e) return e;
}

> In Bugzilla there are already requests for some Railway-Oriented
> Programming:
>
> https://issues.dlang.org/show_bug.cgi?id=6840

Nice, but I think we need Expected!T in addition to Nullable!T.

> https://issues.dlang.org/show_bug.cgi?id=6843

This is not good; trying to see if conversion would succeed is almost as 
much work as doing it. We need a

Expected!To tryTo(From, To)(From source);

which produces the error but doesn't throw it.

> I think no language extensions are needed for such kind of programming,

Agreed.

> but of course built-in tuple syntax and basic forms of pattern matching
> in switch (https://d.puremagic.com/issues/show_bug.cgi?id=596 ) improve
> the syntax and make the code more handy, handy enough to push more D
> programmers in using it.

No :o).

> For some examples of those things in a system language, this page shows
> some little examples of functional syntax for Rust:
> http://science.raphael.poss.name/rust-for-functional-programmers.html

We, too, could use a couple of full-time library designers on the roster...


Andrei