> It's just syntax. Eliminating syntax noise is fine. Code should look
> like what it does.

Not if "eliminating noise" equals to making things harder to understand.

When you say (int x) { return x; } it's clear about what it is, a _function_ without name.

On 07/19/2012 05:03 PM, Petr Janda wrote:
>> It's just syntax. Eliminating syntax noise is fine. Code should look
>> like what it does.
>
> Not if "eliminating noise" equals to making things harder to understand.
>

Harder to understand to whom? Optimizing stuff for beginners usually
makes it a PITA to work with.

> When you say (int x) { return x; } it's clear about what it is, a
> _function_ without name.

That expression looks eg. like this in Haskell:
\x->x

(If the type of x cannot be inferred to Int, then it is (\x->x)::Int->Int)

I agree that there is some non-uniformity. It should be possible to use
=> in named function declarations.

On 07/19/2012 04:39 PM, Petr Janda wrote:
> On Thursday, 19 July 2012 at 14:31:53 UTC, travert@phare.normalesup.org
> (Christophe Travert) wrote:
>> "q66" , dans le message (digitalmars.D:172716), a écrit :
>>> (so instead of calling a(b(c(d(e(f))))) you can just call a.b.c.d.e.f())
>>
>> rather f.e.d.c.b.a, if you omit the empty parenthesis after each letter
>> (but f).
>
> Ok, but the empty parenthesis is is important,

It is not.

> it tells you about whether it's a an object or a function.
>

(No, it does not. And even if it would, )

There is usually nothing that makes this distinction terribly
important.

Furthermore, to learn the meaning of a symbol, being able to look at its documentation or declaration is fully sufficient / required.

> It's another thing I hate about Ruby is that a parenthesis enforcement
> is weak.

I take that to mean you dislike ruby's function call syntax. That is a
very poor thing to dislike, there is no objective justification for it.

On Thu, Jul 19, 2012 at 9:03 AM, Petr Janda <janda.petr@gmail.com> wrote:

> It's just syntax. Eliminating syntax noise is fine. Code should look
>> like what it does.
>>
>
> Not if "eliminating noise" equals to making things harder to understand.
>
> When you say (int x) { return x; } it's clear about what it is, a
> _function_ without name.
>

Nothing is stopping someone from being explicit with their types like that, of course.

Here is the original code written in a way that is probably more familiar to you:

auto r = map!((int x) { to!(string)(x); })(uniq(sort([5, 3, 5, 6, 8])));

Personally I find the original version to be much more readable but that does require a basic knowledge of D's syntax. People coming from other languages are free to use the more classic way if they wish.  It's better to learn idiomatic usage of a language, though, instead of forcing it to be a language you are more comfortable in.

Regards,
Brad Anderson

On Thu, Jul 19, 2012 at 9:20 AM, Brad Anderson <eco@gnuk.net> wrote:

> On Thu, Jul 19, 2012 at 9:03 AM, Petr Janda <janda.petr@gmail.com> wrote:
>
>>  It's just syntax. Eliminating syntax noise is fine. Code should look
>>> like what it does.
>>>
>>
>> Not if "eliminating noise" equals to making things harder to understand.
>>
>> When you say (int x) { return x; } it's clear about what it is, a
>> _function_ without name.
>>
>
> Nothing is stopping someone from being explicit with their types like that, of course.
>
> Here is the original code written in a way that is probably more familiar to you:
>
> auto r = map!((int x) { to!(string)(x); })(uniq(sort([5, 3, 5, 6, 8])));
>
>
Ehm...forgot the return:

auto r = map!((int x) { return to!(string)(x); })(uniq(sort([5, 3, 5, 6,
8])));


> Personally I find the original version to be much more readable but that does require a basic knowledge of D's syntax. People coming from other languages are free to use the more classic way if they wish.  It's better to learn idiomatic usage of a language, though, instead of forcing it to be a language you are more comfortable in.
>
> Regards,
> Brad Anderson
>

