undefined | Better HN

0 pointsenneff6y ago0 comments

You can tell if it’s a function call or a generic type based on where it is used; the local context. Function calls are either statements or expressions. Types appear in declarations.

0 comments

shhsshs6y ago

    a := Bar(baz)(buzz)

Is Bar a `func(some) func(thing) other` or is it a `func(type T)(some) other`? You need to know what “baz” is to be able to tell.

agrajag6y ago

Yeah, it's ambiguous, but be realistic: how often are you calling a function with a function return just to invoke that directly?

You usually won't see much of either sinice the type argument is only necessary when it can't be inferred.

imtringued6y ago

In Haskell this happens every time you call a function with two or more arguments.

helper6y ago

Normally you wouldn't write that since the compiler will be able to infer the baz type based on buzz (assuming this is a call to a generic function).

weberc26y ago

That's a fair point, but there are still times when being explicit is useful or even required, and it doesn't hurt to use syntax that disambiguates easily.

weberc26y ago

Reverse(x)(y)

Is that a function that returns a function or a generic Reverse function specialized over type x, invoked with argument y?

enneffOP6y ago

When a function returns a function, you rarely just call it immediately in Go. But even if that were common (and maybe it would become common with generics? I'd have to think that through) it is uncommon to have a type name as unrecognizable as 'x'.

I've always been a big advocate for unambiguous, clear code, especially in Go, but I don't see a big potential for confusion here.

weberc26y ago

I don’t want to overstate the problem; I think it is a bit less readable. While types are rarely so indescriptive as “x”, they are often still plenty indescriptive, and I don’t know why we should introduce a syntax that depends on the clarity of type names or the frequency of other potentially ambiguous constructs when we could use a syntax that is unambiguous with no caveats and friendlier/more familiar to the larger body of programmers who have not yet tried Go.

j / k navigate · click thread line to collapse

0 comments

shhsshs6y ago

    a := Bar(baz)(buzz)

Is Bar a `func(some) func(thing) other` or is it a `func(type T)(some) other`? You need to know what “baz” is to be able to tell.

agrajag6y ago

Yeah, it's ambiguous, but be realistic: how often are you calling a function with a function return just to invoke that directly?

You usually won't see much of either sinice the type argument is only necessary when it can't be inferred.

imtringued6y ago

In Haskell this happens every time you call a function with two or more arguments.

helper6y ago

Normally you wouldn't write that since the compiler will be able to infer the baz type based on buzz (assuming this is a call to a generic function).

weberc26y ago

That's a fair point, but there are still times when being explicit is useful or even required, and it doesn't hurt to use syntax that disambiguates easily.

weberc26y ago

Reverse(x)(y)

Is that a function that returns a function or a generic Reverse function specialized over type x, invoked with argument y?

enneffOP6y ago

I've always been a big advocate for unambiguous, clear code, especially in Go, but I don't see a big potential for confusion here.

weberc26y ago

j / k navigate · click thread line to collapse