higher-order functions

[spir]

On Sun, 31 Oct 2010 20:24:59 -0600
Rainer Deyke <rainerd at eldwood.com> wrote:

> On 10/31/2010 16:57, Simen kjaeraas wrote:
> > For very short functions, strings are better, because of the length of
> > the 'return' keyword. Had D instead always returned the result of the
> > last line of a function (unless specified to be of void return type),
> > map/filter/reduce would likely not take strings.
> 
> In other words: function literals in D are too verbose to be convenient.
>  This language-level shortcoming is plastered over at the library level.

True. But it is very hard to find a notation that is at the same time:
* compact
* general
* clear
In many language communities, there are endless discussions of this topic. One common issue is the contradiction between compact and general. Oftentimes people come up with a cooool format without realising they only consider their little egotic use case (typically one single arg, one single expr, etc...).
Also, the need for clarity is difficult to achieve for historical reasons in languages of the C & Pascal lines: namely that func defs (and type defs) were basically special cased (because then they were not first-class elements):
	string Text (...) {...}
instead of
	Text = func string (...) {...}
This makes theoretically superior formats difficult to integrate nicely with the general syntax of the language. The solution is indeed to get rid of the legacy syntax and use only literals (1), but...


Denis

(1) Once the bug that prevents using literals in func defs, using the form
	auto f = function type (params) {block}
is solved, we do not need the legacy format at all anymore.
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com