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

[bearophile via Digitalmars-d-announce]

Andrei Alexandrescu:

> Just read the slides, very interesting.

There are many papers, books and articles around that explain the 
same things, but that explanation is easy to understand even for 
people not used to functional programming (as I still partially 
am).


> I think it would be interesting to experiment with an 
> Expected!T that holds an Algebraic!(T, Exception) as state,

In those slides as other member of the sum type they have used an 
enumeration of possible error conditions (or at first even just 
strings of the error messages), sometimes augmented with more 
information, like:

| EmailNotValid of EmailAddress
| DbAuthorizationError of ConnectionString * Credentials
| SmtpTimeout of SmtpConnection
| SmtpBadRecipient of EmailAddress


> 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;
> }

One of the main points of using those two railways is to avoid 
exceptions.


>> 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).

Are you saying you don't want built-in tuples and that you also 
don't agree with the proposal in issue 596 and that you don't 
agree that a better syntax doesn't make monads like those 
actually handy to use? I don't understand what's controversial in 
what I have written there.

 From a syntax point of view issue 596 asks for an optional 
onMatch method, and if you want a syntax to create variables in 
switch cases. Plus support for structs and classes as variables 
to switch on.

The use of Algebraic, Nullable and Expected is very different 
(and safer) if you use them through pattern matching. The point 
is not to ape the functional languages: currently in D Nullable 
is not much safer (and not more handy) than using a null pointer.

Bye,
bearophile