Full closures for D

[David B. Held]

Janice Caron wrote:
> On Nov 7, 2007 6:44 AM, David B. Held <dheld at codelogicconsulting.com> wrote:
>>     my $base = "/path/to/dir/";
>>     my @absoluteDirs = map { $_ = $base . $_ } readdir DIR;
>>
>> Whatever you think about Perl, you have to admit that this is some
>> pretty sweet code.
> 
> Looks completely unreadable to me. It just doesn't make sense to my brain.
> 
> D is C-like, not perl-like. Please let's keep it that way.

What if I said D is BASIC-like?  Is that a good thing?  The main failure 
of Perl is that it went overboard with operators.  In fact, Perl 6 has 
so many operators that they had to create a Periodic Table of the 
Operators for it: 
http://www.ozonehouse.com/mark/blog/code/PeriodicTable.pdf.  The good 
thing about Perl is that it supports Functional style programming.

What do you think about the STL?  Good, bad, or ugly?  Did you know that 
std::foreach(), std::transform(), std::accumulate(), etc. are all 
functional-style algorithms like map()?

>> Let's look at the old imperative way to do this:
>>
>>     string base = "/path/to/dir/";
>>     string[] absoluteDirs;
>>     foreach (file; readdir(DIR))
>>     {
>>         absoluteDirs ~= base ~ file;
>>     }
> 
> This I understand.

Of course.  You can practically write this verbatim in BASIC and Pascal.

>> Now given some suitable definitions (which I demonstrate at the bottom),
>> this is what we can do in D, with Walter's new closures:
>>
>>     auto base = "/path/to/dir/";
>>     auto absoluteDirs = map((string file) { return base ~ file; },
>> readdir(DIR));
>>
>> We don't have to repeat absoluteDirs, but we still have to repeat file.
> 
> But of course. It's the name of a parameter. You ALWAYS have to repeat
> parameter names, unless the name is "this". (Or "outer" :) ). This is
> what code clear and readable. In a function parameter list, you give
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Sorry, I couldn't resist. ;>

> each paramter a name, and then in the function body, you refer to each
> paramter by name. Perfect!

But what about closures?  In the function body you're referring to 
variables that you *didn't* declare in the parameter list!

>> However, I think it would be nice to get rid of the
>> delegate type declaration altogether and git ourselves an implicit
>> delegate argument
> 
> Generally speaking, I don't. Although that said, D already supports
> variadic functions, so one could declare a function as accepting a
> tuple, and then refer to the arguments as tuple[n]. I do not believe
> this would increase readability, however, in cases where functions are
> not actually variadic!

Agreed, which is why I dislike Perl's @_ variable (which is exactly 
Tuple[n] for Perl).  But let's think about 'this'.  You know, there was 
a time when 'this' was always spelled out:

void push(Stack stack, void* item);
void pop(Stack stack);
void* top(Stack stack);
size_t size(Stack stack);

Like you said, you declare it in the parameter list, you use it in the 
function body, right?  This must mean that C is superior to C++!  Why do 
we tolerate that first variable disappearing from the function 
signatures like that?  Why, that sounds suspiciously like an implicit 
parameter!

>>     auto base = "/path/to/dir/";
>>     auto absoluteDirs = map({ return base ~ $0; }, readdir(DIR));
> 
> Yuk!
> 
> Dollar zero? Yuk! Yuk! Yuk!
> 
> Please, no!

Well, there's many ways we could name implicit parameters.  Most likely, 
it will require using numbers in some way (unless you think that letters 
are better); but if it's just the syntax that bothers you, I'm open to 
suggestions.

Dave