Functional programming in D and some reflexion on the () optionality.

Christophe Travert travert at phare.normalesup.org
Tue Aug 7 00:51:31 PDT 2012


Timon Gehr , dans le message (digitalmars.D:174361), a écrit :
> On 08/06/2012 09:42 PM, Christophe Travert wrote:
>> Timon Gehr , dans le message (digitalmars.D:174329), a écrit :
>>> On 08/06/2012 07:20 PM, Christophe Travert wrote:
>>>>
>>>> What do you think?
>>>
>>> Creating byzantine language rules to cater to unimportant or
>>> non-existent use cases will slaughter the language.
>>
>> What exactly do you consider byzantine here, whatever that means?
> 
> byzantine means involved. Why deliberately make the language more
> complicated for no gain whatsoever?
> 
>> Implicit cast is an already defined feature. Clarifying the way
>> parenthesis-less function calls exist by adding a casting rule is making
>> the langage more simple IMHO,
> 
> I don't know what to respond to this. Are you serious?
> 
>> and might improve the current position. Of
>> course, if your point is that parenthesis-less function calls are
>> unimportant or non-existent,
> 
> It isn't. My point is that there actually is no issue that would
> require some complex solution.

Misha's post reminded me that parenthesis-less function call rules are 
not that complicated, although I think he omitted one or a few things 
like assigning a function to an auto parameter or passing a function to 
a template. I agree that the situation is sufficent can be kept that 
way, and that there is no big issue.

However, I had the impression from deadalnix' post that what he wanted 
to discuss was something that would make function real first class 
types, that you could use, assign, etc, without using function pointers 
(although there have to be function pointers internally of course). If 
foo is a function, I think making "auto a = foo;" be a function is 
something that is expected in a langage where function are first class 
types. Thus, making parenthesis-less function expressions be functions. 
I maintain that I don't think that one implicit cast rule is not more 
complicated than the lines Misha used to describe parenthesis-less 
function call + some probably missing cases.

I understand the D language does not like implicit cast. The approach 
was to make as few implicit casts as possible and loosen the rule 
parsimoniously to avoid to create mess. That rule may be more 
important than making function first-class types in D, or defining 
parenthesis-less function call as an implicit cast.

Now, a little off-topic, implicit cast and rewrites are already 
everywhere in the language. Many feature are already attempts something, 
if it does not work, rewrite and attempt again. That's how the compiler 
works in many cases from what I briefly caught. Describing as many 
language features as possible as rewrites is a way that may make the 
language easier, and provides a way to describe feature interactions 
too, by prioritizing or restricting combinaisons of rewrites. 
Independently of parenthesis-less function call issue, I think that this 
may be a way to redefine the language, and open doors to clarify a few 
tricky issues. I may very well be mistaken, but I think this approach 
should be considered when discussing language features.

-- 
Christophe



More information about the Digitalmars-d mailing list