On 07/19/2012 05:20 PM, Brad Anderson wrote:
> On Thu, Jul 19, 2012 at 9:03 AM, Petr Janda <janda.petr@gmail.com
> <mailto:janda.petr@gmail.com>> wrote:
>
>         It's just syntax. Eliminating syntax noise is fine. Code should look
>         like what it does.
>
>
>     Not if "eliminating noise" equals to making things harder to understand.
>
>     When you say (int x) { return x; } it's clear about what it is, a
>     _function_ without name.
>
>
> Nothing is stopping someone from being explicit with their types like
> that, of course.
>
> Here is the original code written in a way that is probably more
> familiar to you:
>
> auto r = map!((int x) { to!(string)(x); })(uniq(sort([5, 3, 5, 6, 8])));
                         ^
                       return
>
> Personally I find the original version to be much more readable but that
> does require a basic knowledge of D's syntax. People coming from other
> languages are free to use the more classic way if they wish.  It's
> better to learn idiomatic usage of a language, though, instead of
> forcing it to be a language you are more comfortable in.
>
> Regards,
> Brad Anderson

On Thursday, 19 July 2012 at 14:51:59 UTC, Timon Gehr wrote:
>> On another note, (copied from wikipedia)
>>
>> foreach(item; set) {
>> // do something to item
>> }
>>
>> what's with the lax syntax being allowed?
>
> s/lax/to the point/
>
>> Shouldn't it be at least specified "auto item"?
>>
>
> Why on earth would that be the case?
>
>> I'm sorry I don't mean to be a criticizer, but it seems to me that D is
>> trying to be a dynamic-like compiled language way too hard.
>
> It's just syntax. Eliminating syntax noise is fine. Code should look
> like what it does.

Additionally, allowing to omit auto is actually consistent with the rest of the language, which also allows you to not explicitly write it if the code doesn't become ambiguous (for example, you don't need to do "immutable auto").

David

On 07/19/2012 08:03 AM, Petr Janda wrote:
>> It's just syntax. Eliminating syntax noise is fine. Code should look
>> like what it does.
>
> Not if "eliminating noise" equals to making things harder to understand.
>
> When you say (int x) { return x; } it's clear about what it is, a
> _function_ without name.

Others beat me to it but the anonymous function can be written more completely as

  function string(int x) { return x.to!string(); }

(Or 'delegate' depending on the situation.)

Allow me to add a take(..., 2) to the entire expression, which is to me the strongest reason why UFCS can be great:

    writeln(take(map!(function string(int x) { return x.to!string(); })(uniq(sort([5, 3, 5, 6, 8]))), 2));

The problem is, the 2 is related to take() but they are too far apart above. UFCS puts them together:

  a_long_expression.take(2)

I don't like UFCS everywhere but it is very helpful in many cases.

Ali

On Thu, 19 Jul 2012 14:44:20 +0000 (UTC)
travert@phare.normalesup.org (Christophe Travert) wrote:

> "Petr Janda" , dans le message (digitalmars.D:172727), a écrit :
> > On Thursday, 19 July 2012 at 14:31:53 UTC, travert@phare.normalesup.org (Christophe Travert) wrote:
> >> "q66" , dans le message (digitalmars.D:172716), a écrit :
> >>> (so instead of calling a(b(c(d(e(f))))) you can just call a.b.c.d.e.f())
> >>
> >> rather f.e.d.c.b.a, if you omit the empty parenthesis after
> >> each letter
> >> (but f).
> > 
> > Ok, but the empty parenthesis is is important, it tells you about whether it's a an object or a function.
> > 
> > It's another thing I hate about Ruby is that a parenthesis enforcement is weak.
> 
> property (functions that behaves like fields) don't require empty parenthesis. This feature has been extended to all function, leading to the current situation. Some people would like this to disappear, and enforce strict property.

That's already happening. It's just that for the moment you have to pass -property into DMD. Then it'll enforce "Function calls always need parens, propertied always omit parens". Supposedly, this behavior will become the default at some point.

On 2012-07-19 16:39, Petr Janda wrote:

> It's another thing I hate about Ruby is that a parenthesis enforcement
> is weak.

I love that :)

-- 
/Jacob Carlborg