I dislike the idea of using $ and @ because I don't want to add new symbols
to the language, if it can be avoided. In general I'd argue that Go tends
to use keywords instead of symbols to convey meaning - e.g. we don't write
`a -> b`, but `func(a) b`. There are exceptions (pointers are a big one) of
course, but Go is still pretty light on symbols.
I think the overuse of symbols to convey semantics is a huge reason that I
find perl and Haskell so unreadable, personally.
On Thu, Jul 16, 2020 at 2:23 PM Jan Mercl <0xj...@gmail.com> wrote:
> Resending to the list after mistakenly replied off list. My apologies.
>
> ----
>
> On Wed, Jul 15, 2020 at 10:59 PM Ian Lance Taylor <i...@golang.org> wrote:
>
> > Thanks for the detailed writeup.
>
> It might have been too detailed and suffered from low information
> density. Let me amend it with a tl;dr:
>
> ----
>
> 1. The main idea is to remove the parenthesized type list while
> keeping exactly 100% of the semantics of the original draft.
>
> 2. $T declares a type parameter. (For the mnemotechnical clue cf. the
> POSIX shell env vars or Tcl vars, to name a few.)
>
> 3. U@V, u-at-v, instantiates generic type U using type argument V.
> (cf. value instance at address, now type-parameter instantiated at
> type)
>
> 4. Instantiating a generic type W with a type parameter X that is
> declared in the same place means plugging 2 into 3, hence W@$X.
>
> ----
>
> The particular syntax is less important here. But it seems to remove
> the parsing ambiguities of the original draft.
>
> Motivational example of a function signature:
>
> Original:
>
> func Keys(type K comparable, V interface{})(m map[K]V) []K
>
> Alternative:
>
> func Keys(m map[$K comparable]$V) []K
>
> ----
>
> > I'm a bit concerned about name
> > scoping.
>
> Then I must have miscommunicated something. The intent is to have the
> type parameters live in the exact same scope as in the original draft.
> The comments about $T and T in the same scope just tried to say that
> there cannot be both a type parameter $T and other named, but
> different thing T in the same scope. Exactly as in the original, but
> there the $ sign does not exist, so there's nothing to talk about in
> this regard.
>
> > Also about the fact that constraints can apparently show up
> > anywhere; is that always going to work?
>
> In the original draft a type parameter constraint appears only once,
> next to the type parameter declaration. In the alternative one is the
> same, only once, next to the type parameter declaration. Hence I
> expect the alternative version to work in exactly the same way.
>
> > And I don't think that
> > Vector@$T is going to be all that intuitive for anybody to read.
>
> This is subjective by definition, but I'd like to point out something
> different. We write and read code not by intuition but by using quite
> precise knowledge about the grammar and semantics of the language.
>
> Intuition can of course help us to learn that necessary level of
> knowledge to become a fluent language user.
>
> f(x), for example, is intuitively a function call, because we write
> f(x) in math classes in school.
>
> a+b is intuitively an addition, because that's how we write it in math.
>
> a*b is not very intuitive, because we write multiplication in math as
> ab, a.b, axb. (The last has at least some visual resemblance to the
> asterisk, admitted.)
>
> Okay, now that we know the correct multiplication symbol, what an
> unary multiplication is intuitively supposed to mean and why it
> actually denotes dereferencing a pointer or pointer-ness of a type?
>
> a^b is intuitively exponentiation, because that's how we write it in
> math. But it's actually a xor b in Go.
>
> The conclusion is, sometimes intuition helps in learning the language,
> other times it can hurt. The only thing that matters at the end of the
> day is knowing the language and that's no more connected much with
> intuition.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAA40n-WEv4uoa0eSyE5M2yimn6tPJ7_vHFxPW5W2mCk1zTZfmg%40mail.gmail.com
> .
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfE5M%2BqQ7czhSULbpcfHwcO9QOF98Uw6P18f-CUP6ia80A%40mail.gmail.com.
