On Tuesday, 24 September 2013 at 11:32:18 UTC, renoX wrote:
> I'm not sure you understood my point: a 'normal' function takes inputS and produce an output, in the notation: a,b->c you can clearly see the inputS and the output with a minimum of 'syntax noise' around them.
> In the notation a -> b -> c, the 'syntax noise' is bigger (those arrows between the input parameters are much more 'heavy on the eye' than a quote), and what does it bring?
> Nothing..
>
> It's the notation which makes the function type less readable which I consider a mistake.
>

You are putting artificial barrier here.

a -> b -> c is a function that take a as parameter and return a function that take b as parameter and return c. The concept of multiple parameters and stuff like that exists only in your mind. You try to map a concept you have in your mind in the language when it DO NOT exist in the language.

On 20/09/13 20:53, H. S. Teoh wrote:
> Sad to say, I encountered a good number of Phobos bugs caused by the
> conflation between built-in arrays and ranges. Code would inadvertently
> assume array behaviour on ranges, and break when you pass in a non-array
> range. Some of these have been fixed; I'm pretty sure there are still
> more lurking around.

In my case, I discovered a number of bugs that stemmed from unittests where the default range type used was an array.

In that case, it wasn't so much the conflation of range and container, but the fact that arrays are random-access ranges and so have the maximal set of range properties -- so code that _theoretically_ should have worked with input ranges was actually failing, because it wasn't being tested.

> Actually, it helps you understand the const(T[]) case. To iterate over a
> const array, you need a range over it (i.e., a slice); and indeed,
> writing arr[] on an array of type const(T[]) gives you a tail-const
> slice of type const(T)[], which *is* an iterable range.
>
> The confusion really just stems from the conflation between T[] and a
> range over T[] in the non-const case.

Ahh, OK.  You're right, that does help.  Thank you! :-)

On Tuesday, 24 September 2013 at 13:04:10 UTC, deadalnix wrote:
> On Tuesday, 24 September 2013 at 11:32:18 UTC, renoX wrote:
>> I'm not sure you understood my point: a 'normal' function takes inputS and produce an output, in the notation: a,b->c you can clearly see the inputS and the output with a minimum of 'syntax noise' around them.
>> In the notation a -> b -> c, the 'syntax noise' is bigger (those arrows between the input parameters are much more 'heavy on the eye' than a quote), and what does it bring?
>> Nothing..
>>
>> It's the notation which makes the function type less readable which I consider a mistake.
>>
>
> You are putting artificial barrier here.
>
> a -> b -> c is a function that take a as parameter and return a function that take b as parameter and return c. The concept of multiple parameters and stuff like that exists only in your mind. You try to map a concept you have in your mind in the language when it DO NOT exist in the language.

A language is not something set in stone! If the design of a language requires unecessary visual noise, I dislike it, this is not as bad as Lisp, but it is still suboptimal.

This is not the only 'visual noise' in Haskell: for example Idris replaced '::' by ':', a good change IMHO.

renoX

On Tuesday, 24 September 2013 at 13:46:16 UTC, renoX wrote:
> On Tuesday, 24 September 2013 at 13:04:10 UTC, deadalnix wrote:
>> On Tuesday, 24 September 2013 at 11:32:18 UTC, renoX wrote:
>>> I'm not sure you understood my point: a 'normal' function takes inputS and produce an output, in the notation: a,b->c you can clearly see the inputS and the output with a minimum of 'syntax noise' around them.
>>> In the notation a -> b -> c, the 'syntax noise' is bigger (those arrows between the input parameters are much more 'heavy on the eye' than a quote), and what does it bring?
>>> Nothing..
>>>
>>> It's the notation which makes the function type less readable which I consider a mistake.
>>>
>>
>> You are putting artificial barrier here.
>>
>> a -> b -> c is a function that take a as parameter and return a function that take b as parameter and return c. The concept of multiple parameters and stuff like that exists only in your mind. You try to map a concept you have in your mind in the language when it DO NOT exist in the language.
>
> A language is not something set in stone! If the design of a language requires unecessary visual noise, I dislike it, this is not as bad as Lisp, but it is still suboptimal.

I think that -> is neither unnecessary nor noise. After having played with Haskell for a while, I actually find the syntax of D unnecessarily redundant.

>
> This is not the only 'visual noise' in Haskell: for example Idris replaced '::' by ':', a good change IMHO.

That is probably because ':' is the list append operator already.

>
> renoX

On Tuesday, 24 September 2013 at 14:15:12 UTC, Max Samukha wrote:
[cut]
> I think that -> is neither unnecessary nor noise. After having played with Haskell for a while, I actually find the syntax of D unnecessarily redundant.

Oh, D is hardly a good example for syntax! Better than C++ doesn't say much..
That said, I don't see how one could prefer 'a -> b -> c' over 'a,b -> c' in this case..

>> This is not the only 'visual noise' in Haskell: for example Idris replaced '::' by ':', a good change IMHO.
>
> That is probably because ':' is the list append operator already.

Yes, it's the other way round in Idris, but for once I prefer D's operator '~': list appending is common enough that it deserves a proper operator not a doubled one :: like in Idris or other (Scala?).

renoX

On Tuesday, 24 September 2013 at 14:24:48 UTC, renoX wrote:
> On Tuesday, 24 September 2013 at 14:15:12 UTC, Max Samukha wrote:
> [cut]
>> I think that -> is neither unnecessary nor noise. After having played with Haskell for a while, I actually find the syntax of D unnecessarily redundant.
>
> Oh, D is hardly a good example for syntax! Better than C++ doesn't say much..

Ok.

> That said, I don't see how one could prefer 'a -> b -> c' over 'a,b -> c' in this case..

In case of Haskell, it is not a matter of preference. The syntax follows from the language semantics and I don't see how it can be different and better at the same time. (a, b) -> c means a function that maps a pair to an object (the same as ((,) a b) -> c). a -> b -> c, parens around b -> c omitted thanks to right associativity, means a function that maps an object to a function. How does a, b -> c fits in this picture?

>
>>> This is not the only 'visual noise' in Haskell: for example Idris replaced '::' by ':', a good change IMHO.
>>
>> That is probably because ':' is the list append operator already.
>
> Yes, it's the other way round in Idris, but for once I prefer D's operator '~': list appending is common enough that it deserves a proper operator not a doubled one :: like in Idris or other (Scala?).
>

Sadly, I don't know Idris or Scala.

Now we are talking about subjective preferences, which is an exercise in futility. :)

> renoX