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