In article <b45gcj$22r6$1@digitaldaemon.com>, Mark Evans says... [snip]
>
>C-ish
>----------------------------
>int myfunction();
>List mylist();
>for(int i=0; i<mylist.len(); i++)
>{ mylist[i] = myfunction(mylist[i]); }
>----------------------------
>Lisp-ish
>----------------------------
>int myfunction();
>List mylist;
>mylist = map(myfunction,mylist);
>----------------------------

D-ish
alias List instance TList(int).List;
int myfunction();
List mylist;
mylist = mylist.map(myfunction);


But such could would never work, because how can you map over a function that
takes nothing and give back ints? ;-)
[snip]

In article <b45oa0$2858$1@digitaldaemon.com>, Dan Liebgold says...
>
>In article <3E6648D5.3030002@viasic.com>, Bill Cox says...
>>
>>> It's all about choices.  If a programmer wants to write C for-loops instead of using map, he can do that.  I see no conflict here.  In fact D has the opportunity to introduce to C folks choices that they never had before.  They might thank you for that.
>>
>>Or they might run screaming and naked for the woods.
>>
>>Bill
>>
>>
>
>Why naked, exactly? ;)
>
>But back to Mark's point, if D did implement builtin support for constructs like "map" over lists, it would really only be a win.  The old for-loop way of doing things is not going to be eliminated, and as new programmers catch on to the map (for example) idea, whey will migrate over and become more productive.


D already has support for higher-order functions. The Deimos Template Library has such functions available for arrays. You can download it from www.minddrome.com/produtos/d under the Deimos link. Beware compiler version bugs, this version (0.0.1) works with dmd 0.50 (perhaps with some versions later). The next version will work with dmd 0.58 and new syntax for function types.


>Built in garbage collection throws open the doors to all sorts of more expressive ways of doing things, and meanwhile the C-ish constructs will always be available.  D can really do everything right that the STL is attempting to do, without the negative impact to understandability and implementational complexity.
>
>Dan

> But such could would never work, because how can you
> map over a function that takes nothing and give back ints? ;-)

My "-ish" qualifier disclaimed all accuracy.  BTW one maps over a list, not a function.

>D already has support for higher-order functions.

This dubious claim implies that D supports first-class functions (which are required for HOFs).  Last I heard, Walter was only recently working on such matters:   http://www.digitalmars.com/drn-bin/wwwnews?D/11250

And we had a whole thread about first-class functions, too.  Nobody told me that D already supports them.  I would have celebrated.


The FC++ papers are worth reading because they discuss the particular deficiencies of C++ which make the functional paradigm hard to support.  In D we can address them directly instead of with FC++'s workarounds.

It's also worth noting that FC++ does not claim to be complete, just as close as you can get in ISO C++:

"Despite FC++’s abilities, it is not a complete functional language with polymorphism and type inference. One of the main drawbacks is that variable types have to be declared explicitly. Although FC++ type inference eliminates the need for typing intermediate results, if the final result of an FC++ expression needs to be stored, the variable should be explicitly typed. This restriction will hopefully be removed with the addition of the typeof keyword in the next revision of the C++ standard."

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:b48bcv$m4p$1@digitaldaemon.com...
> This dubious claim implies that D supports first-class functions (which
are
> required for HOFs).  Last I heard, Walter was only recently working on
such
> matters:   http://www.digitalmars.com/drn-bin/wwwnews?D/11250
>
> And we had a whole thread about first-class functions, too.  Nobody told
me that
> D already supports them.  I would have celebrated.

They are in the latest version. I'm interested in any deficiencies in it.

Do you really need the recursing boolean in the TRange type?  You'd be better off just writing a more robust test in the Intersects method and not having it recurse.  Or make a private Intersects_NoRecurse method;  just don't saddle all instances with an extra bool.

Sean

"Daniel Yokomiso" <Daniel_member@pathlink.com> wrote in message news:b47srh$cn9$1@digitaldaemon.com...
> D already has support for higher-order functions. The Deimos Template
Library
> has such functions available for arrays. You can download it from www.minddrome.com/produtos/d under the Deimos link. Beware compiler
version
> bugs, this version (0.0.1) works with dmd 0.50 (perhaps with some versions
> later). The next version will work with dmd 0.58 and new syntax for
function
> types.

1)
Your definition and presention of language expressiveness as the level of
possible abstractions with metalinguistic abstraction as the climax, is
excellent.

Obviously with metalinguistic abstraction problems can be expressed more directly, which was Ilya's definition of expressiveness. Furthermore metalinguistic abstraction is good example for the downsides of language expressiveness.


2)
> D is mostly much better in this regard (function literals, nested
> functions, garbage collection, etc.), but there's one area where it
> lags behind C++: templates.  For example, to simply declare a set of[...]

Very right. Recently, I did some D template programming. Definitely the cumbersome usage of templates would drove away programmers.

I think, exploring possible applications of templates (e.g. a graph lib) will increase the usefulness of D templates over time. But C++ templates are not at their best, too. Walter could make using templates more terse and nicer at some later time, when people have more experience with D templates.

I agree, D has more abstractions than C++. I guess, that compared with more research oriented languages it is worse [worse is better?] in at least these areas:

- procedural abstraction:
think of inout parameters or function literals:
"function (SubClass)" cannot be assigned to function literal of type
"function (BaseClass)"

- Object abstraction: E.g.: Sather fixes the quirks of OOP much better.

- "Concurrent process": D concurrent process model is like the simplistic one that Java(tm) uses.



3)
> Let's conclude with a nice little paper by MacLennan (1997) about the effect of aesthetics in the context of language design: [...]

I want to understand it this way: Do not hide language deficiencies with nice looking syntax sugar. Better improve the design. The design is best when it looks nice.


Farmer.




>http://www.info.ucl.ac.be/~pvr/
>(Concepts, Techniques, and Models of Computer Programming, which was
>already mentioned but is worth repeating over and over.  The kernel
>language approach is something that would be healthy to be interested
>in for most people that would like to call themselves computer
>scientists.)

Huh, glad I prefer not calling myself a computer scientists; it saves me reading over 1000 pages ;-)

In article <b49hcj$1daf$1@digitaldaemon.com>, Sean L. Palmer says...
>
>Do you really need the recursing boolean in the TRange type?  You'd be better off just writing a more robust test in the Intersects method and not having it recurse.  Or make a private Intersects_NoRecurse method;  just don't saddle all instances with an extra bool.
>
>Sean
>

[snip]

It's just a hack to avoid recursion on contracts. It's used to enforce symmetrical properties of operations. In the Eiffel library there are lot's of examples of such postconditions.

Can it be done in a way that affects performance and memory usage less?

Sean

"Daniel Yokomiso" <Daniel_member@pathlink.com> wrote in message news:b4crih$am4$1@digitaldaemon.com...
> In article <b49hcj$1daf$1@digitaldaemon.com>, Sean L. Palmer says...
> >
> >Do you really need the recursing boolean in the TRange type?  You'd be better off just writing a more robust test in the Intersects method and
not
> >having it recurse.  Or make a private Intersects_NoRecurse method;  just don't saddle all instances with an extra bool.
> >
> >Sean
> >
>
> [snip]
>
> It's just a hack to avoid recursion on contracts. It's used to enforce symmetrical properties of operations. In the Eiffel library there are
lot's of
> examples of such postconditions.

Sean L. Palmer wrote:
> Can it be done in a way that affects performance and memory usage less?

debug private boolean recursing = false;

in and out contracts, and the contents of assert, aren't run through the semantic phase when -release.