FAQ
I'm still actively learning Go, but I've noticed that the code can become
quite hairy. I've been thinking of ways to simplify the code without losing
meaning and the map type seems like a good, verbose example.

     var dictionary map[string]string

this could be:

     var dictionary[string]string

This example is basically an extension of the `slice` type. If a type is
given between the brackets, then it should be declared as a `map`, if not
then it should be a `slice`.

To emphasize, when defining an array or string slice, you don't do:

     var array array[10]string
     var stringSlice slice[]string

instead you do:

     var array [10]string
     var stringSlice []string

So really it would follow that we do the same with maps.


Thoughts?

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Jan Mercl at Nov 23, 2013 at 5:59 am
    Then

             var foo [bar]baz

    is an array if bar is an integer constant but a map if bar is a type name.
    The proposal enables hard to read code.

    -j

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brenden at Nov 23, 2013 at 6:47 am
    If readability is the issue, then what can you say for declaring arrays and
    slices?

    Also, I'm wondering now, is it practical to use anything other than a
    string for the key? How might you use something other than a string/int?
    On Friday, November 22, 2013 9:52:12 PM UTC-8, Jan Mercl wrote:

    Then

    var foo [bar]baz

    is an array if bar is an integer constant but a map if bar is a type name.
    The proposal enables hard to read code.

    -j
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dan Kortschak at Nov 23, 2013 at 6:53 am
    e.g.

    type Point struct{ x, y float64 }

    var pc map[Point]int
    On 23/11/2013, at 5:17 PM, "Brenden" wrote:

    Also, I'm wondering now, is it practical to use anything other than a string for the key? How might you use something other than a string/int?
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kevin Gillette at Nov 23, 2013 at 7:10 am

    On Friday, November 22, 2013 10:52:12 PM UTC-7, Jan Mercl wrote:
    var foo [bar]baz is an array if bar is an integer constant but a map if
    bar is a type name.
    That's the first thing that came to mind for me as well -- it's not only a
    readability issue, it's syntactic ambiguity that can only be resolved after
    dependent types and constants have been evaluated.
    On Friday, November 22, 2013 11:47:04 PM UTC-7, Brenden wrote:

    If readability is the issue, then what can you say for declaring arrays
    and slices?

    arrays, slices, and maps are all current syntactically unambiguous. Code
    some more in Go for a while, and there won't be any confusion or
    readability issues.
    On Friday, November 22, 2013 10:40:56 PM UTC-7, Brenden wrote:

    I'm still actively learning Go, but I've noticed that the code can become
    quite hairy.
    What other code examples do you find to be hairy?

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brenden at Nov 23, 2013 at 9:33 am

    On Friday, November 22, 2013 11:10:04 PM UTC-8, Kevin Gillette wrote:
    On Friday, November 22, 2013 10:52:12 PM UTC-7, Jan Mercl wrote:

    var foo [bar]baz is an array if bar is an integer constant but a map if
    bar is a type name.
    That's the first thing that came to mind for me as well -- it's not only a
    readability issue, it's syntactic ambiguity that can only be resolved after
    dependent types and constants have been evaluated.
    Ok, lots of big words here. How is what I'm proposing any less ambiguous
    than what a slice currently is? Also, dependent types...sounds
    familiar...`somevar := anothervar`...what type is `somevar`?

    On Friday, November 22, 2013 11:47:04 PM UTC-7, Brenden wrote:

    If readability is the issue, then what can you say for declaring arrays
    and slices?

    arrays, slices, and maps are all current syntactically unambiguous. Code
    some more in Go for a while, and there won't be any confusion or
    readability issues.
    On Friday, November 22, 2013 10:40:56 PM UTC-7, Brenden wrote:

    I'm still actively learning Go, but I've noticed that the code can become
    quite hairy.
    What other code examples do you find to be hairy?
    There's a lot of syntactic cruff (eg: the topic at hand)

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Benjamin Measures at Nov 23, 2013 at 11:31 am

    On Saturday, 23 November 2013 09:33:35 UTC, Brenden wrote:

    How is what I'm proposing any less ambiguous than what a slice currently
    is?
    What do you find ambiguous about slices?

    On Friday, November 22, 2013 11:10:04 PM UTC-8, Kevin Gillette wrote:
    What other code examples do you find to be hairy?
    There's a lot of syntactic cruff (eg: the topic at hand)
    >

    It is important to know the difference between a slice and a map not least
    because they behave differently. For example, iteration order over maps is
    not specified and is not guaranteed to be the same from one iteration to
    the next (and is indeed pseudo-random in this implementation to enforce
    this point).

    Syntax that allows you to locally determine this not is not cruft.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brenden at Nov 24, 2013 at 5:27 am

    On Saturday, November 23, 2013 3:30:47 AM UTC-8, Benjamin Measures wrote:
    On Saturday, 23 November 2013 09:33:35 UTC, Brenden wrote:

    How is what I'm proposing any less ambiguous than what a slice currently
    is?
    What do you find ambiguous about slices?
    It's more ambiguous than a map declaration because it doesn't explicitly
    define its type like map does.
    On Friday, November 22, 2013 11:10:04 PM UTC-8, Kevin Gillette wrote:
    What other code examples do you find to be hairy?
    There's a lot of syntactic cruff (eg: the topic at hand)
    It is important to know the difference between a slice and a map not least
    because they behave differently. For example, iteration order over maps is
    not specified and is not guaranteed to be the same from one iteration to
    the next (and is indeed pseudo-random in this implementation to enforce
    this point).
    Sure they work differently, but I know the difference between an array and
    a slice based on a VERY slight difference in their respective declarations
    (ie: array defines a length and slice doesn't).
    Syntax that allows you to locally determine this not is not cruft.
    It is cruft if it's absence would not change the meaning of the
    declaration. It's presence does not add any meaning; it's redundant.


    Thanks for your time and thoughts!

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Benjamin Measures at Nov 24, 2013 at 3:54 pm

    On Sunday, 24 November 2013 05:27:37 UTC, Brenden wrote:
    On Saturday, November 23, 2013 3:30:47 AM UTC-8, Benjamin Measures wrote:

    What do you find ambiguous about slices?
    It's more ambiguous than a map declaration because it doesn't explicitly
    define its type like map does.
    Slices can be thought of as "growable arrays" and can be used in place with
    very little difference. Since they are so similar in usage, they are also
    similar in declaration: slice types are declared similarly to arrays but
    with no length.

    There is no ambiguity since what appears to be an array type declaration
    with no length must always be a slice declaration. It is clearly defined.

    Syntax that allows you to locally determine this not is not cruft.
    It is cruft if it's absence would not change the meaning of the
    declaration. It's presence does not add any meaning; it's redundant.
    Take the following example:
    var v [string]int

    Now, this is a map, isn't it? Turns out,
    not: http://play.golang.org/p/puXlQccUhy

    That is the very definition of ambiguous.

    Thanks for your time and thoughts!
    >

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kevin Gillette at Nov 23, 2013 at 12:34 pm

    On Saturday, November 23, 2013 2:33:35 AM UTC-7, Brenden wrote:
    How is what I'm proposing any less ambiguous than what a slice currently
    is?
    I'm using the term 'ambiguous' in a technical sense here***. The Go
    language, as specified, has absolutely no syntactic ambiguity between map,
    slice, and array (and struct) type declarations; in other words, a parser
    on the first pass can precisely determine the 'kind' of any composite type
    literal (e.g. `[]int` as a slice vs `[n]int` as an array [without even
    having to know *what* n is]), and on the second pass can precisely
    determine the 'kind' of any named literal (e.g. `T{}`, where T is specified
    elsewhere in a type declaration).

    With your proposed changes, there is *syntactic* ambiguity between arrays
    and maps (e.g. `[n]int` could be a map or an array), and the compiler would
    need more identifier resolution passes to determine the basic kind of
    composite types (I'm not even sure that it's limited to just a fixed number
    of additional passes).

    *** If you're using ambiguous here to mean "confusing," then I suggest you
    read the language specification, which is rather short. Many people have
    been confused by the *semantic* differences between slices and arrays
    (particularly in that one is a reference type and the other is not), but I
    have yet to see anyone have persistent difficulty recognizing and
    benefiting from the *syntactic* differences.

    Also, dependent types...sounds familiar...`somevar := anothervar`...what
    type is `somevar`?
    You're referring to type inference. I'm referring to:

    // compiler has to know about A before it can fully resolve B
    // but at least it instantly knows B is of map kind.
    type B map[A]int
    type A int

    (vs)

    // same as the above, but in this case, a compilation error
    // occurs (because A is not a type).
    type B map[A]int
    const A = 10

    With your proposal, these examples become:

    // compiler has to know about A before it can *start *to resolve B
    // because it has no way of instantly knowing whether B is a map
    // or an array. In this case, B is a map
    type B [A]int
    type A int

    (vs)

    // no compilation error occurs, because B is now an array. As a
    // *requirement* for readability, if the kind of a named type changes,
    // that change must always occur in the line of that type's
    // declaration, which isn't the case here. This leads to subtle,
    // confusing bugs being introduced in subtle, confusing ways.
    type B map[A]int
    const A = 10

    In any case, even if we did unanimously agree that the proposal was
    desirable and problem-free, we couldn't change the language to accommodate
    it at least before Go version 2 (which is at least several years away),
    because 1) backwards-incompatible language changes are prohibited in Go
    1.x, unless you're proposing that the map keyword be optional, in which
    case, 2) it could not be implemented because as a language design decision
    Go does not allow any keyword to be optional.

    What other code examples do you find to be hairy?
    There's a lot of syntactic cruff (eg: the topic at hand)
    I'm specifically interested in what you find to be hairy *besides* the
    topic at hand, since it sounds like there were at least a few other sore
    points, by your reckoning.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kevin Gillette at Nov 23, 2013 at 12:36 pm
    (edit: the bottom-most code example was intended to read as...)

    // no compilation error occurs, because B is now an array. As a
    // *requirement* for readability, if the kind of a named type changes,
    // that change must always occur in the line of that type's
    // declaration, which isn't the case here. This leads to subtle,
    // confusing bugs being introduced in subtle, confusing ways.
    type B [A]int
    const A = 10
    On Saturday, November 23, 2013 5:34:21 AM UTC-7, Kevin Gillette wrote:
    On Saturday, November 23, 2013 2:33:35 AM UTC-7, Brenden wrote:

    How is what I'm proposing any less ambiguous than what a slice currently
    is?
    I'm using the term 'ambiguous' in a technical sense here***. The Go
    language, as specified, has absolutely no syntactic ambiguity between map,
    slice, and array (and struct) type declarations; in other words, a parser
    on the first pass can precisely determine the 'kind' of any composite type
    literal (e.g. `[]int` as a slice vs `[n]int` as an array [without even
    having to know *what* n is]), and on the second pass can precisely
    determine the 'kind' of any named literal (e.g. `T{}`, where T is specified
    elsewhere in a type declaration).

    With your proposed changes, there is *syntactic* ambiguity between arrays
    and maps (e.g. `[n]int` could be a map or an array), and the compiler would
    need more identifier resolution passes to determine the basic kind of
    composite types (I'm not even sure that it's limited to just a fixed number
    of additional passes).

    *** If you're using ambiguous here to mean "confusing," then I suggest you
    read the language specification, which is rather short. Many people have
    been confused by the *semantic* differences between slices and arrays
    (particularly in that one is a reference type and the other is not), but I
    have yet to see anyone have persistent difficulty recognizing and
    benefiting from the *syntactic* differences.

    Also, dependent types...sounds familiar...`somevar := anothervar`...what
    type is `somevar`?
    You're referring to type inference. I'm referring to:

    // compiler has to know about A before it can fully resolve B
    // but at least it instantly knows B is of map kind.
    type B map[A]int
    type A int

    (vs)

    // same as the above, but in this case, a compilation error
    // occurs (because A is not a type).
    type B map[A]int
    const A = 10

    With your proposal, these examples become:

    // compiler has to know about A before it can *start *to resolve B
    // because it has no way of instantly knowing whether B is a map
    // or an array. In this case, B is a map
    type B [A]int
    type A int

    (vs)

    // no compilation error occurs, because B is now an array. As a
    // *requirement* for readability, if the kind of a named type changes,
    // that change must always occur in the line of that type's
    // declaration, which isn't the case here. This leads to subtle,
    // confusing bugs being introduced in subtle, confusing ways.
    type B map[A]int
    const A = 10

    In any case, even if we did unanimously agree that the proposal was
    desirable and problem-free, we couldn't change the language to accommodate
    it at least before Go version 2 (which is at least several years away),
    because 1) backwards-incompatible language changes are prohibited in Go
    1.x, unless you're proposing that the map keyword be optional, in which
    case, 2) it could not be implemented because as a language design decision
    Go does not allow any keyword to be optional.

    What other code examples do you find to be hairy?
    There's a lot of syntactic cruff (eg: the topic at hand)
    I'm specifically interested in what you find to be hairy *besides* the
    topic at hand, since it sounds like there were at least a few other sore
    points, by your reckoning.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brenden at Nov 24, 2013 at 5:23 am

    On Saturday, November 23, 2013 4:34:21 AM UTC-8, Kevin Gillette wrote:
    On Saturday, November 23, 2013 2:33:35 AM UTC-7, Brenden wrote:

    How is what I'm proposing any less ambiguous than what a slice currently
    is?
    I'm using the term 'ambiguous' in a technical sense here***. The Go
    language, as specified, has absolutely no syntactic ambiguity between map,
    slice, and array (and struct) type declarations; in other words, a parser
    on the first pass can precisely determine the 'kind' of any composite type
    literal (e.g. `[]int` as a slice vs `[n]int` as an array [without even
    having to know *what* n is]), and on the second pass can precisely
    determine the 'kind' of any named literal (e.g. `T{}`, where T is specified
    elsewhere in a type declaration).

    With your proposed changes, there is *syntactic* ambiguity between arrays
    and maps (e.g. `[n]int` could be a map or an array), and the compiler would
    need more identifier resolution passes to determine the basic kind of
    composite types (I'm not even sure that it's limited to just a fixed number
    of additional passes).

    *** If you're using ambiguous here to mean "confusing," then I suggest you
    read the language specification, which is rather short. Many people have
    been confused by the *semantic* differences between slices and arrays
    (particularly in that one is a reference type and the other is not), but I
    have yet to see anyone have persistent difficulty recognizing and
    benefiting from the *syntactic* differences.

    Also, dependent types...sounds familiar...`somevar := anothervar`...what
    type is `somevar`?
    You're referring to type inference. I'm referring to:

    // compiler has to know about A before it can fully resolve B
    // but at least it instantly knows B is of map kind.
    type B map[A]int
    type A int

    (vs)

    // same as the above, but in this case, a compilation error
    // occurs (because A is not a type).
    type B map[A]int
    const A = 10

    With your proposal, these examples become:

    // compiler has to know about A before it can *start *to resolve B
    // because it has no way of instantly knowing whether B is a map
    // or an array. In this case, B is a map
    type B [A]int
    type A int

    (vs)

    // no compilation error occurs, because B is now an array. As a
    // *requirement* for readability, if the kind of a named type changes,
    // that change must always occur in the line of that type's
    // declaration, which isn't the case here. This leads to subtle,
    // confusing bugs being introduced in subtle, confusing ways.
    type B map[A]int
    const A = 10

    In any case, even if we did unanimously agree that the proposal was
    desirable and problem-free, we couldn't change the language to accommodate
    it at least before Go version 2 (which is at least several years away),
    because 1) backwards-incompatible language changes are prohibited in Go
    1.x, unless you're proposing that the map keyword be optional, in which
    case, 2) it could not be implemented because as a language design decision
    Go does not allow any keyword to be optional.

    What other code examples do you find to be hairy?
    There's a lot of syntactic cruff (eg: the topic at hand)
    I'm specifically interested in what you find to be hairy *besides* the
    topic at hand, since it sounds like there were at least a few other sore
    points, by your reckoning.
    I've been getting the general feeling that some of the syntactic choices
    with Go are a bit odd and not really thematically consistent.

    Overall, I REALLY like Go. It's almost as low level as C while being better
    organized and it is much less bloated than C++. It has the potential to be
    as readable as Ruby while being far more performant.

    This topic is just me being imaginative. It's sad to see some of the
    replies being some defensive. I keep getting the feeling (and not just on
    this mailing list, but other places online too) that Go is the way it is
    and it's just fine and good and great. I have a good amount of experience
    with iOS programming and Objective C and I feel it's a great language. That
    said, it's still actively being improved to make writing code with it less
    repetitive and really more enjoyable.

    I would hope that the same spirit would prevail in Go's community.

    Not including 3 characters (ie "map") is really a trivial optimization and
    doesn't make that much of a difference, but it is still an improvement and
    means I have to make that many fewer key strokes and that scales on large
    code bases.

    I'll be referencing the Go spec more as I learn to get more familiar with
    maps, especially maps that use non-string and non-integer indexes. I hope
    to learn why maps were made to be the way they are. After all, the creators
    of Go have way more experience coding than I do.

    Thanks for your time.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Benjamin Measures at Nov 24, 2013 at 5:59 pm

    On Sunday, 24 November 2013 05:23:28 UTC, Brenden wrote:

    Not including 3 characters (ie "map") is really a trivial optimization and
    doesn't make that much of a difference, but it is still an improvement and
    means I have to make that many fewer key strokes and that scales on large
    code bases.
    If this were the case then we'd all be playing Perl Golf in the large.
    @a=<>;print splice@a,rand@a,1while@a
    What does it do? Nobody knows anymore.

    One of the goals of Go is to address the problem of "programming in the
    large". Especially here, good quality code is read a lot more than it is
    written. For this reason, quick code comprehension is pretty important.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kevin Gillette at Nov 25, 2013 at 4:16 am

    On Sunday, November 24, 2013 10:59:17 AM UTC-7, Benjamin Measures wrote:
    If this were the case then we'd all be playing Perl Golf in the large.
    @a=<>;print splice@a,rand@a,1while@a
    What does it do? Nobody knows anymore.
    Who cares?! Look at all the typing you saved! :-D On very large scale
    projects (which for this style of programming, I'd estimate to be about 10
    lines), the time savings involved in writing all that code clearly pays for
    itself!

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ian Lance Taylor at Nov 24, 2013 at 8:51 pm

    On Sat, Nov 23, 2013 at 9:23 PM, Brenden wrote:
    Not including 3 characters (ie "map") is really a trivial optimization and
    doesn't make that much of a difference, but it is still an improvement and
    means I have to make that many fewer key strokes and that scales on large
    code bases.
    I personally don't find it that interesting to discuss this kind of
    change because Go is not just a relatively new language, it's also a
    programming project. And part of that project is a commitment to
    maintaining a language standard, as described at
    http://golang.org/doc/go1compat . Dropping the "map" keyword, while
    doable, would break most existing Go programs, so we won't do it.

    Looking forward, if dropping "map" were a significant improvement, we
    could do it in Go 2, and write a gofix module to fix all existing
    programs. But frankly, as far as I am concerned, it is not a
    significant improvement. And if we get only a minor improvement, then
    it is not worth the cost.

    Ian

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • John Nagle at Nov 24, 2013 at 7:07 pm

    On 11/22/2013 11:10 PM, Kevin Gillette wrote:
    That's the first thing that came to mind for me as well -- it's not only a
    readability issue, it's syntactic ambiguity that can only be resolved after
    dependent types and constants have been evaluated.
        Which is something Go's syntax avoids. C and C++ have that, which is
    why you can't reliably parse C/C++ without parsing all the include
    files. Go's grammar, like that of Pascal, Modula, and Ada, is
    context-free.

        (C was supposed to have a context-free grammar. Originally, it did.
    Then they added "typedef", and parsing became dependent on knowing what
    was a type. It was downhill from there.)

         John Nagle

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • DisposaBoy at Nov 23, 2013 at 3:09 pm

    On Saturday, November 23, 2013 5:40:56 AM UTC, Brenden wrote:
    I'm still actively learning Go, but I've noticed that the code can become
    quite hairy. I've been thinking of ways to simplify the code
    What are you trying to simplify, and why?


    without losing meaning and the map type seems like a good, verbose example.

    var dictionary map[string]string

    this could be:

    var dictionary[string]string
    Without losing meaning? You just lost the variable name, and what's a
    dictionary? Is it a new Go keyword? Is it a typo? With this form I have to
    ask these questions and more every time I come into contact with it, and
    all this to avoid typing 3 letters?

    This example is basically an extension of the `slice` type. If a type is
    given between the brackets, then it should be declared as a `map`, if not
    then it should be a `slice`.
    And now I need to go lookup the definition of `string` between the brackets
    if I want to know if it's a map or an **array**

    To emphasize, when defining an array or string slice, you don't do:

    var array array[10]string
    var stringSlice slice[]string

    instead you do:

    var array [10]string
    var stringSlice []string
    I don't get it. You'll also notice that array and slices don't have *type*
    between the brackets.

    So really it would follow that we do the same with maps.
    No.

    Thoughts?

    I see several cons but no pros.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brenden at Nov 24, 2013 at 5:14 am

    On Saturday, November 23, 2013 7:09:26 AM UTC-8, DisposaBoy wrote:

    On Saturday, November 23, 2013 5:40:56 AM UTC, Brenden wrote:

    I'm still actively learning Go, but I've noticed that the code can become
    quite hairy. I've been thinking of ways to simplify the code
    What are you trying to simplify, and why?
    The amount of useless characters in my code.

    without losing meaning and the map type seems like a good, verbose
    example.

    var dictionary map[string]string

    this could be:

    var dictionary[string]string
    Without losing meaning? You just lost the variable name, and what's a
    dictionary? Is it a new Go keyword? Is it a typo? With this form I have to
    ask these questions and more every time I come into contact with it, and
    all this to avoid typing 3 letters?
    ...dictionary is a variable name in this case. Also, the concept of a
    dictionary is synonymous with an associative array or map or hash; a rose
    by any other name...
    This example is basically an extension of the `slice` type. If a type is
    given between the brackets, then it should be declared as a `map`, if not
    then it should be a `slice`.
    And now I need to go lookup the definition of `string` between the
    brackets if I want to know if it's a map or an **array**
    `string` is a built-in type. If you don't know that then you can't code in
    Go. Of course you can code in Go, so you know that string is a type. I
    would go so far as to say that a map can only be referenced with a string,
    but that's just me. I don't see any good/common use for non-string or
    non-integer indexes.
    To emphasize, when defining an array or string slice, you don't do:

    var array array[10]string
    var stringSlice slice[]string

    instead you do:

    var array [10]string
    var stringSlice []string
    I don't get it. You'll also notice that array and slices don't have *type*
    between the brackets.
    Exactly my point though. You know what they are without blatantly labeling
    them. How? Because we infer based on the syntax. How can you not get what
    I'm saying?
    So really it would follow that we do the same with maps.
    No.
    Really? 2 of the 3 examples do not require an explicit type to be defined
    in the declaration. If I were a statistician I'd call that a pattern.
    Thoughts?

    I see several cons but no pros.
    Thanks for taking the time to at least reply.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Minux at Nov 24, 2013 at 5:24 am

    On Nov 24, 2013 12:14 AM, "Brenden" wrote:
    On Saturday, November 23, 2013 7:09:26 AM UTC-8, DisposaBoy wrote:
    This example is basically an extension of the `slice` type. If a type
    is given between the brackets, then it should be declared as a `map`, if
    not then it should be a `slice`.
    And now I need to go lookup the definition of `string` between the
    brackets if I want to know if it's a map or an **array**
    `string` is a built-in type. If you don't know that then you can't code
    in Go. Of course you can code in Go, so you know that string is a type. I
    would go so far as to say that a map can only be referenced with a string,
    but that's just me. I don't see any good/common use for non-string or
    non-integer indexes.
    really? string is not a builtin type, it is just a predeclared name for the
    string type, and you are free to redefine it.

    http://play.golang.org/p/KbTreBZmrk

    i'd expect you to at least have read the Go specification before making
    suggestions like this.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brenden at Nov 24, 2013 at 5:30 am
    What spec are you reading?

      A *string type* represents the set of string values.

    http://golang.org/ref/spec#String_types

    It's nice that you can redefine it, but that's besides the point.
    On Saturday, November 23, 2013 9:24:24 PM UTC-8, minux wrote:


    On Nov 24, 2013 12:14 AM, "Brenden" <bso...@gmail.com <javascript:>>
    wrote:
    On Saturday, November 23, 2013 7:09:26 AM UTC-8, DisposaBoy wrote:
    This example is basically an extension of the `slice` type. If a type
    is given between the brackets, then it should be declared as a `map`, if
    not then it should be a `slice`.
    And now I need to go lookup the definition of `string` between the
    brackets if I want to know if it's a map or an **array**
    `string` is a built-in type. If you don't know that then you can't code
    in Go. Of course you can code in Go, so you know that string is a type. I
    would go so far as to say that a map can only be referenced with a string,
    but that's just me. I don't see any good/common use for non-string or
    non-integer indexes.
    really? string is not a builtin type, it is just a predeclared name for
    the string type, and you are free to redefine it.

    http://play.golang.org/p/KbTreBZmrk

    i'd expect you to at least have read the Go specification before making
    suggestions like this.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Minux at Nov 24, 2013 at 5:38 am

    On Nov 24, 2013 12:30 AM, "Brenden" wrote:
    What spec are you reading?

    A string type represents the set of string values.

    http://golang.org/ref/spec#String_types

    It's nice that you can redefine it, but that's besides the point.
    when you see
    var variable[string]int

    how can you tell that string is not redefined? how can you be sure that
    it's a map not an array of int? (perhaps there is a line that reads:
    const string = 42
    one thousand lines above this one)

    it seems you didn't differentiate builtin types and their predeclared names.
    On Saturday, November 23, 2013 9:24:24 PM UTC-8, minux wrote:
    On Nov 24, 2013 12:14 AM, "Brenden" wrote:
    On Saturday, November 23, 2013 7:09:26 AM UTC-8, DisposaBoy wrote:
    This example is basically an extension of the `slice` type. If a
    type is given between the brackets, then it should be declared as a `map`,
    if not then it should be a `slice`.
    And now I need to go lookup the definition of `string` between the
    brackets if I want to know if it's a map or an **array**
    `string` is a built-in type. If you don't know that then you can't
    code in Go. Of course you can code in Go, so you know that string is a
    type. I would go so far as to say that a map can only be referenced with a
    string, but that's just me. I don't see any good/common use for non-string
    or non-integer indexes.
    really? string is not a builtin type, it is just a predeclared name for
    the string type, and you are free to redefine it.
    http://play.golang.org/p/KbTreBZmrk

    i'd expect you to at least have read the Go specification before making
    suggestions like this.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brenden at Nov 24, 2013 at 5:55 am
    I'm pretty sure the compiler knows what the real type is. It isn't so
    easily confused like a human reading it would be; it has a table of all
    types and the types behind them.
    On Saturday, November 23, 2013 9:38:02 PM UTC-8, minux wrote:


    On Nov 24, 2013 12:30 AM, "Brenden" <bso...@gmail.com <javascript:>>
    wrote:
    What spec are you reading?

    A string type represents the set of string values.

    http://golang.org/ref/spec#String_types

    It's nice that you can redefine it, but that's besides the point.
    when you see
    var variable[string]int

    how can you tell that string is not redefined? how can you be sure that
    it's a map not an array of int? (perhaps there is a line that reads:
    const string = 42
    one thousand lines above this one)

    it seems you didn't differentiate builtin types and their predeclared
    names.
    On Saturday, November 23, 2013 9:24:24 PM UTC-8, minux wrote:
    On Nov 24, 2013 12:14 AM, "Brenden" wrote:
    On Saturday, November 23, 2013 7:09:26 AM UTC-8, DisposaBoy wrote:
    This example is basically an extension of the `slice` type. If a
    type is given between the brackets, then it should be declared as a `map`,
    if not then it should be a `slice`.
    And now I need to go lookup the definition of `string` between the
    brackets if I want to know if it's a map or an **array**
    `string` is a built-in type. If you don't know that then you can't
    code in Go. Of course you can code in Go, so you know that string is a
    type. I would go so far as to say that a map can only be referenced with a
    string, but that's just me. I don't see any good/common use for non-string
    or non-integer indexes.
    really? string is not a builtin type, it is just a predeclared name for
    the string type, and you are free to redefine it.
    http://play.golang.org/p/KbTreBZmrk

    i'd expect you to at least have read the Go specification before making
    suggestions like this.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Lucio at Nov 24, 2013 at 6:17 am

    On Sunday, 24 November 2013 07:55:21 UTC+2, Brenden wrote:
    I'm pretty sure the compiler knows what the real type is. It isn't so
    easily confused like a human reading it would be; it has a table of all
    types and the types behind them.
    But readability is not intended for the compiler, it's meant for a human
    and not necessarily one who is familiar with the Go programming language.
      We seem to have gone around in a big circle.

    Lucio.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brenden at Nov 24, 2013 at 6:28 am
    I would venture to say that simplifying the code by removing unnecessary
    bits makes the code more readable.

    The original issue is not how many passes the compiler needs in order to
    definitely define what a line of code is doing. The issue is making Go's
    syntax more simple and consistent.

    Personally, I feel anything less than Go 2 is too soon to start optimizing
    the language. On the other side, Go 1 is pretty mature and therefore I can
    see Go 2 not being very far off in the future. So it will be interesting to
    see how we can refine the Go language.

    That's really my point in raising the question about one single example of
    how something could be done differently/better; refining Go.
    On Saturday, November 23, 2013 10:17:06 PM UTC-8, Lucio wrote:


    On Sunday, 24 November 2013 07:55:21 UTC+2, Brenden wrote:

    I'm pretty sure the compiler knows what the real type is. It isn't so
    easily confused like a human reading it would be; it has a table of all
    types and the types behind them.
    But readability is not intended for the compiler, it's meant for a human
    and not necessarily one who is familiar with the Go programming language.
    We seem to have gone around in a big circle.

    Lucio.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dave Cheney at Nov 24, 2013 at 6:42 am

    On 24 Nov 2013, at 17:28, Brenden wrote:

    I would venture to say that simplifying the code by removing unnecessary bits makes the code more readable.
    No. This is a false dichotomy to argue that a shorter, terser syntax is always more readable. Would you argue that all variable names should be made single characters for reasons of readability? I doubt it.

    As many have argued the current map syntax is unambiguous, it is a map of values of one type to another type.
    The original issue is not how many passes the compiler needs in order to definitely define what a line of code is doing. The issue is making Go's syntax more simple and consistent.
    Again, this argument is false. Removing the map keyword from the declaration introduces ambiguity.
    Personally, I feel anything less than Go 2 is too soon to start optimizing the language. On the other side, Go 1 is pretty mature and therefore I can see Go 2 not being very far off in the future. So it will be interesting to see how we can refine the Go language.

    That's really my point in raising the question about one single example of how something could be done differently/better; refining Go.
    Thank you for your contribution but this is one aspect of the Go syntax that is unlikely to change. Partially because of universal rejection of your proposal by people who have worked in the language for years, but mainly because this is the first proposal of this kind since the language started.

    It is simply not the issue for the majority of users of Go that you have chosen to make it.

    With reference to Go 2, I recommend you spend time familiarising yourself with the language before embarking on radical campaigns for redesigning it in a future version

    Dave
    On Saturday, November 23, 2013 10:17:06 PM UTC-8, Lucio wrote:

    On Sunday, 24 November 2013 07:55:21 UTC+2, Brenden wrote:
    I'm pretty sure the compiler knows what the real type is. It isn't so easily confused like a human reading it would be; it has a table of all types and the types behind them.
    But readability is not intended for the compiler, it's meant for a human and not necessarily one who is familiar with the Go programming language. We seem to have gone around in a big circle.

    Lucio.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brenden at Nov 24, 2013 at 7:26 am

    On Saturday, November 23, 2013 10:42:20 PM UTC-8, Dave Cheney wrote:


    On 24 Nov 2013, at 17:28, Brenden <bso...@gmail.com <javascript:>> wrote:

    I would venture to say that simplifying the code by removing unnecessary
    bits makes the code more readable.


    No. This is a false dichotomy to argue that a shorter, terser syntax is
    always more readable. Would you argue that all variable names should be
    made single characters for reasons of readability? I doubt it.

    As many have argued the current map syntax is unambiguous, it is a map of
    values of one type to another type.


    The original issue is not how many passes the compiler needs in order to
    definitely define what a line of code is doing. The issue is making Go's
    syntax more simple and consistent.


    Again, this argument is false. Removing the map keyword from the
    declaration introduces ambiguity.


    Personally, I feel anything less than Go 2 is too soon to start optimizing
    the language. On the other side, Go 1 is pretty mature and therefore I can
    see Go 2 not being very far off in the future. So it will be interesting to
    see how we can refine the Go language.

    That's really my point in raising the question about one single example of
    how something could be done differently/better; refining Go.


    Thank you for your contribution but this is one aspect of the Go syntax
    that is unlikely to change. Partially because of universal rejection of
    your proposal by people who have worked in the language for years, but
    mainly because this is the first proposal of this kind since the language
    started.

    It is simply not the issue for the majority of users of Go that you have
    chosen to make it.

    With reference to Go 2, I recommend you spend time familiarising yourself
    with the language before embarking on radical campaigns for redesigning it
    in a future version
    LOL. Well said. I let my excitement get the best of me. I am glad to have
    others to bounce ideas off of though.

    Thanks all for the counter arguments and helping me see the value of
    unambiguous syntax.
    Dave

    On Saturday, November 23, 2013 10:17:06 PM UTC-8, Lucio wrote:


    On Sunday, 24 November 2013 07:55:21 UTC+2, Brenden wrote:

    I'm pretty sure the compiler knows what the real type is. It isn't so
    easily confused like a human reading it would be; it has a table of all
    types and the types behind them.
    But readability is not intended for the compiler, it's meant for a human
    and not necessarily one who is familiar with the Go programming language.
    We seem to have gone around in a big circle.

    Lucio.

    --
    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...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Minux at Nov 24, 2013 at 6:36 am

    On Nov 24, 2013 12:55 AM, "Brenden" wrote:
    I'm pretty sure the compiler knows what the real type is. It isn't so
    easily confused like a human reading it would be; it has a table of all
    types and the types behind them.
    we are talking exactly about human readers. It is fair to say Go is
    designed more for human readers than for computers. This principal is
    explained in numerous posts, for example rob's splash article. please read
    talks.golang.org/2012/splash.article for more background of Go.

    previously, looking at
    var variable map[string]int
    we know it's a map, now looking at your proposed simplification:
    var variable[string]int
    one doesn't know if it's a map or an array.

    i'm confident to say that any proposal that hinders code readability is a
    no go for Go.
    On Saturday, November 23, 2013 9:38:02 PM UTC-8, minux wrote:
    On Nov 24, 2013 12:30 AM, "Brenden" wrote:

    What spec are you reading?

    A string type represents the set of string values.

    http://golang.org/ref/spec#String_types

    It's nice that you can redefine it, but that's besides the point.
    when you see
    var variable[string]int

    how can you tell that string is not redefined? how can you be sure that
    it's a map not an array of int? (perhaps there is a line that reads:
    const string = 42
    one thousand lines above this one)

    it seems you didn't differentiate builtin types and their predeclared
    names.
    On Saturday, November 23, 2013 9:24:24 PM UTC-8, minux wrote:
    On Nov 24, 2013 12:14 AM, "Brenden" wrote:
    On Saturday, November 23, 2013 7:09:26 AM UTC-8, DisposaBoy wrote:
    This example is basically an extension of the `slice` type. If a
    type is given between the brackets, then it should be declared as a `map`,
    if not then it should be a `slice`.
    And now I need to go lookup the definition of `string` between the
    brackets if I want to know if it's a map or an **array**
    `string` is a built-in type. If you don't know that then you can't
    code in Go. Of course you can code in Go, so you know that string is a
    type. I would go so far as to say that a map can only be referenced with a
    string, but that's just me. I don't see any good/common use for non-string
    or non-integer indexes.
    really? string is not a builtin type, it is just a predeclared name
    for the string type, and you are free to redefine it.
    http://play.golang.org/p/KbTreBZmrk

    i'd expect you to at least have read the Go specification before
    making suggestions like this.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Volker Dobler at Nov 24, 2013 at 1:57 pm

    Am Sonntag, 24. November 2013 06:55:21 UTC+1 schrieb Brenden:
    I'm pretty sure the compiler knows what the real type is. It isn't so
    easily confused like a human reading it would be; it has a table of all
    types and the types behind them.
    On Saturday, November 23, 2013 9:38:02 PM UTC-8, minux wrote:

    when you see
    var variable[string]int

    how can you tell that string is not redefined? how can you be sure that
    it's a map not an array of int? (perhaps there is a line that reads:
    const string = 42
    one thousand lines above this one)

    it seems you didn't differentiate builtin types and their predeclared
    names.
    "The compiler knows" is a *very* bad argument.
    If "the compiler knows" what is going on would be a
    compelling argument we could code in whitespace
    or brainfuck or APL.
    Go is about human-understandable code.

    V.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kevin Gillette at Nov 24, 2013 at 6:29 am

    On Saturday, November 23, 2013 10:14:24 PM UTC-7, Brenden wrote:
    On Saturday, November 23, 2013 7:09:26 AM UTC-8, DisposaBoy wrote:

    What are you trying to simplify, and why?
    The amount of useless characters in my code.
    >

    You'll find that very often that syntactical (and stylistic formatting)
    decisions in Go very often choose "clarity" when the other option is
    "succinctness". Type inference is one of the few cases where succinctness
    is chosen. Other examples demonstrating the decision to favor clarity:

        - Nested composite literals require explicit type names. `[]struct{x
        struct{y int}}{{{1}}}}` *could* be deterministically resolved (and more
        easily than this topic's proposal), but for the sake of readability, only
        the outer-most type name can be elided, thus `[]struct{x struct{y
        int}}{{struct{y int}{1}}}` is the shortest equivalent form the first
        expression can legally take. To regain some measure of succinctness,
        obviously named types are preferable here.
        - gofmt really doesn't care (and neither do [most of] the rest of us)
        that you might want your one-liner control struct (loop, conditional, etc)
        to fit on one line. For clarity, control structures always use at least 3
        lines (including the terminating brace). In this community, we really don't
        care too much about 1-line or 3-byte savings when any argument about
        clarity can be made. Further, maps aren't used nearly as much in Go by
        proportion as maps/tables/hashes/dicts are used in other languages; many
        things that would be map equivalents in another language are often slices
        when competently expressed in Go, thus a 3-byte savings is even less of an
        issue when it's for a comparatively less-used part of the language.
        - It would be syntactically unambiguous for `func() {}` to allow the
        elision of the parentheses, resulting in `func {}`, but consistency (and
        thus clarity) are favored. For that matter, the keyword func could have
        just been shortened to `fun`, or `fn`, yet 'func' was chosen, and 'func'
        occurs far more often in Go code than 'map'. There have been other
        keystroke-reductionist proposals to allow `func main() {}` to be specified
        as just a top-level anonymous block, `{ }`, but for reasons of clarity (and
        lack of widespread annoyance with typing `func main()`, that proposal was
        rejected.

    And now I need to go lookup the definition of `string` between the brackets
    if I want to know if it's a map or an **array**
    `string` is a built-in type. If you don't know that then you can't code in
    Go.
    type string int
    var bool string = 5

    I would go so far as to say that a map can only be referenced with a
    string, but that's just me. I don't see any good/common use for non-string
    or non-integer indexes.
    Once a programmer can envision those use cases, only then will they begin
    benefit from them, anyway. Besides which, even if there were no such use
    cases (but there are), decisions regarding the Go language have
    traditionally favored caution and flexibility: just because there's no
    apparent reason to do something, it doesn't mean that doing that something
    should be prohibited.

    I don't get it. You'll also notice that array and slices don't have *type*
    between the brackets.
    Exactly my point though. You know what they are without blatantly
    labeling them. How? Because we infer based on the syntax. How can you not
    get what I'm saying?
    We do get what you're saying, but the point is self-contradictory. As
    mentioned several times, yes, the distinction between slices, arrays, and
    maps can _currently_ be inferred based on syntax; with this proposal, the
    distinction between arrays and maps could no longer be inferred from the
    syntax.

    Really? 2 of the 3 examples do not require an explicit type to be defined
    in the declaration. If I were a statistician I'd call that a pattern.
    If you were a statistician, you'd consider generalizations "which apply to
    only two-thirds of a sample" to have been reached with "statistically
    significant error" ;)

    I see several cons but no pros.
    Thanks for taking the time to at least reply.
    Note that if you had proposed unambiguous syntax, such as [{K}]V as being
    equivalent to the current map[K]V, then these valid, accurate
    counter-arguments regarding ambiguity (both visual and technical) would go
    away, leaving just (strong) resistance on the matters of style and
    stick-with-it-ism.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedNov 23, '13 at 5:41a
activeNov 25, '13 at 4:16a
posts29
users12
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase