FAQ
1. Where is `union`?
golang uses `struct` as in c. But i noticed `union` is dropped. There is
composition for interfaces and structs, but it does mean `one and another`
not `one or another`.
Then how to define `basic type` but not including those `map`, `array`,
`slice` etc...
Ex.:
type basic bool|int|int32|int64|uint|float32|float64|string...
those basic types?

2. OO and PO?
if they are the same thing, why not when creating:
func Add(a, b int) int {
return a + b
}
also generating the method (to make things simple):
func (a int) Add (b int) int {
return a + b
}
and vise versa.

I mean when create a function `Add`, the compiler will automatically create
a method for the type of the first argument (as an alias or something...)
- of cause, there may be name conflicts, so i support func overload
- anonymous func won't have this feature

3. Runtime channel
Why not the channel is running in runtime mode? I mean, if so, it seems
there's no need `go` and `channel` keywords. Ex.:
func test(ch chan int) {
ch <- 1
}

func main() {
ch := make(chan int)
test(ch)
i := <-ch
fmt.Println(i)
}

It seems useless cause if i can:
func test() int {
return 1
}

func main() {
i := <-test()
// i := test()
fmt.Println(i)
}
operator <- has already figure out `test()` is running in gorountine mode,
and the return value will be sent in a channel, comparing to the 2nd
statement.
So, we don't have to change the `test` function. (the definition is same as
in concurrency mode or normal, no need special parameter `chan`, it seems
like an output parameter in my eyes...why not just return it?)


(Maybe here, what i'm thinking is the features based on runtime...i'm not
sure...)
But i will feel more comfortable if golang has those features.

--
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/d/optout.

Search Discussions

  • Ian Lance Taylor at May 17, 2016 at 6:46 pm

    On Tue, May 17, 2016 at 7:37 AM, Wang Yarco wrote:
    1. Where is `union`?
    golang uses `struct` as in c. But i noticed `union` is dropped. There is
    composition for interfaces and structs, but it does mean `one and another`
    not `one or another`.
    Then how to define `basic type` but not including those `map`, `array`,
    `slice` etc...
    Ex.:
    type basic bool|int|int32|int64|uint|float32|float64|string...
    those basic types?
    You can't. Go does not have union or sum types.

    https://golang.org/doc/faq#unions
    https://golang.org/doc/faq#variant_types

    2. OO and PO?
    if they are the same thing, why not when creating:
    func Add(a, b int) int {
    return a + b
    }
    also generating the method (to make things simple):
    func (a int) Add (b int) int {
    return a + b
    }
    and vise versa.

    I mean when create a function `Add`, the compiler will automatically create
    a method for the type of the first argument (as an alias or something...)
    - of cause, there may be name conflicts, so i support func overload
    - anonymous func won't have this feature
    That would mean that writing functions would change the interfaces
    that a type satisfies. That does not seem like a good idea to me.

    3. Runtime channel
    Why not the channel is running in runtime mode? I mean, if so, it seems
    there's no need `go` and `channel` keywords. Ex.:
    func test(ch chan int) {
    ch <- 1
    }

    func main() {
    ch := make(chan int)
    test(ch)
    i := <-ch
    fmt.Println(i)
    }

    It seems useless cause if i can:
    func test() int {
    return 1
    }

    func main() {
    i := <-test()
    // i := test()
    fmt.Println(i)
    }
    operator <- has already figure out `test()` is running in gorountine mode,
    and the return value will be sent in a channel, comparing to the 2nd
    statement.
    So, we don't have to change the `test` function. (the definition is same as
    in concurrency mode or normal, no need special parameter `chan`, it seems
    like an output parameter in my eyes...why not just return it?)
    I'm sorry, I don't understand this suggestion. Channels are used for
    many things other than returning values from functions.

    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/d/optout.
  • Wang Yarco at May 18, 2016 at 12:32 pm

    You can't. Go does not have union or sum types.
    That's fine.
    That would mean that writing functions would change the interfaces
    that a type satisfies. That does not seem like a good idea to me.
    It can be limited to in same package, and only adding method when adding
    function. So if a struct already has its method, it will not do that.
    But if you might run some action on struct A (ex. `Action(A, ...)` in PO),
    obviously, it would feel comfortable if A also have such method
    `A.Action(...)`. So that i can run both.
    I'm sorry, I don't understand this suggestion. Channels are used for
    many things other than returning values from functions.
    I'm not sure. I didn't see that. Can you show some examples?
    On Wednesday, May 18, 2016 at 2:47:01 AM UTC+8, Ian Lance Taylor wrote:

    On Tue, May 17, 2016 at 7:37 AM, Wang Yarco <yarco...@gmail.com
    <javascript:>> wrote:
    1. Where is `union`?
    golang uses `struct` as in c. But i noticed `union` is dropped. There is
    composition for interfaces and structs, but it does mean `one and another`
    not `one or another`.
    Then how to define `basic type` but not including those `map`, `array`,
    `slice` etc...
    Ex.:
    type basic bool|int|int32|int64|uint|float32|float64|string...
    those basic types?
    You can't. Go does not have union or sum types.

    https://golang.org/doc/faq#unions
    https://golang.org/doc/faq#variant_types

    2. OO and PO?
    if they are the same thing, why not when creating:
    func Add(a, b int) int {
    return a + b
    }
    also generating the method (to make things simple):
    func (a int) Add (b int) int {
    return a + b
    }
    and vise versa.

    I mean when create a function `Add`, the compiler will automatically create
    a method for the type of the first argument (as an alias or
    something...)
    - of cause, there may be name conflicts, so i support func overload
    - anonymous func won't have this feature
    That would mean that writing functions would change the interfaces
    that a type satisfies. That does not seem like a good idea to me.

    3. Runtime channel
    Why not the channel is running in runtime mode? I mean, if so, it seems
    there's no need `go` and `channel` keywords. Ex.:
    func test(ch chan int) {
    ch <- 1
    }

    func main() {
    ch := make(chan int)
    test(ch)
    i := <-ch
    fmt.Println(i)
    }

    It seems useless cause if i can:
    func test() int {
    return 1
    }

    func main() {
    i := <-test()
    // i := test()
    fmt.Println(i)
    }
    operator <- has already figure out `test()` is running in gorountine mode,
    and the return value will be sent in a channel, comparing to the 2nd
    statement.
    So, we don't have to change the `test` function. (the definition is same as
    in concurrency mode or normal, no need special parameter `chan`, it seems
    like an output parameter in my eyes...why not just return it?)
    I'm sorry, I don't understand this suggestion. Channels are used for
    many things other than returning values from functions.

    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/d/optout.
  • Ian Lance Taylor at May 18, 2016 at 1:16 pm

    On Wed, May 18, 2016 at 5:32 AM, Wang Yarco wrote:
    That would mean that writing functions would change the interfaces
    that a type satisfies. That does not seem like a good idea to me.
    It can be limited to in same package, and only adding method when adding
    function. So if a struct already has its method, it will not do that.
    Now your suggestion is getting more complicated. It becomes more
    detail that the programmer has to remember. I don't think the
    benefits, which are small, are worth the cost.

    I'm sorry, I don't understand this suggestion. Channels are used for
    many things other than returning values from functions.
    I'm not sure. I didn't see that. Can you show some examples?
    https://golang.org/test/sieve.go

    Have you look at the Go tour? https://tour.golang.org

    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/d/optout.
  • Henry at May 18, 2016 at 1:31 pm
    I would think that template (generics) and polymorphism are probably more useful.

    --
    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/d/optout.
  • Wang Yarco at May 18, 2016 at 5:00 pm

    Now your suggestion is getting more complicated. It becomes more
    detail that the programmer has to remember. I don't think the
    benefits, which are small, are worth the cost.
    You thought it is complicated because you think you need to remember it.
    But actually it does't need you to do so.
    Ex.: when you import a lib from github, and you see the doc, if it has an
    api in PO, then you certainly know it also has an OO style. You remember
    only one, but can do things in two ways. It is natural.

    Golang seems try to make itself keep distance from OO (especially c++),
    like the code:
       func (foo *Foo) method(...)
    But actually we are familiar with OO:
       func (this *Foo) method(...)
    Even it is the same thing, written in `this` is more comfortable to me. And
    i also don't need to worry about the name.
    (Of cause, it is personal style. )

    Just another thinking:
    Like c++ has its disadvantage, it keeps c part !!!
    Golang seems also has its disadvantage, it does't get some good thinkings
    in c++ !!!
    (Even in technology, c / go is right, but when thinking as a human, the
    interface of c++ is right!)
    This seems very smart... But i'd prefer not smart way to keep things simple
    (even i will spend more memories for containing variables, i don't care)...
    Have you look at the Go tour? https://tour.golang.org
    No. Just first few topics. (Cause i'm in China, behind GFW, even i have
    VPN, i still try to reduce my usage on VPN)
    I would think that template (generics) and polymorphism are probably more
    useful.
    I don't like generics. If you want <T>, it means, you want something
    without considering TYPE. But the same time, you said `hey, we want strong
    typed language, because we want something running efficient`. NONONO...if
    you have interface{}, why you need <T>?

    Actually, we stand in different position. When i'm thinking about golang,
    it should be more humanity / easy, efficiency is the 2nd thing;
    but i know you guys don't agree...
    On Tuesday, May 17, 2016 at 10:37:27 PM UTC+8, Wang Yarco wrote:

    1. Where is `union`?
    golang uses `struct` as in c. But i noticed `union` is dropped. There is
    composition for interfaces and structs, but it does mean `one and another`
    not `one or another`.
    Then how to define `basic type` but not including those `map`, `array`,
    `slice` etc...
    Ex.:
    type basic bool|int|int32|int64|uint|float32|float64|string...
    those basic types?

    2. OO and PO?
    if they are the same thing, why not when creating:
    func Add(a, b int) int {
    return a + b
    }
    also generating the method (to make things simple):
    func (a int) Add (b int) int {
    return a + b
    }
    and vise versa.

    I mean when create a function `Add`, the compiler will automatically
    create a method for the type of the first argument (as an alias or
    something...)
    - of cause, there may be name conflicts, so i support func overload
    - anonymous func won't have this feature

    3. Runtime channel
    Why not the channel is running in runtime mode? I mean, if so, it seems
    there's no need `go` and `channel` keywords. Ex.:
    func test(ch chan int) {
    ch <- 1
    }

    func main() {
    ch := make(chan int)
    test(ch)
    i := <-ch
    fmt.Println(i)
    }

    It seems useless cause if i can:
    func test() int {
    return 1
    }

    func main() {
    i := <-test()
    // i := test()
    fmt.Println(i)
    }
    operator <- has already figure out `test()` is running in gorountine mode,
    and the return value will be sent in a channel, comparing to the 2nd
    statement.
    So, we don't have to change the `test` function. (the definition is same
    as in concurrency mode or normal, no need special parameter `chan`, it
    seems like an output parameter in my eyes...why not just return it?)


    (Maybe here, what i'm thinking is the features based on runtime...i'm not
    sure...)
    But i will feel more comfortable if golang has those features.
    --
    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/d/optout.
  • Ian Lance Taylor at May 18, 2016 at 7:17 pm

    On Wed, May 18, 2016 at 10:00 AM, Wang Yarco wrote:
    Now your suggestion is getting more complicated. It becomes more
    detail that the programmer has to remember. I don't think the
    benefits, which are small, are worth the cost.
    You thought it is complicated because you think you need to remember it. But
    actually it does't need you to do so.
    Go is a relatively small and simple language. Everybody who uses it
    should be able to remember the whole language. Anything that makes it
    more complicated needs to bring a corresponding benefit.

    Actually, we stand in different position. When i'm thinking about golang, it
    should be more humanity / easy, efficiency is the 2nd thing;
    but i know you guys don't agree...
    I think we do agree. We just disagree on what is easier.

    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/d/optout.
  • Henry at May 19, 2016 at 4:42 am
    There are some things I disagree. First, template (generics) isn't the absence of types. In fact, generics is there to enforce strong type checking. Instead of writing similar codes for each type you need, the compiler does it for you. It is essentially code generation without cluttering your source files. In Go, interface{} is often abused to fill the role of a void type. Void type is the absence of types. The programmer is required to manually check and assert the types, rather than to have the system does it for you. This is the opposite of strong type checking. The widespread use of void types in Go indicates that there is a need in this area, and I don't think that interface{} is an elegant solution to this.

    Secondly, while Go may be many things to different people, I don't think that Go should be made easy to people first and performance second. Performance is important. There are other languages designed for lay people and I hope Go doesn't end up being one of them. Instead, I think Go should stay on true engineering path and focus on solving problems in an elegant way.

    --
    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/d/optout.
  • As Utf8 at May 20, 2016 at 4:04 am
    Performance is usually ugly, not elegant. There exist myriad languages
    designed for "performance", suffering greatly in usability by putting
    performance on a pedestal without first establishing a definition of the
    term and salient guidelines to keep the language from growing too complex.
    This usually leads to over-optimization and breaking changes, resulting in
    code nobody wants to work with, and if trivialized every few years by
    hardware optimizations, still can't be undone due to complexity and the
    fact that it works. Go programs gain "performance" transparently as the
    runtime improves, more importantly, these internal changes are easy to
    understand and reason about.
    On Wednesday, May 18, 2016 at 9:41:57 PM UTC-7, Henry wrote:

    There are some things I disagree. First, template (generics) isn't the
    absence of types. In fact, generics is there to enforce strong type
    checking. Instead of writing similar codes for each type you need, the
    compiler does it for you. It is essentially code generation without
    cluttering your source files. In Go, interface{} is often abused to fill
    the role of a void type. Void type is the absence of types. The programmer
    is required to manually check and assert the types, rather than to have the
    system does it for you. This is the opposite of strong type checking. The
    widespread use of void types in Go indicates that there is a need in this
    area, and I don't think that interface{} is an elegant solution to this.

    Secondly, while Go may be many things to different people, I don't think
    that Go should be made easy to people first and performance second.
    Performance is important. There are other languages designed for lay people
    and I hope Go doesn't end up being one of them. Instead, I think Go should
    stay on true engineering path and focus on solving problems in an elegant
    way.
    --
    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/d/optout.
  • Wang Yarco at May 20, 2016 at 2:01 am
    @Ian Lance Taylor:
    It was said that in America, they arrange normal guys into jury but not
    those smart guys because of the common sense.
    So if you are an expert, then you can not judge it by your feelings.
    Because you don't have common sense then.
    Even the principle you write here is right, but the common sense is not, so
    beyond the technology, i'm right here.

    @Henry:
    Well, i'm not saying i wanna depends on interface{}, actually, as a human,
    i only want two basic types "numeric" and "string".
    So why i can not have this in computer world?
    Because the whole structure of computer is based on 1 and 0. Then interger
    and float have different pattern in memory, not like in our natrual world,
    you can have x axis which includes all integers and floats and it is
    continuous.
    So the problem is:
       People should invent something which could express something like x
      axis in some precision.
    And if so, there's no integer and float32 and float64, so you don't have to
    cast between those types, you don't need to "writing similar codes for each
    type you need", then no template, no strong type check. So, what i'm saying
    here is:
       The solution `template` actually is middle way cause we don't have
    solution on creating `x axis` such element. And if so, no strong types
    then.
    So if golang is language facing future, it should not worry about types and
    efficiency, strong types etc, even for now, those are reasonable. But for
    future, it should drop them.


    So i don't agree that as a human.

    On Thursday, May 19, 2016 at 3:18:02 AM UTC+8, Ian Lance Taylor wrote:

    On Wed, May 18, 2016 at 10:00 AM, Wang Yarco <yarco...@gmail.com
    <javascript:>> wrote:
    Now your suggestion is getting more complicated. It becomes more
    detail that the programmer has to remember. I don't think the
    benefits, which are small, are worth the cost.
    You thought it is complicated because you think you need to remember it. But
    actually it does't need you to do so.
    Go is a relatively small and simple language. Everybody who uses it
    should be able to remember the whole language. Anything that makes it
    more complicated needs to bring a corresponding benefit.

    Actually, we stand in different position. When i'm thinking about
    golang, it
    should be more humanity / easy, efficiency is the 2nd thing;
    but i know you guys don't agree...
    I think we do agree. We just disagree on what is easier.

    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/d/optout.
  • Wang Yarco at May 20, 2016 at 2:09 am
    It was said that computer beat human in game go, and everyone worry about
    that.
    But human is created by god, computer is created by human -- it seems human
    is more complex than computer.
    So, computer should work for human -- i mean, the programming language
    should be invented tending to human feeling, not computer's feeling.
    On Tuesday, May 17, 2016 at 10:37:27 PM UTC+8, Wang Yarco wrote:

    1. Where is `union`?
    golang uses `struct` as in c. But i noticed `union` is dropped. There is
    composition for interfaces and structs, but it does mean `one and another`
    not `one or another`.
    Then how to define `basic type` but not including those `map`, `array`,
    `slice` etc...
    Ex.:
    type basic bool|int|int32|int64|uint|float32|float64|string...
    those basic types?

    2. OO and PO?
    if they are the same thing, why not when creating:
    func Add(a, b int) int {
    return a + b
    }
    also generating the method (to make things simple):
    func (a int) Add (b int) int {
    return a + b
    }
    and vise versa.

    I mean when create a function `Add`, the compiler will automatically
    create a method for the type of the first argument (as an alias or
    something...)
    - of cause, there may be name conflicts, so i support func overload
    - anonymous func won't have this feature

    3. Runtime channel
    Why not the channel is running in runtime mode? I mean, if so, it seems
    there's no need `go` and `channel` keywords. Ex.:
    func test(ch chan int) {
    ch <- 1
    }

    func main() {
    ch := make(chan int)
    test(ch)
    i := <-ch
    fmt.Println(i)
    }

    It seems useless cause if i can:
    func test() int {
    return 1
    }

    func main() {
    i := <-test()
    // i := test()
    fmt.Println(i)
    }
    operator <- has already figure out `test()` is running in gorountine mode,
    and the return value will be sent in a channel, comparing to the 2nd
    statement.
    So, we don't have to change the `test` function. (the definition is same
    as in concurrency mode or normal, no need special parameter `chan`, it
    seems like an output parameter in my eyes...why not just return it?)


    (Maybe here, what i'm thinking is the features based on runtime...i'm not
    sure...)
    But i will feel more comfortable if golang has those features.
    --
    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/d/optout.
  • Wang Yarco at May 22, 2016 at 12:43 pm
    BTW, go back to my `runtime channel` idea.
    It was said that channel is like a pipe, so, in the code:
    // https://tour.golang.org/concurrency/2
    package main

    import "fmt"

    func sum(s []int, c chan int) {
    sum := 0
    for _, v := range s {
    sum += v
    }
    c <- sum // send sum to c
    }

    func main() {
    s := []int{7, 2, 8, -9, 4, 0}

    c := make(chan int)
    go sum(s[:len(s)/2], c)
    go sum(s[len(s)/2:], c)
    x, y := <-c, <-c // receive from c

    fmt.Println(x, y, x+y)
    }
    The channel `c` is something like a named pipe. According to the knowledge
    of unix system, there can be also unnamed pipe.
    So, i think my suggestion is for unnamed pipe. At least, if so, this
    example can be written as:
    func sum(s []int) {
    sum := 0
    for _, v := range s {
    sum += v
    }
    return sum
    }

    func main() {
    s := []int{7, 2, 8, -9, 4, 0}

    x := <- sum(s[:len(s)/2])
    y := <- sum(s[len(s)/2:])
    fmt.Println(x, y, x+y)
    }
    In this case, the named pipe is not required...
    Of cause, it can not refute the usage of named pipe.

    But i think the code is more clean here...

    On Tuesday, May 17, 2016 at 10:37:27 PM UTC+8, Wang Yarco wrote:

    1. Where is `union`?
    golang uses `struct` as in c. But i noticed `union` is dropped. There is
    composition for interfaces and structs, but it does mean `one and another`
    not `one or another`.
    Then how to define `basic type` but not including those `map`, `array`,
    `slice` etc...
    Ex.:
    type basic bool|int|int32|int64|uint|float32|float64|string...
    those basic types?

    2. OO and PO?
    if they are the same thing, why not when creating:
    func Add(a, b int) int {
    return a + b
    }
    also generating the method (to make things simple):
    func (a int) Add (b int) int {
    return a + b
    }
    and vise versa.

    I mean when create a function `Add`, the compiler will automatically
    create a method for the type of the first argument (as an alias or
    something...)
    - of cause, there may be name conflicts, so i support func overload
    - anonymous func won't have this feature

    3. Runtime channel
    Why not the channel is running in runtime mode? I mean, if so, it seems
    there's no need `go` and `channel` keywords. Ex.:
    func test(ch chan int) {
    ch <- 1
    }

    func main() {
    ch := make(chan int)
    test(ch)
    i := <-ch
    fmt.Println(i)
    }

    It seems useless cause if i can:
    func test() int {
    return 1
    }

    func main() {
    i := <-test()
    // i := test()
    fmt.Println(i)
    }
    operator <- has already figure out `test()` is running in gorountine mode,
    and the return value will be sent in a channel, comparing to the 2nd
    statement.
    So, we don't have to change the `test` function. (the definition is same
    as in concurrency mode or normal, no need special parameter `chan`, it
    seems like an output parameter in my eyes...why not just return it?)


    (Maybe here, what i'm thinking is the features based on runtime...i'm not
    sure...)
    But i will feel more comfortable if golang has those features.
    --
    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/d/optout.
  • Michael Jones at May 22, 2016 at 2:53 pm
    Hello Wang Yarco,

    What you propose is an implicit channel. In this design, code that does a channel receive from a non-channel (which would fail to compile now because of a type mismatch) would cause the construction of an invisible channel wrapper:

    func a() int {}

    func b() {
    :
    x := <- a()
    :
    }

    would mean and compile to

    func b() {
    :
    implicitChannel := make(chan int) // part 1
    go func() {implicitChannel <- a()} // part 1
    x := <- implicitChannel // part 2
    close(implicitChannel) // part 2
    :
    }

    Technically, this automatic transformation would work, but there is a problem that remains to be solved. The problem is where in the sequence of the overall program code to do part 2. Consider:

    func b() {
    :
    x := <- a()
    y := <- b()
    :
    }

    If the part 2 for a() is performed immediately after part 1, then the program must wait for a() to return its value through its implicit channel before b() can be started. This wastes the notion and machinery of concurrency. What you really need is:

    :
    implicitly do part 1 for a() // either order of scatter is fine
    implicitly do part 1 for b()

    then

    implicitly do part 2 for a() // either order of gather is fine
    implicitly do part 2 for b()
    :

    This is what accomplishes your intention. It starts a() and b(), has them run concurrently, and gathers the results. Go can only accomplish this if both part 1 activities happen before the first part 2 causes a wait for a result.

    This "part 2 where" issue is what makes your proposal a challenge. For example, we might tell the compiler to issue part 2 code just before each left hand side value is used. That would make most cases work naturally. However, any change of user’s code that make x and argument of b() would invisibly prevent concurrency and it is easy to imagine that developers would spend a great deal of time trying to debug the sudden performance problem caused by a slight change in the code. (Also, this just in time part 2 approach is harder to implement than it may seem at first. Left-hand sides that update values through a pointer have aliasing issues, and returns and panics could leave channels unclosed. It is complicated.)

    Please think of what you feel would make a good solution here. The answer for part 2 is what can make the idea good.


    Michael Jones, CEO • michael@wearality.com • +1 650 656-6989
    Wearality Corporation • 289 S. San Antonio Road • Los Altos, CA 94022
    On May 22, 2016, at 8:43 AM, Wang Yarco wrote:

    BTW, go back to my `runtime channel` idea.
    It was said that channel is like a pipe, so, in the code:
    // https://tour.golang.org/concurrency/2
    package main

    import "fmt"

    func sum(s []int, c chan int) {
    sum := 0
    for _, v := range s {
    sum += v
    }
    c <- sum // send sum to c
    }

    func main() {
    s := []int{7, 2, 8, -9, 4, 0}

    c := make(chan int)
    go sum(s[:len(s)/2], c)
    go sum(s[len(s)/2:], c)
    x, y := <-c, <-c // receive from c

    fmt.Println(x, y, x+y)
    }
    The channel `c` is something like a named pipe. According to the knowledge of unix system, there can be also unnamed pipe.
    So, i think my suggestion is for unnamed pipe. At least, if so, this example can be written as:
    func sum(s []int) {
    sum := 0
    for _, v := range s {
    sum += v
    }
    return sum
    }

    func main() {
    s := []int{7, 2, 8, -9, 4, 0}

    x := <- sum(s[:len(s)/2])
    y := <- sum(s[len(s)/2:])
    fmt.Println(x, y, x+y)
    }
    In this case, the named pipe is not required...
    Of cause, it can not refute the usage of named pipe.

    But i think the code is more clean here...


    On Tuesday, May 17, 2016 at 10:37:27 PM UTC+8, Wang Yarco wrote:
    1. Where is `union`?
    golang uses `struct` as in c. But i noticed `union` is dropped. There is composition for interfaces and structs, but it does mean `one and another` not `one or another`.
    Then how to define `basic type` but not including those `map`, `array`, `slice` etc...
    Ex.:
    type basic bool|int|int32|int64|uint|float32|float64|string...
    those basic types?

    2. OO and PO?
    if they are the same thing, why not when creating:
    func Add(a, b int) int {
    return a + b
    }
    also generating the method (to make things simple):
    func (a int) Add (b int) int {
    return a + b
    }
    and vise versa.

    I mean when create a function `Add`, the compiler will automatically create a method for the type of the first argument (as an alias or something...)
    - of cause, there may be name conflicts, so i support func overload
    - anonymous func won't have this feature

    3. Runtime channel
    Why not the channel is running in runtime mode? I mean, if so, it seems there's no need `go` and `channel` keywords. Ex.:
    func test(ch chan int) {
    ch <- 1
    }

    func main() {
    ch := make(chan int)
    test(ch)
    i := <-ch
    fmt.Println(i)
    }

    It seems useless cause if i can:
    func test() int {
    return 1
    }

    func main() {
    i := <-test()
    // i := test()
    fmt.Println(i)
    }
    operator <- has already figure out `test()` is running in gorountine mode, and the return value will be sent in a channel, comparing to the 2nd statement.
    So, we don't have to change the `test` function. (the definition is same as in concurrency mode or normal, no need special parameter `chan`, it seems like an output parameter in my eyes...why not just return it?)


    (Maybe here, what i'm thinking is the features based on runtime...i'm not sure...)
    But i will feel more comfortable if golang has those features.

    --
    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/d/optout <https://groups.google.com/d/optout>.
    --
    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/d/optout.
  • Wang Yarco at May 22, 2016 at 4:44 pm
    :) Thanks for providing great information.

    So do you mean, if i write it as following (current golang code):
      go sum(s[:len(s)/2], c)
      x := <-c
    go sum(s[len(s)/2:], c)
    y := <-c
    It also has `This wastes the notion and machinery of concurrency`?

    Then the problem is how you write the code, not the notion itself, right?
    If so, in our case, for those processes need concurrency, just write it as:
    x,y := <-sum(..), <-sum(..)

    The compiler should also arrange the code to:
    implicitChannel1 := make(chan *int*) // part 1
    implicitChannel2 :=make(chan int)// part 1
    go func() {implicitChannel1 <- sum()} // part 1
    go func() {implicitChannel2 <- sum()} // part 1
    x := <- implicitChannel1 // part 2
    y:= <- implicitChannel2 // part 2
    close(implicitChannel1) // part 2
    close(implicitChannel2) // part 2

    I think it is also very sensitive, for you want concurrency between
    `a,b,c`, you write it as:
    x,y,z :=<-a(),<-b(),<-c()
    for you don't care concurrency, you write it as:
    x:=<-a()
    y:=<-b()
    z:=<-c()

    On Sunday, May 22, 2016 at 10:53:48 PM UTC+8, Michael Jones wrote:

    Hello Wang Yarco,

    What you propose is an *implicit channel*. In this design, code that does
    a channel receive from a non-channel (which would fail to compile now
    because of a type mismatch) would cause the construction of an invisible
    channel wrapper:

    func a() *int* {}

    func b() {
    :
    x := <- a()
    :
    }

    would mean and compile to

    func b() {
    :
    implicitChannel := make(chan *int*) // part 1
    go func() {implicitChannel <- a()} // part 1
    x := <- implicitChannel // part 2
    close(implicitChannel) // part 2
    :
    }

    Technically, this automatic transformation would work, but there is a
    problem that remains to be solved. The problem is where in the sequence of
    the overall program code to do part 2. Consider:

    func b() {
    :
    x := <- a()
    y := <- b()
    :
    }

    If the part 2 for a() is performed immediately after part 1, then the
    program must wait for a() to return its value through its implicit channel
    before b() can be started. This wastes the notion and machinery of
    concurrency. What you really need is:

    :
    implicitly do part 1 for a() // either order of scatter is fine
    implicitly do part 1 for b()

    then

    implicitly do part 2 for a() // either order of gather is fine
    implicitly do part 2 for b()
    :

    This is what accomplishes your intention. It starts a() and b(), has them
    run concurrently, and gathers the results. Go can only accomplish this if
    both part 1 activities happen before the first part 2 causes a wait for a
    result.

    This "part 2 where" issue is what makes your proposal a challenge. For
    example, we might tell the compiler to issue part 2 code just before each
    left hand side value is used. That would make most cases work naturally.
    However, any change of user’s code that make x and argument of b() would
    invisibly prevent concurrency and it is easy to imagine that developers
    would spend a great deal of time trying to debug the sudden performance
    problem caused by a slight change in the code. (Also, this just in time
    part 2 approach is harder to implement than it may seem at first. Left-hand
    sides that update values through a pointer have aliasing issues, and
    returns and panics could leave channels unclosed. It is complicated.)

    Please think of what you feel would make a good solution here. The answer
    for part 2 is what can make the idea good.


    Michael Jones, CEO • mic...@wearality.com <javascript:> • +1 650
    656-6989
    Wearality Corporation • 289 S. San Antonio Road • Los Altos, CA 94022

    On May 22, 2016, at 8:43 AM, Wang Yarco <yarco...@gmail.com <javascript:>>
    wrote:

    BTW, go back to my `runtime channel` idea.
    It was said that channel is like a pipe, so, in the code:
    // https://tour.golang.org/concurrency/2
    package main

    import "fmt"

    func sum(s []int, c chan int) {
    sum := 0
    for _, v := range s {
    sum += v
    }
    c <- sum // send sum to c
    }

    func main() {
    s := []int{7, 2, 8, -9, 4, 0}

    c := make(chan int)
    go sum(s[:len(s)/2], c)
    go sum(s[len(s)/2:], c)
    x, y := <-c, <-c // receive from c

    fmt.Println(x, y, x+y)
    }
    The channel `c` is something like a named pipe. According to the knowledge
    of unix system, there can be also unnamed pipe.
    So, i think my suggestion is for unnamed pipe. At least, if so, this
    example can be written as:
    func sum(s []int) {
    sum := 0
    for _, v := range s {
    sum += v
    }
    return sum
    }

    func main() {
    s := []int{7, 2, 8, -9, 4, 0}

    x := <- sum(s[:len(s)/2])
    y := <- sum(s[len(s)/2:])
    fmt.Println(x, y, x+y)
    }
    In this case, the named pipe is not required...
    Of cause, it can not refute the usage of named pipe.

    But i think the code is more clean here...

    On Tuesday, May 17, 2016 at 10:37:27 PM UTC+8, Wang Yarco wrote:

    1. Where is `union`?
    golang uses `struct` as in c. But i noticed `union` is dropped. There is
    composition for interfaces and structs, but it does mean `one and another`
    not `one or another`.
    Then how to define `basic type` but not including those `map`, `array`,
    `slice` etc...
    Ex.:
    type basic bool|int|int32|int64|uint|float32|float64|string...
    those basic types?

    2. OO and PO?
    if they are the same thing, why not when creating:
    func Add(a, b int) int {
    return a + b
    }
    also generating the method (to make things simple):
    func (a int) Add (b int) int {
    return a + b
    }
    and vise versa.

    I mean when create a function `Add`, the compiler will automatically
    create a method for the type of the first argument (as an alias or
    something...)
    - of cause, there may be name conflicts, so i support func overload
    - anonymous func won't have this feature

    3. Runtime channel
    Why not the channel is running in runtime mode? I mean, if so, it seems
    there's no need `go` and `channel` keywords. Ex.:
    func test(ch chan int) {
    ch <- 1
    }

    func main() {
    ch := make(chan int)
    test(ch)
    i := <-ch
    fmt.Println(i)
    }

    It seems useless cause if i can:
    func test() int {
    return 1
    }

    func main() {
    i := <-test()
    // i := test()
    fmt.Println(i)
    }
    operator <- has already figure out `test()` is running in gorountine
    mode, and the return value will be sent in a channel, comparing to the 2nd
    statement.
    So, we don't have to change the `test` function. (the definition is same
    as in concurrency mode or normal, no need special parameter `chan`, it
    seems like an output parameter in my eyes...why not just return it?)


    (Maybe here, what i'm thinking is the features based on runtime...i'm not
    sure...)
    But i will feel more comfortable if golang has those features.
    --
    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/d/optout.

    --
    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/d/optout.
  • Michael Jones at May 22, 2016 at 6:24 pm

    So do you mean, if i write it as following (current golang code):
    go sum(s[:len(s)/2], c)
    x := <-c
    go sum(s[len(s)/2:], c)
    y := <-c
    It also has `This wastes the notion and machinery of concurrency`?
    Yes, this code means:

    1. Start a goroutine summing s[:len(s)/2] and when you are done, write to channel c
    2. Wait for a result on channel c and put into the integer variable x
    3. Start a goroutine summing s[len(s)/2:] and when you are done, write to channel c
    4. Wait for a result on channel c and put into the integer variable y

    This is exactly...

    x := sum(s[:len(s)/2])
    y := sum(s[len(s)/2:])

    ...except that it has more overhead and complexity.

    The right way is:

    go sum(s[:len(s)/2], c)
    go sum(s[len(s)/2:], c)
    x := <-c
    y := <-c

    …because that means:

    1. Start a groutine summing s[:len(s)/2] and when you are done, write to channel c
    2. Start a groutine summing s[len(s)/2:] and when you are done, write to channel c
    3. Wait for a result on channel c and put into the integer variable x
    4. Wait for a result on channel c and put into the integer variable y

    ...and this overlaps the calls to sum() when you have multiple execution units, even if you don’t, it lets you get the first result (x) and work with it while you wait for the second one (y). If you want this freedom, then you wold not want parallel assignments as in your example. When you don’t need the freedom, them parallel assignment would be a nice way to express the order independence on the right-hand side.


    Michael Jones, CEO • michael@wearality.com • +1 650 656-6989
    Wearality Corporation • 289 S. San Antonio Road • Los Altos, CA 94022
    On May 22, 2016, at 12:44 PM, Wang Yarco wrote:

    :) Thanks for providing great information.

    So do you mean, if i write it as following (current golang code):
    go sum(s[:len(s)/2], c)
    x := <-c
    go sum(s[len(s)/2:], c)
    y := <-c
    It also has `This wastes the notion and machinery of concurrency`?

    Then the problem is how you write the code, not the notion itself, right?
    If so, in our case, for those processes need concurrency, just write it as:
    x,y := <-sum(..), <-sum(..)

    The compiler should also arrange the code to:
    implicitChannel1 := make(chan int) // part 1
    implicitChannel2 :=make(chan int)// part 1
    go func() {implicitChannel1 <- sum()} // part 1
    go func() {implicitChannel2 <- sum()} // part 1
    x := <- implicitChannel1 // part 2
    y:= <- implicitChannel2 // part 2
    close(implicitChannel1) // part 2
    close(implicitChannel2) // part 2

    I think it is also very sensitive, for you want concurrency between `a,b,c`, you write it as:
    x,y,z :=<-a(),<-b(),<-c()
    for you don't care concurrency, you write it as:
    x:=<-a()
    y:=<-b()
    z:=<-c()


    On Sunday, May 22, 2016 at 10:53:48 PM UTC+8, Michael Jones wrote:
    Hello Wang Yarco,

    What you propose is an implicit channel. In this design, code that does a channel receive from a non-channel (which would fail to compile now because of a type mismatch) would cause the construction of an invisible channel wrapper:

    func a() int {}

    func b() {
    :
    x := <- a()
    :
    }

    would mean and compile to

    func b() {
    :
    implicitChannel := make(chan int) // part 1
    go func() {implicitChannel <- a()} // part 1
    x := <- implicitChannel // part 2
    close(implicitChannel) // part 2
    :
    }

    Technically, this automatic transformation would work, but there is a problem that remains to be solved. The problem is where in the sequence of the overall program code to do part 2. Consider:

    func b() {
    :
    x := <- a()
    y := <- b()
    :
    }

    If the part 2 for a() is performed immediately after part 1, then the program must wait for a() to return its value through its implicit channel before b() can be started. This wastes the notion and machinery of concurrency. What you really need is:

    :
    implicitly do part 1 for a() // either order of scatter is fine
    implicitly do part 1 for b()

    then

    implicitly do part 2 for a() // either order of gather is fine
    implicitly do part 2 for b()
    :

    This is what accomplishes your intention. It starts a() and b(), has them run concurrently, and gathers the results. Go can only accomplish this if both part 1 activities happen before the first part 2 causes a wait for a result.

    This "part 2 where" issue is what makes your proposal a challenge. For example, we might tell the compiler to issue part 2 code just before each left hand side value is used. That would make most cases work naturally. However, any change of user’s code that make x and argument of b() would invisibly prevent concurrency and it is easy to imagine that developers would spend a great deal of time trying to debug the sudden performance problem caused by a slight change in the code. (Also, this just in time part 2 approach is harder to implement than it may seem at first. Left-hand sides that update values through a pointer have aliasing issues, and returns and panics could leave channels unclosed. It is complicated.)

    Please think of what you feel would make a good solution here. The answer for part 2 is what can make the idea good.


    Michael Jones, CEO • mic...@ <>wearality.com <http://wearality.com/> • +1 650 656-6989
    Wearality Corporation • 289 S. San Antonio Road • Los Altos, CA 94022
    On May 22, 2016, at 8:43 AM, Wang Yarco <yarco...@ <>gmail.com <http://gmail.com/>> wrote:

    BTW, go back to my `runtime channel` idea.
    It was said that channel is like a pipe, so, in the code:
    // https://tour.golang.org/concurrency/2 <https://tour.golang.org/concurrency/2>
    package main

    import "fmt"

    func sum(s []int, c chan int) {
    sum := 0
    for _, v := range s {
    sum += v
    }
    c <- sum // send sum to c
    }

    func main() {
    s := []int{7, 2, 8, -9, 4, 0}

    c := make(chan int)
    go sum(s[:len(s)/2], c)
    go sum(s[len(s)/2:], c)
    x, y := <-c, <-c // receive from c

    fmt.Println(x, y, x+y)
    }
    The channel `c` is something like a named pipe. According to the knowledge of unix system, there can be also unnamed pipe.
    So, i think my suggestion is for unnamed pipe. At least, if so, this example can be written as:
    func sum(s []int) {
    sum := 0
    for _, v := range s {
    sum += v
    }
    return sum
    }

    func main() {
    s := []int{7, 2, 8, -9, 4, 0}

    x := <- sum(s[:len(s)/2])
    y := <- sum(s[len(s)/2:])
    fmt.Println(x, y, x+y)
    }
    In this case, the named pipe is not required...
    Of cause, it can not refute the usage of named pipe.

    But i think the code is more clean here...


    On Tuesday, May 17, 2016 at 10:37:27 PM UTC+8, Wang Yarco wrote:
    1. Where is `union`?
    golang uses `struct` as in c. But i noticed `union` is dropped. There is composition for interfaces and structs, but it does mean `one and another` not `one or another`.
    Then how to define `basic type` but not including those `map`, `array`, `slice` etc...
    Ex.:
    type basic bool|int|int32|int64|uint|float32|float64|string...
    those basic types?

    2. OO and PO?
    if they are the same thing, why not when creating:
    func Add(a, b int) int {
    return a + b
    }
    also generating the method (to make things simple):
    func (a int) Add (b int) int {
    return a + b
    }
    and vise versa.

    I mean when create a function `Add`, the compiler will automatically create a method for the type of the first argument (as an alias or something...)
    - of cause, there may be name conflicts, so i support func overload
    - anonymous func won't have this feature

    3. Runtime channel
    Why not the channel is running in runtime mode? I mean, if so, it seems there's no need `go` and `channel` keywords. Ex.:
    func test(ch chan int) {
    ch <- 1
    }

    func main() {
    ch := make(chan int)
    test(ch)
    i := <-ch
    fmt.Println(i)
    }

    It seems useless cause if i can:
    func test() int {
    return 1
    }

    func main() {
    i := <-test()
    // i := test()
    fmt.Println(i)
    }
    operator <- has already figure out `test()` is running in gorountine mode, and the return value will be sent in a channel, comparing to the 2nd statement.
    So, we don't have to change the `test` function. (the definition is same as in concurrency mode or normal, no need special parameter `chan`, it seems like an output parameter in my eyes...why not just return it?)


    (Maybe here, what i'm thinking is the features based on runtime...i'm not sure...)
    But i will feel more comfortable if golang has those features.

    --
    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 <http://googlegroups.com/>.
    For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

    --
    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/d/optout <https://groups.google.com/d/optout>.
    --
    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/d/optout.
  • Wang Yarco at May 23, 2016 at 1:34 am
    Thanks. So this idea could work except it requires a lot efforts on the
    current golang implementation?
    On Monday, May 23, 2016 at 2:25:02 AM UTC+8, Michael Jones wrote:

    So do you mean, if i write it as following (current golang code):
    go sum(s[:len(s)/2], c)
    x := <-c
    go sum(s[len(s)/2:], c)
    y := <-c
    It also has `This wastes the notion and machinery of concurrency`?


    Yes, this code means:

    1. Start a goroutine summing s[:len(s)/2] and when you are done, write to
    channel c
    2. Wait for a result on channel c and put into the integer variable x
    3. Start a goroutine summing s[len(s)/2:] and when you are done, write to
    channel c
    4. Wait for a result on channel c and put into the integer variable y

    This is exactly...

    x := sum(s[:len(s)/2])
    y := sum(s[len(s)/2:])

    ...except that it has more overhead and complexity.

    The right way is:

    go sum(s[:len(s)/2], c)
    go sum(s[len(s)/2:], c)
    x := <-c
    y := <-c

    …because that means:

    1. Start a groutine summing s[:len(s)/2] and when you are done, write to
    channel c
    2. Start a groutine summing s[len(s)/2:] and when you are done, write to
    channel c
    3. Wait for a result on channel c and put into the integer variable x
    4. Wait for a result on channel c and put into the integer variable y

    ...and this overlaps the calls to sum() when you have multiple execution
    units, even if you don’t, it lets you get the first result (x) and work
    with it while you wait for the second one (y). If you want this freedom,
    then you wold not want parallel assignments as in your example. When you
    don’t need the freedom, them parallel assignment would be a nice way to
    express the order independence on the right-hand side.


    Michael Jones, CEO • mic...@wearality.com <javascript:> • +1 650
    656-6989
    Wearality Corporation • 289 S. San Antonio Road • Los Altos, CA 94022

    On May 22, 2016, at 12:44 PM, Wang Yarco <yarco...@gmail.com <javascript:>>
    wrote:

    :) Thanks for providing great information.

    So do you mean, if i write it as following (current golang code):
    go sum(s[:len(s)/2], c)
    x := <-c
    go sum(s[len(s)/2:], c)
    y := <-c
    It also has `This wastes the notion and machinery of concurrency`?

    Then the problem is how you write the code, not the notion itself, right?
    If so, in our case, for those processes need concurrency, just write it as:
    x,y := <-sum(..), <-sum(..)

    The compiler should also arrange the code to:
    implicitChannel1 := make(chan *int*) // part 1
    implicitChannel2 :=make(chan int)// part 1
    go func() {implicitChannel1 <- sum()} // part 1
    go func() {implicitChannel2 <- sum()} // part 1
    x := <- implicitChannel1 // part 2
    y:= <- implicitChannel2 // part 2
    close(implicitChannel1) // part 2
    close(implicitChannel2) // part 2

    I think it is also very sensitive, for you want concurrency between
    `a,b,c`, you write it as:
    x,y,z :=<-a(),<-b(),<-c()
    for you don't care concurrency, you write it as:
    x:=<-a()
    y:=<-b()
    z:=<-c()

    On Sunday, May 22, 2016 at 10:53:48 PM UTC+8, Michael Jones wrote:

    Hello Wang Yarco,

    What you propose is an *implicit channel*. In this design, code that
    does a channel receive from a non-channel (which would fail to compile now
    because of a type mismatch) would cause the construction of an invisible
    channel wrapper:

    func a() *int* {}

    func b() {
    :
    x := <- a()
    :
    }

    would mean and compile to

    func b() {
    :
    implicitChannel := make(chan *int*) // part 1
    go func() {implicitChannel <- a()} // part 1
    x := <- implicitChannel // part 2
    close(implicitChannel) // part 2
    :
    }

    Technically, this automatic transformation would work, but there is a
    problem that remains to be solved. The problem is where in the sequence of
    the overall program code to do part 2. Consider:

    func b() {
    :
    x := <- a()
    y := <- b()
    :
    }

    If the part 2 for a() is performed immediately after part 1, then the
    program must wait for a() to return its value through its implicit channel
    before b() can be started. This wastes the notion and machinery of
    concurrency. What you really need is:

    :
    implicitly do part 1 for a() // either order of scatter is fine
    implicitly do part 1 for b()

    then

    implicitly do part 2 for a() // either order of gather is fine
    implicitly do part 2 for b()
    :

    This is what accomplishes your intention. It starts a() and b(), has them
    run concurrently, and gathers the results. Go can only accomplish this if
    both part 1 activities happen before the first part 2 causes a wait for a
    result.

    This "part 2 where" issue is what makes your proposal a challenge. For
    example, we might tell the compiler to issue part 2 code just before each
    left hand side value is used. That would make most cases work naturally.
    However, any change of user’s code that make x and argument of b() would
    invisibly prevent concurrency and it is easy to imagine that developers
    would spend a great deal of time trying to debug the sudden performance
    problem caused by a slight change in the code. (Also, this just in time
    part 2 approach is harder to implement than it may seem at first. Left-hand
    sides that update values through a pointer have aliasing issues, and
    returns and panics could leave channels unclosed. It is complicated.)

    Please think of what you feel would make a good solution here. The answer
    for part 2 is what can make the idea good.


    Michael Jones, CEO • mic...@wearality.com • +1 650 656-6989
    Wearality Corporation • 289 S. San Antonio Road • Los Altos, CA 94022

    On May 22, 2016, at 8:43 AM, Wang Yarco wrote:

    BTW, go back to my `runtime channel` idea.
    It was said that channel is like a pipe, so, in the code:
    // https://tour.golang.org/concurrency/2
    package main

    import "fmt"

    func sum(s []int, c chan int) {
    sum := 0
    for _, v := range s {
    sum += v
    }
    c <- sum // send sum to c
    }

    func main() {
    s := []int{7, 2, 8, -9, 4, 0}

    c := make(chan int)
    go sum(s[:len(s)/2], c)
    go sum(s[len(s)/2:], c)
    x, y := <-c, <-c // receive from c

    fmt.Println(x, y, x+y)
    }
    The channel `c` is something like a named pipe. According to the
    knowledge of unix system, there can be also unnamed pipe.
    So, i think my suggestion is for unnamed pipe. At least, if so, this
    example can be written as:
    func sum(s []int) {
    sum := 0
    for _, v := range s {
    sum += v
    }
    return sum
    }

    func main() {
    s := []int{7, 2, 8, -9, 4, 0}

    x := <- sum(s[:len(s)/2])
    y := <- sum(s[len(s)/2:])
    fmt.Println(x, y, x+y)
    }
    In this case, the named pipe is not required...
    Of cause, it can not refute the usage of named pipe.

    But i think the code is more clean here...

    On Tuesday, May 17, 2016 at 10:37:27 PM UTC+8, Wang Yarco wrote:

    1. Where is `union`?
    golang uses `struct` as in c. But i noticed `union` is dropped. There is
    composition for interfaces and structs, but it does mean `one and another`
    not `one or another`.
    Then how to define `basic type` but not including those `map`, `array`,
    `slice` etc...
    Ex.:
    type basic bool|int|int32|int64|uint|float32|float64|string...
    those basic types?

    2. OO and PO?
    if they are the same thing, why not when creating:
    func Add(a, b int) int {
    return a + b
    }
    also generating the method (to make things simple):
    func (a int) Add (b int) int {
    return a + b
    }
    and vise versa.

    I mean when create a function `Add`, the compiler will automatically
    create a method for the type of the first argument (as an alias or
    something...)
    - of cause, there may be name conflicts, so i support func overload
    - anonymous func won't have this feature

    3. Runtime channel
    Why not the channel is running in runtime mode? I mean, if so, it seems
    there's no need `go` and `channel` keywords. Ex.:
    func test(ch chan int) {
    ch <- 1
    }

    func main() {
    ch := make(chan int)
    test(ch)
    i := <-ch
    fmt.Println(i)
    }

    It seems useless cause if i can:
    func test() int {
    return 1
    }

    func main() {
    i := <-test()
    // i := test()
    fmt.Println(i)
    }
    operator <- has already figure out `test()` is running in gorountine
    mode, and the return value will be sent in a channel, comparing to the 2nd
    statement.
    So, we don't have to change the `test` function. (the definition is same
    as in concurrency mode or normal, no need special parameter `chan`, it
    seems like an output parameter in my eyes...why not just return it?)


    (Maybe here, what i'm thinking is the features based on runtime...i'm
    not sure...)
    But i will feel more comfortable if golang has those features.
    --
    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.
    For more options, visit https://groups.google.com/d/optout.

    --
    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/d/optout.

    --
    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/d/optout.
  • Xingtao zhao at May 23, 2016 at 6:46 pm
    The problem is that the semantic of the translation is not clear:

    x,y,z := <-sum(..), F(), <-sum(..)

    Where should F() be called?

    implicitChannel1 := make(chan int) // part 1
    implicitChannel2 :=make(chan int)// part 1
    go func() {implicitChannel1 <- sum()} // part 1
    go func() {implicitChannel2 <- sum()} // part 1
    x := <- implicitChannel1 // part 2
    z := <- implicitChannel2 // part 2
    close(implicitChannel1) // part 2
    close(implicitChannel2) // part 2

    If you simply disallow this kind of syntax, then the usage of it will be
    very limited. The question will be if it worth to do that? And let alone it
    breaks the semantic of multi-assignment.

    On Sunday, May 22, 2016 at 6:34:23 PM UTC-7, Wang Yarco wrote:

    Thanks. So this idea could work except it requires a lot efforts on the
    current golang implementation?
    On Monday, May 23, 2016 at 2:25:02 AM UTC+8, Michael Jones wrote:

    So do you mean, if i write it as following (current golang code):
    go sum(s[:len(s)/2], c)
    x := <-c
    go sum(s[len(s)/2:], c)
    y := <-c
    It also has `This wastes the notion and machinery of concurrency`?


    Yes, this code means:

    1. Start a goroutine summing s[:len(s)/2] and when you are done, write to
    channel c
    2. Wait for a result on channel c and put into the integer variable x
    3. Start a goroutine summing s[len(s)/2:] and when you are done, write to
    channel c
    4. Wait for a result on channel c and put into the integer variable y

    This is exactly...

    x := sum(s[:len(s)/2])
    y := sum(s[len(s)/2:])

    ...except that it has more overhead and complexity.

    The right way is:

    go sum(s[:len(s)/2], c)
    go sum(s[len(s)/2:], c)
    x := <-c
    y := <-c

    …because that means:

    1. Start a groutine summing s[:len(s)/2] and when you are done, write to
    channel c
    2. Start a groutine summing s[len(s)/2:] and when you are done, write to
    channel c
    3. Wait for a result on channel c and put into the integer variable x
    4. Wait for a result on channel c and put into the integer variable y

    ...and this overlaps the calls to sum() when you have multiple execution
    units, even if you don’t, it lets you get the first result (x) and work
    with it while you wait for the second one (y). If you want this freedom,
    then you wold not want parallel assignments as in your example. When you
    don’t need the freedom, them parallel assignment would be a nice way to
    express the order independence on the right-hand side.


    Michael Jones, CEO • mic...@wearality.com • +1 650 656-6989
    Wearality Corporation • 289 S. San Antonio Road • Los Altos, CA 94022

    On May 22, 2016, at 12:44 PM, Wang Yarco wrote:

    :) Thanks for providing great information.

    So do you mean, if i write it as following (current golang code):
    go sum(s[:len(s)/2], c)
    x := <-c
    go sum(s[len(s)/2:], c)
    y := <-c
    It also has `This wastes the notion and machinery of concurrency`?

    Then the problem is how you write the code, not the notion itself, right?
    If so, in our case, for those processes need concurrency, just write it
    as:
    x,y := <-sum(..), <-sum(..)

    The compiler should also arrange the code to:
    implicitChannel1 := make(chan *int*) // part 1
    implicitChannel2 :=make(chan int)// part 1
    go func() {implicitChannel1 <- sum()} // part 1
    go func() {implicitChannel2 <- sum()} // part 1
    x := <- implicitChannel1 // part 2
    y:= <- implicitChannel2 // part 2
    close(implicitChannel1) // part 2
    close(implicitChannel2) // part 2

    I think it is also very sensitive, for you want concurrency between
    `a,b,c`, you write it as:
    x,y,z :=<-a(),<-b(),<-c()
    for you don't care concurrency, you write it as:
    x:=<-a()
    y:=<-b()
    z:=<-c()

    On Sunday, May 22, 2016 at 10:53:48 PM UTC+8, Michael Jones wrote:

    Hello Wang Yarco,

    What you propose is an *implicit channel*. In this design, code that
    does a channel receive from a non-channel (which would fail to compile now
    because of a type mismatch) would cause the construction of an invisible
    channel wrapper:

    func a() *int* {}

    func b() {
    :
    x := <- a()
    :
    }

    would mean and compile to

    func b() {
    :
    implicitChannel := make(chan *int*) // part 1
    go func() {implicitChannel <- a()} // part 1
    x := <- implicitChannel // part 2
    close(implicitChannel) // part 2
    :
    }

    Technically, this automatic transformation would work, but there is a
    problem that remains to be solved. The problem is where in the sequence of
    the overall program code to do part 2. Consider:

    func b() {
    :
    x := <- a()
    y := <- b()
    :
    }

    If the part 2 for a() is performed immediately after part 1, then the
    program must wait for a() to return its value through its implicit channel
    before b() can be started. This wastes the notion and machinery of
    concurrency. What you really need is:

    :
    implicitly do part 1 for a() // either order of scatter is fine
    implicitly do part 1 for b()

    then

    implicitly do part 2 for a() // either order of gather is fine
    implicitly do part 2 for b()
    :

    This is what accomplishes your intention. It starts a() and b(), has
    them run concurrently, and gathers the results. Go can only accomplish this
    if both part 1 activities happen before the first part 2 causes a wait for
    a result.

    This "part 2 where" issue is what makes your proposal a challenge. For
    example, we might tell the compiler to issue part 2 code just before each
    left hand side value is used. That would make most cases work naturally.
    However, any change of user’s code that make x and argument of b() would
    invisibly prevent concurrency and it is easy to imagine that developers
    would spend a great deal of time trying to debug the sudden performance
    problem caused by a slight change in the code. (Also, this just in time
    part 2 approach is harder to implement than it may seem at first. Left-hand
    sides that update values through a pointer have aliasing issues, and
    returns and panics could leave channels unclosed. It is complicated.)

    Please think of what you feel would make a good solution here. The
    answer for part 2 is what can make the idea good.


    Michael Jones, CEO • mic...@wearality.com • +1 650 656-6989
    Wearality Corporation • 289 S. San Antonio Road • Los Altos, CA
    94022

    On May 22, 2016, at 8:43 AM, Wang Yarco wrote:

    BTW, go back to my `runtime channel` idea.
    It was said that channel is like a pipe, so, in the code:
    // https://tour.golang.org/concurrency/2
    package main

    import "fmt"

    func sum(s []int, c chan int) {
    sum := 0
    for _, v := range s {
    sum += v
    }
    c <- sum // send sum to c
    }

    func main() {
    s := []int{7, 2, 8, -9, 4, 0}

    c := make(chan int)
    go sum(s[:len(s)/2], c)
    go sum(s[len(s)/2:], c)
    x, y := <-c, <-c // receive from c

    fmt.Println(x, y, x+y)
    }
    The channel `c` is something like a named pipe. According to the
    knowledge of unix system, there can be also unnamed pipe.
    So, i think my suggestion is for unnamed pipe. At least, if so, this
    example can be written as:
    func sum(s []int) {
    sum := 0
    for _, v := range s {
    sum += v
    }
    return sum
    }

    func main() {
    s := []int{7, 2, 8, -9, 4, 0}

    x := <- sum(s[:len(s)/2])
    y := <- sum(s[len(s)/2:])
    fmt.Println(x, y, x+y)
    }
    In this case, the named pipe is not required...
    Of cause, it can not refute the usage of named pipe.

    But i think the code is more clean here...

    On Tuesday, May 17, 2016 at 10:37:27 PM UTC+8, Wang Yarco wrote:

    1. Where is `union`?
    golang uses `struct` as in c. But i noticed `union` is dropped. There
    is composition for interfaces and structs, but it does mean `one and
    another` not `one or another`.
    Then how to define `basic type` but not including those `map`,
    `array`, `slice` etc...
    Ex.:
    type basic bool|int|int32|int64|uint|float32|float64|string...
    those basic types?

    2. OO and PO?
    if they are the same thing, why not when creating:
    func Add(a, b int) int {
    return a + b
    }
    also generating the method (to make things simple):
    func (a int) Add (b int) int {
    return a + b
    }
    and vise versa.

    I mean when create a function `Add`, the compiler will automatically
    create a method for the type of the first argument (as an alias or
    something...)
    - of cause, there may be name conflicts, so i support func overload
    - anonymous func won't have this feature

    3. Runtime channel
    Why not the channel is running in runtime mode? I mean, if so, it seems
    there's no need `go` and `channel` keywords. Ex.:
    func test(ch chan int) {
    ch <- 1
    }

    func main() {
    ch := make(chan int)
    test(ch)
    i := <-ch
    fmt.Println(i)
    }

    It seems useless cause if i can:
    func test() int {
    return 1
    }

    func main() {
    i := <-test()
    // i := test()
    fmt.Println(i)
    }
    operator <- has already figure out `test()` is running in gorountine
    mode, and the return value will be sent in a channel, comparing to the 2nd
    statement.
    So, we don't have to change the `test` function. (the definition is
    same as in concurrency mode or normal, no need special parameter `chan`, it
    seems like an output parameter in my eyes...why not just return it?)


    (Maybe here, what i'm thinking is the features based on runtime...i'm
    not sure...)
    But i will feel more comfortable if golang has those features.
    --
    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.
    For more options, visit https://groups.google.com/d/optout.

    --
    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.
    For more options, visit https://groups.google.com/d/optout.

    --
    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/d/optout.
  • Konstantin Shaposhnikov at May 24, 2016 at 12:01 am
    If f() returns a channel then x := <- f() is already a valid expression in
    Go (https://play.golang.org/p/AE_RaxPWaq). I beleive you will have to come
    up with different syntax for your proposal.
    On Monday, 23 May 2016 09:34:23 UTC+8, Wang Yarco wrote:

    Thanks. So this idea could work except it requires a lot efforts on the
    current golang implementation?
    On Monday, May 23, 2016 at 2:25:02 AM UTC+8, Michael Jones wrote:

    So do you mean, if i write it as following (current golang code):
    go sum(s[:len(s)/2], c)
    x := <-c
    go sum(s[len(s)/2:], c)
    y := <-c
    It also has `This wastes the notion and machinery of concurrency`?


    Yes, this code means:

    1. Start a goroutine summing s[:len(s)/2] and when you are done, write to
    channel c
    2. Wait for a result on channel c and put into the integer variable x
    3. Start a goroutine summing s[len(s)/2:] and when you are done, write to
    channel c
    4. Wait for a result on channel c and put into the integer variable y

    This is exactly...

    x := sum(s[:len(s)/2])
    y := sum(s[len(s)/2:])

    ...except that it has more overhead and complexity.

    The right way is:

    go sum(s[:len(s)/2], c)
    go sum(s[len(s)/2:], c)
    x := <-c
    y := <-c

    …because that means:

    1. Start a groutine summing s[:len(s)/2] and when you are done, write to
    channel c
    2. Start a groutine summing s[len(s)/2:] and when you are done, write to
    channel c
    3. Wait for a result on channel c and put into the integer variable x
    4. Wait for a result on channel c and put into the integer variable y

    ...and this overlaps the calls to sum() when you have multiple execution
    units, even if you don’t, it lets you get the first result (x) and work
    with it while you wait for the second one (y). If you want this freedom,
    then you wold not want parallel assignments as in your example. When you
    don’t need the freedom, them parallel assignment would be a nice way to
    express the order independence on the right-hand side.


    Michael Jones, CEO • mic...@wearality.com • +1 650 656-6989
    Wearality Corporation • 289 S. San Antonio Road • Los Altos, CA 94022

    On May 22, 2016, at 12:44 PM, Wang Yarco wrote:

    :) Thanks for providing great information.

    So do you mean, if i write it as following (current golang code):
    go sum(s[:len(s)/2], c)
    x := <-c
    go sum(s[len(s)/2:], c)
    y := <-c
    It also has `This wastes the notion and machinery of concurrency`?

    Then the problem is how you write the code, not the notion itself, right?
    If so, in our case, for those processes need concurrency, just write it
    as:
    x,y := <-sum(..), <-sum(..)

    The compiler should also arrange the code to:
    implicitChannel1 := make(chan *int*) // part 1
    implicitChannel2 :=make(chan int)// part 1
    go func() {implicitChannel1 <- sum()} // part 1
    go func() {implicitChannel2 <- sum()} // part 1
    x := <- implicitChannel1 // part 2
    y:= <- implicitChannel2 // part 2
    close(implicitChannel1) // part 2
    close(implicitChannel2) // part 2

    I think it is also very sensitive, for you want concurrency between
    `a,b,c`, you write it as:
    x,y,z :=<-a(),<-b(),<-c()
    for you don't care concurrency, you write it as:
    x:=<-a()
    y:=<-b()
    z:=<-c()

    On Sunday, May 22, 2016 at 10:53:48 PM UTC+8, Michael Jones wrote:

    Hello Wang Yarco,

    What you propose is an *implicit channel*. In this design, code that
    does a channel receive from a non-channel (which would fail to compile now
    because of a type mismatch) would cause the construction of an invisible
    channel wrapper:

    func a() *int* {}

    func b() {
    :
    x := <- a()
    :
    }

    would mean and compile to

    func b() {
    :
    implicitChannel := make(chan *int*) // part 1
    go func() {implicitChannel <- a()} // part 1
    x := <- implicitChannel // part 2
    close(implicitChannel) // part 2
    :
    }

    Technically, this automatic transformation would work, but there is a
    problem that remains to be solved. The problem is where in the sequence of
    the overall program code to do part 2. Consider:

    func b() {
    :
    x := <- a()
    y := <- b()
    :
    }

    If the part 2 for a() is performed immediately after part 1, then the
    program must wait for a() to return its value through its implicit channel
    before b() can be started. This wastes the notion and machinery of
    concurrency. What you really need is:

    :
    implicitly do part 1 for a() // either order of scatter is fine
    implicitly do part 1 for b()

    then

    implicitly do part 2 for a() // either order of gather is fine
    implicitly do part 2 for b()
    :

    This is what accomplishes your intention. It starts a() and b(), has
    them run concurrently, and gathers the results. Go can only accomplish this
    if both part 1 activities happen before the first part 2 causes a wait for
    a result.

    This "part 2 where" issue is what makes your proposal a challenge. For
    example, we might tell the compiler to issue part 2 code just before each
    left hand side value is used. That would make most cases work naturally.
    However, any change of user’s code that make x and argument of b() would
    invisibly prevent concurrency and it is easy to imagine that developers
    would spend a great deal of time trying to debug the sudden performance
    problem caused by a slight change in the code. (Also, this just in time
    part 2 approach is harder to implement than it may seem at first. Left-hand
    sides that update values through a pointer have aliasing issues, and
    returns and panics could leave channels unclosed. It is complicated.)

    Please think of what you feel would make a good solution here. The
    answer for part 2 is what can make the idea good.


    Michael Jones, CEO • mic...@wearality.com • +1 650 656-6989
    Wearality Corporation • 289 S. San Antonio Road • Los Altos, CA
    94022

    On May 22, 2016, at 8:43 AM, Wang Yarco wrote:

    BTW, go back to my `runtime channel` idea.
    It was said that channel is like a pipe, so, in the code:
    // https://tour.golang.org/concurrency/2
    package main

    import "fmt"

    func sum(s []int, c chan int) {
    sum := 0
    for _, v := range s {
    sum += v
    }
    c <- sum // send sum to c
    }

    func main() {
    s := []int{7, 2, 8, -9, 4, 0}

    c := make(chan int)
    go sum(s[:len(s)/2], c)
    go sum(s[len(s)/2:], c)
    x, y := <-c, <-c // receive from c

    fmt.Println(x, y, x+y)
    }
    The channel `c` is something like a named pipe. According to the
    knowledge of unix system, there can be also unnamed pipe.
    So, i think my suggestion is for unnamed pipe. At least, if so, this
    example can be written as:
    func sum(s []int) {
    sum := 0
    for _, v := range s {
    sum += v
    }
    return sum
    }

    func main() {
    s := []int{7, 2, 8, -9, 4, 0}

    x := <- sum(s[:len(s)/2])
    y := <- sum(s[len(s)/2:])
    fmt.Println(x, y, x+y)
    }
    In this case, the named pipe is not required...
    Of cause, it can not refute the usage of named pipe.

    But i think the code is more clean here...

    On Tuesday, May 17, 2016 at 10:37:27 PM UTC+8, Wang Yarco wrote:

    1. Where is `union`?
    golang uses `struct` as in c. But i noticed `union` is dropped. There
    is composition for interfaces and structs, but it does mean `one and
    another` not `one or another`.
    Then how to define `basic type` but not including those `map`,
    `array`, `slice` etc...
    Ex.:
    type basic bool|int|int32|int64|uint|float32|float64|string...
    those basic types?

    2. OO and PO?
    if they are the same thing, why not when creating:
    func Add(a, b int) int {
    return a + b
    }
    also generating the method (to make things simple):
    func (a int) Add (b int) int {
    return a + b
    }
    and vise versa.

    I mean when create a function `Add`, the compiler will automatically
    create a method for the type of the first argument (as an alias or
    something...)
    - of cause, there may be name conflicts, so i support func overload
    - anonymous func won't have this feature

    3. Runtime channel
    Why not the channel is running in runtime mode? I mean, if so, it seems
    there's no need `go` and `channel` keywords. Ex.:
    func test(ch chan int) {
    ch <- 1
    }

    func main() {
    ch := make(chan int)
    test(ch)
    i := <-ch
    fmt.Println(i)
    }

    It seems useless cause if i can:
    func test() int {
    return 1
    }

    func main() {
    i := <-test()
    // i := test()
    fmt.Println(i)
    }
    operator <- has already figure out `test()` is running in gorountine
    mode, and the return value will be sent in a channel, comparing to the 2nd
    statement.
    So, we don't have to change the `test` function. (the definition is
    same as in concurrency mode or normal, no need special parameter `chan`, it
    seems like an output parameter in my eyes...why not just return it?)


    (Maybe here, what i'm thinking is the features based on runtime...i'm
    not sure...)
    But i will feel more comfortable if golang has those features.
    --
    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.
    For more options, visit https://groups.google.com/d/optout.

    --
    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.
    For more options, visit https://groups.google.com/d/optout.

    --
    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/d/optout.
  • Wang Yarco at May 24, 2016 at 12:23 am
    @xingtao zhao:
    implicitChannel1 := make(chan int) // part 1
    implicitChannel2 :=make(chan int)// part 1
    go func() {implicitChannel1 <- sum()} // part 1
    go func() {implicitChannel2 <- sum()} // part 1
    x := <- implicitChannel1 // part 2
    y := F() // <== here
    z := <- implicitChannel2 // part 2
    close(implicitChannel1) // part 2
    close(implicitChannel2) // part 2
    Assignment is the same as in normal statements. Please ignore the implicit
    channel, when considering assignment.

    @Konstantin Shaposhnikov:
    Compiler could check the return value of the function, if it contains
    channel type, then do the normal flow. It seems not very complex.
    On Tuesday, May 17, 2016 at 10:37:27 PM UTC+8, Wang Yarco wrote:

    1. Where is `union`?
    golang uses `struct` as in c. But i noticed `union` is dropped. There is
    composition for interfaces and structs, but it does mean `one and another`
    not `one or another`.
    Then how to define `basic type` but not including those `map`, `array`,
    `slice` etc...
    Ex.:
    type basic bool|int|int32|int64|uint|float32|float64|string...
    those basic types?

    2. OO and PO?
    if they are the same thing, why not when creating:
    func Add(a, b int) int {
    return a + b
    }
    also generating the method (to make things simple):
    func (a int) Add (b int) int {
    return a + b
    }
    and vise versa.

    I mean when create a function `Add`, the compiler will automatically
    create a method for the type of the first argument (as an alias or
    something...)
    - of cause, there may be name conflicts, so i support func overload
    - anonymous func won't have this feature

    3. Runtime channel
    Why not the channel is running in runtime mode? I mean, if so, it seems
    there's no need `go` and `channel` keywords. Ex.:
    func test(ch chan int) {
    ch <- 1
    }

    func main() {
    ch := make(chan int)
    test(ch)
    i := <-ch
    fmt.Println(i)
    }

    It seems useless cause if i can:
    func test() int {
    return 1
    }

    func main() {
    i := <-test()
    // i := test()
    fmt.Println(i)
    }
    operator <- has already figure out `test()` is running in gorountine mode,
    and the return value will be sent in a channel, comparing to the 2nd
    statement.
    So, we don't have to change the `test` function. (the definition is same
    as in concurrency mode or normal, no need special parameter `chan`, it
    seems like an output parameter in my eyes...why not just return it?)


    (Maybe here, what i'm thinking is the features based on runtime...i'm not
    sure...)
    But i will feel more comfortable if golang has those features.
    --
    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/d/optout.
  • Konstantin Shaposhnikov at May 24, 2016 at 12:49 am
    Sorry, replied off list
    @Konstantin Shaposhnikov:
    Compiler could check the return value of the function, if it contains
    channel type, then do the normal flow. It seems not very complex.

    Yes, but this will make impossible to return a channel via an implicit
    channel (as in your proposal). A special case like that feels gross and
    makes the language harder to learn IMHO.

    Also I think that readability suffers when the same expression ( x :=
    <-f()) behaves differently depending on the return type of f().


    A few more questions to answer:
    - what if f() panics (especially in case of multiple assignments)
    - will functions with multiple return values be supported?

    --
    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/d/optout.
  • Wang Yarco at May 24, 2016 at 12:29 am
    And, for compatible, keyword `go` can be an alias as the grammer:
    go func(...)
    <==> the same as
    <-func(...)
    Except <- also check the return value, if not contains channel type, it
    will do implicit channel flow.
    On Tuesday, May 17, 2016 at 10:37:27 PM UTC+8, Wang Yarco wrote:

    1. Where is `union`?
    golang uses `struct` as in c. But i noticed `union` is dropped. There is
    composition for interfaces and structs, but it does mean `one and another`
    not `one or another`.
    Then how to define `basic type` but not including those `map`, `array`,
    `slice` etc...
    Ex.:
    type basic bool|int|int32|int64|uint|float32|float64|string...
    those basic types?

    2. OO and PO?
    if they are the same thing, why not when creating:
    func Add(a, b int) int {
    return a + b
    }
    also generating the method (to make things simple):
    func (a int) Add (b int) int {
    return a + b
    }
    and vise versa.

    I mean when create a function `Add`, the compiler will automatically
    create a method for the type of the first argument (as an alias or
    something...)
    - of cause, there may be name conflicts, so i support func overload
    - anonymous func won't have this feature

    3. Runtime channel
    Why not the channel is running in runtime mode? I mean, if so, it seems
    there's no need `go` and `channel` keywords. Ex.:
    func test(ch chan int) {
    ch <- 1
    }

    func main() {
    ch := make(chan int)
    test(ch)
    i := <-ch
    fmt.Println(i)
    }

    It seems useless cause if i can:
    func test() int {
    return 1
    }

    func main() {
    i := <-test()
    // i := test()
    fmt.Println(i)
    }
    operator <- has already figure out `test()` is running in gorountine mode,
    and the return value will be sent in a channel, comparing to the 2nd
    statement.
    So, we don't have to change the `test` function. (the definition is same
    as in concurrency mode or normal, no need special parameter `chan`, it
    seems like an output parameter in my eyes...why not just return it?)


    (Maybe here, what i'm thinking is the features based on runtime...i'm not
    sure...)
    But i will feel more comfortable if golang has those features.
    --
    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/d/optout.
  • Michael Jones at May 24, 2016 at 12:49 am
    This is an important issue. When the documentation would need to say “like this except when…” then the concept is not fully general; the cross-product of all combinations of ideas is not supported. The Go team worked carefully to avoid that kind of case. Adding “non-orthogonal” features is uncomfortable.


    Michael Jones, CEO • michael@wearality.com • +1 650 656-6989
    Wearality Corporation • 289 S. San Antonio Road • Los Altos, CA 94022
    On May 23, 2016, at 8:29 PM, Wang Yarco wrote:

    And, for compatible, keyword `go` can be an alias as the grammer:
    go func(...)
    <==> the same as
    <-func(...)
    Except <- also check the return value, if not contains channel type, it will do implicit channel flow.

    On Tuesday, May 17, 2016 at 10:37:27 PM UTC+8, Wang Yarco wrote:
    1. Where is `union`?
    golang uses `struct` as in c. But i noticed `union` is dropped. There is composition for interfaces and structs, but it does mean `one and another` not `one or another`.
    Then how to define `basic type` but not including those `map`, `array`, `slice` etc...
    Ex.:
    type basic bool|int|int32|int64|uint|float32|float64|string...
    those basic types?

    2. OO and PO?
    if they are the same thing, why not when creating:
    func Add(a, b int) int {
    return a + b
    }
    also generating the method (to make things simple):
    func (a int) Add (b int) int {
    return a + b
    }
    and vise versa.

    I mean when create a function `Add`, the compiler will automatically create a method for the type of the first argument (as an alias or something...)
    - of cause, there may be name conflicts, so i support func overload
    - anonymous func won't have this feature

    3. Runtime channel
    Why not the channel is running in runtime mode? I mean, if so, it seems there's no need `go` and `channel` keywords. Ex.:
    func test(ch chan int) {
    ch <- 1
    }

    func main() {
    ch := make(chan int)
    test(ch)
    i := <-ch
    fmt.Println(i)
    }

    It seems useless cause if i can:
    func test() int {
    return 1
    }

    func main() {
    i := <-test()
    // i := test()
    fmt.Println(i)
    }
    operator <- has already figure out `test()` is running in gorountine mode, and the return value will be sent in a channel, comparing to the 2nd statement.
    So, we don't have to change the `test` function. (the definition is same as in concurrency mode or normal, no need special parameter `chan`, it seems like an output parameter in my eyes...why not just return it?)


    (Maybe here, what i'm thinking is the features based on runtime...i'm not sure...)
    But i will feel more comfortable if golang has those features.

    --
    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/d/optout <https://groups.google.com/d/optout>.
    --
    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/d/optout.
  • Wang Yarco at May 24, 2016 at 1:11 am

    @Konstantin Shaposhnikov:
    Yes, but this will make impossible to return a channel via an implicit
    channel (as in your proposal). A special case like that feels gross and
    makes the language harder to learn IMHO.
    Please stand at human side. **The implicit channel is used because the
    named channel is not required**.
    Why when you use a named channel the same time you also want to pass it to
    a implicit channel?
    There's no such requirements. You can not stop people do stupic things. I
    think it is more simple than Michael said:

    go sum(s[:len(s)/2], c)
      x := <-c
    go sum(s[len(s)/2:], c)
    y := <-c

    This is actually something like a trap. Without deep considering, nobody
    noticed that!!!
    what if f() panics (especially in case of multiple assignments)
    That's the same as in normal statement.
    a, b,c :=E(),F(),G()
    I'm not quite sure your problem.
    - will functions with multiple return values be supported?
    That is the same thing as i said. If has channel type, do the normal flow;
    if not, it do implicit channel flow. So, of cause, it supports.

    @Michael Jones:
    This is an important issue. When the documentation would need to say
    “like this except when…” then the concept is not fully general; the
    cross-product of all combinations of ideas is not supported. The Go team
    worked carefully to avoid that kind of case. Adding “non-orthogonal”
    features is uncomfortable.

    The Go team also said they create golang is for dealing with real problem.
    So, you can only choose one: `deal with real problem` or `keeping the
    language in someway pure`...
    On Tuesday, May 17, 2016 at 10:37:27 PM UTC+8, Wang Yarco wrote:

    1. Where is `union`?
    golang uses `struct` as in c. But i noticed `union` is dropped. There is
    composition for interfaces and structs, but it does mean `one and another`
    not `one or another`.
    Then how to define `basic type` but not including those `map`, `array`,
    `slice` etc...
    Ex.:
    type basic bool|int|int32|int64|uint|float32|float64|string...
    those basic types?

    2. OO and PO?
    if they are the same thing, why not when creating:
    func Add(a, b int) int {
    return a + b
    }
    also generating the method (to make things simple):
    func (a int) Add (b int) int {
    return a + b
    }
    and vise versa.

    I mean when create a function `Add`, the compiler will automatically
    create a method for the type of the first argument (as an alias or
    something...)
    - of cause, there may be name conflicts, so i support func overload
    - anonymous func won't have this feature

    3. Runtime channel
    Why not the channel is running in runtime mode? I mean, if so, it seems
    there's no need `go` and `channel` keywords. Ex.:
    func test(ch chan int) {
    ch <- 1
    }

    func main() {
    ch := make(chan int)
    test(ch)
    i := <-ch
    fmt.Println(i)
    }

    It seems useless cause if i can:
    func test() int {
    return 1
    }

    func main() {
    i := <-test()
    // i := test()
    fmt.Println(i)
    }
    operator <- has already figure out `test()` is running in gorountine mode,
    and the return value will be sent in a channel, comparing to the 2nd
    statement.
    So, we don't have to change the `test` function. (the definition is same
    as in concurrency mode or normal, no need special parameter `chan`, it
    seems like an output parameter in my eyes...why not just return it?)


    (Maybe here, what i'm thinking is the features based on runtime...i'm not
    sure...)
    But i will feel more comfortable if golang has those features.
    --
    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/d/optout.
  • Konstantin Shaposhnikov at May 24, 2016 at 1:50 am

    On May 24, 2016 9:12 AM, "Wang Yarco" wrote:
    @Konstantin Shaposhnikov:
    Yes, but this will make impossible to return a channel via an implicit
    channel (as in your proposal). A special case like that feels gross and
    makes the language harder to learn IMHO.
    Please stand at human side. **The implicit channel is used because the
    named channel is not required**.
    Why when you use a named channel the same time you also want to pass it
    to a implicit channel?

    I believe I am on human side here ;) the less special cases I need to know
    about and the more readable the program the happier I am.
    There's no such requirements. You can not stop people do stupic things. I
    think it is more simple than Michael said:
    go sum(s[:len(s)/2], c)
    x := <-c
    go sum(s[len(s)/2:], c)
    y := <-c
    This is actually something like a trap. Without deep considering, nobody
    noticed that!!
    what if f() panics (especially in case of multiple assignments)
    That's the same as in normal statement.
    a, b,c :=E(),F(),G()
    I'm not quite sure your problem
    Possibly there are no problems, but a complete proposal must specify
    behavior in case of panic.

    In particular will the panic value from another gorountine be available for
    recover? What happens if two or more panics occur?

    There are also potential usability problems. The cause of the original
    panic is in another gorountine and it won't be printed unless you enable
    printing all stack traces on panic.
    - will functions with multiple return values be supported?
    That is the same thing as i said. If has channel type, do the normal
    flow; if not, it do implicit channel flow. So, of cause, it supports

    Can you please give an example? For example if I have two functions:

    func g() (int, error)

    and

    func f() (int, bool)

    Would I had to write:

    i, err, j, b := <-g(), <-f()?

    This is not legal with multiple assignment currently.

    Another issue with the proposal that it has very limited use. For example I
    won't be able to use the proposed syntax if I want to calculate sum of a
    slice using N gorountines. Dynamic cases like that are more common in real
    programs than simple static cases from my experience.
    @Michael Jones:
    This is an important issue. When the documentation would need to say
    “like this except when…” then the concept is not fully general; the
    cross-product of all combinations of ideas is not supported. The Go team
    worked carefully to avoid that kind of case. Adding “non-orthogonal”
    features is uncomfortable.
    The Go team also said they create golang is for dealing with real problem.
    So, you can only choose one: `deal with real problem` or `keeping the
    language in someway pure`...
    On Tuesday, May 17, 2016 at 10:37:27 PM UTC+8, Wang Yarco wrote:

    1. Where is `union`?
    golang uses `struct` as in c. But i noticed `union` is dropped. There is
    composition for interfaces and structs, but it does mean `one and another`
    not `one or another`.
    Then how to define `basic type` but not including those `map`, `array`,
    `slice` etc...
    Ex.:
    type basic bool|int|int32|int64|uint|float32|float64|string...
    those basic types?

    2. OO and PO?
    if they are the same thing, why not when creating:
    func Add(a, b int) int {
    return a + b
    }
    also generating the method (to make things simple):
    func (a int) Add (b int) int {
    return a + b
    }
    and vise versa.

    I mean when create a function `Add`, the compiler will automatically
    create a method for the type of the first argument (as an alias or
    something...)
    - of cause, there may be name conflicts, so i support func overload
    - anonymous func won't have this feature

    3. Runtime channel
    Why not the channel is running in runtime mode? I mean, if so, it seems
    there's no need `go` and `channel` keywords. Ex.:
    func test(ch chan int) {
    ch <- 1
    }

    func main() {
    ch := make(chan int)
    test(ch)
    i := <-ch
    fmt.Println(i)
    }

    It seems useless cause if i can:
    func test() int {
    return 1
    }

    func main() {
    i := <-test()
    // i := test()
    fmt.Println(i)
    }
    operator <- has already figure out `test()` is running in gorountine
    mode, and the return value will be sent in a channel, comparing to the 2nd
    statement.
    So, we don't have to change the `test` function. (the definition is same
    as in concurrency mode or normal, no need special parameter `chan`, it
    seems like an output parameter in my eyes...why not just return it?)

    (Maybe here, what i'm thinking is the features based on runtime...i'm
    not sure...)
    But i will feel more comfortable if golang has those features.
    --
    You received this message because you are subscribed to a topic in the
    Google Groups "golang-nuts" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/golang-nuts/GLpfWcaDb_k/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to
    golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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/d/optout.
  • Wang Yarco at May 24, 2016 at 2:10 am
    This is not legal with multiple assignment currently.
    Yes, that's the problem for now. I don't know why...

    i, err, j, b := <-g(), <-f()?
    I think so. If the grammar support multi-return values, so why the count
    should be equal?
    func t() (int,int) {
    return 1, 1
    }

    func main() {
    a, b, c, d := t(), t()
    fmt.Println(a,b,c,d)
    }

    # command-line-arguments

    ./test.go:12: multiple-value t() in single-value context

    ./test.go:12: assignment count mismatch: 4 = 2

    On Tuesday, May 24, 2016 at 9:50:44 AM UTC+8, Konstantin Shaposhnikov wrote:


    On May 24, 2016 9:12 AM, "Wang Yarco" <yarco...@gmail.com <javascript:>>
    wrote:
    @Konstantin Shaposhnikov:
    Yes, but this will make impossible to return a channel via an implicit
    channel (as in your proposal). A special case like that feels gross and
    makes the language harder to learn IMHO.
    Please stand at human side. **The implicit channel is used because the
    named channel is not required**.
    Why when you use a named channel the same time you also want to pass it
    to a implicit channel?

    I believe I am on human side here ;) the less special cases I need to know
    about and the more readable the program the happier I am.
    There's no such requirements. You can not stop people do stupic things.
    I think it is more simple than Michael said:
    go sum(s[:len(s)/2], c)
    x := <-c
    go sum(s[len(s)/2:], c)
    y := <-c
    This is actually something like a trap. Without deep considering, nobody
    noticed that!!
    what if f() panics (especially in case of multiple assignments)
    That's the same as in normal statement.
    a, b,c :=E(),F(),G()
    I'm not quite sure your problem
    Possibly there are no problems, but a complete proposal must specify
    behavior in case of panic.

    In particular will the panic value from another gorountine be available
    for recover? What happens if two or more panics occur?

    There are also potential usability problems. The cause of the original
    panic is in another gorountine and it won't be printed unless you enable
    printing all stack traces on panic.
    - will functions with multiple return values be supported?
    That is the same thing as i said. If has channel type, do the normal
    flow; if not, it do implicit channel flow. So, of cause, it supports

    Can you please give an example? For example if I have two functions:

    func g() (int, error)

    and

    func f() (int, bool)

    Would I had to write:

    i, err, j, b := <-g(), <-f()?

    This is not legal with multiple assignment currently.

    Another issue with the proposal that it has very limited use. For example
    I won't be able to use the proposed syntax if I want to calculate sum of a
    slice using N gorountines. Dynamic cases like that are more common in real
    programs than simple static cases from my experience.
    @Michael Jones:
    This is an important issue. When the documentation would need to say
    “like this except when…” then the concept is not fully general; the
    cross-product of all combinations of ideas is not supported. The Go team
    worked carefully to avoid that kind of case. Adding “non-orthogonal”
    features is uncomfortable.
    The Go team also said they create golang is for dealing with real problem.
    So, you can only choose one: `deal with real problem` or `keeping the
    language in someway pure`...
    On Tuesday, May 17, 2016 at 10:37:27 PM UTC+8, Wang Yarco wrote:

    1. Where is `union`?
    golang uses `struct` as in c. But i noticed `union` is dropped. There
    is composition for interfaces and structs, but it does mean `one and
    another` not `one or another`.
    Then how to define `basic type` but not including those `map`,
    `array`, `slice` etc...
    Ex.:
    type basic bool|int|int32|int64|uint|float32|float64|string...
    those basic types?

    2. OO and PO?
    if they are the same thing, why not when creating:
    func Add(a, b int) int {
    return a + b
    }
    also generating the method (to make things simple):
    func (a int) Add (b int) int {
    return a + b
    }
    and vise versa.

    I mean when create a function `Add`, the compiler will automatically
    create a method for the type of the first argument (as an alias or
    something...)
    - of cause, there may be name conflicts, so i support func overload
    - anonymous func won't have this feature

    3. Runtime channel
    Why not the channel is running in runtime mode? I mean, if so, it seems
    there's no need `go` and `channel` keywords. Ex.:
    func test(ch chan int) {
    ch <- 1
    }

    func main() {
    ch := make(chan int)
    test(ch)
    i := <-ch
    fmt.Println(i)
    }

    It seems useless cause if i can:
    func test() int {
    return 1
    }

    func main() {
    i := <-test()
    // i := test()
    fmt.Println(i)
    }
    operator <- has already figure out `test()` is running in gorountine
    mode, and the return value will be sent in a channel, comparing to the 2nd
    statement.
    So, we don't have to change the `test` function. (the definition is
    same as in concurrency mode or normal, no need special parameter `chan`, it
    seems like an output parameter in my eyes...why not just return it?)

    (Maybe here, what i'm thinking is the features based on runtime...i'm
    not sure...)
    But i will feel more comfortable if golang has those features.
    --
    You received this message because you are subscribed to a topic in the
    Google Groups "golang-nuts" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/golang-nuts/GLpfWcaDb_k/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to
    golang-nuts...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/d/optout.
    --
    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/d/optout.
  • Wang Yarco at May 24, 2016 at 1:37 am
    To make your (computer like) guys feel simple, let me explain what it
    really did.

    - it has nothing to do with old codes
    go still go, concurrency still concurrency, channel still channel

    - the only feature it added is:
    // a normal function
    func Foo() {
    }
    // can also be used in concurrent mode in this way
    <-Foo()
    // and the return value will be passed through an implicit channel


    On Tuesday, May 17, 2016 at 10:37:27 PM UTC+8, Wang Yarco wrote:

    1. Where is `union`?
    golang uses `struct` as in c. But i noticed `union` is dropped. There is
    composition for interfaces and structs, but it does mean `one and another`
    not `one or another`.
    Then how to define `basic type` but not including those `map`, `array`,
    `slice` etc...
    Ex.:
    type basic bool|int|int32|int64|uint|float32|float64|string...
    those basic types?

    2. OO and PO?
    if they are the same thing, why not when creating:
    func Add(a, b int) int {
    return a + b
    }
    also generating the method (to make things simple):
    func (a int) Add (b int) int {
    return a + b
    }
    and vise versa.

    I mean when create a function `Add`, the compiler will automatically
    create a method for the type of the first argument (as an alias or
    something...)
    - of cause, there may be name conflicts, so i support func overload
    - anonymous func won't have this feature

    3. Runtime channel
    Why not the channel is running in runtime mode? I mean, if so, it seems
    there's no need `go` and `channel` keywords. Ex.:
    func test(ch chan int) {
    ch <- 1
    }

    func main() {
    ch := make(chan int)
    test(ch)
    i := <-ch
    fmt.Println(i)
    }

    It seems useless cause if i can:
    func test() int {
    return 1
    }

    func main() {
    i := <-test()
    // i := test()
    fmt.Println(i)
    }
    operator <- has already figure out `test()` is running in gorountine mode,
    and the return value will be sent in a channel, comparing to the 2nd
    statement.
    So, we don't have to change the `test` function. (the definition is same
    as in concurrency mode or normal, no need special parameter `chan`, it
    seems like an output parameter in my eyes...why not just return it?)


    (Maybe here, what i'm thinking is the features based on runtime...i'm not
    sure...)
    But i will feel more comfortable if golang has those features.
    --
    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/d/optout.
  • Wang Yarco at May 24, 2016 at 1:41 am
    `Normal function` here means `no channel keyword in its arguments or return
    values`.
    On Tuesday, May 17, 2016 at 10:37:27 PM UTC+8, Wang Yarco wrote:

    1. Where is `union`?
    golang uses `struct` as in c. But i noticed `union` is dropped. There is
    composition for interfaces and structs, but it does mean `one and another`
    not `one or another`.
    Then how to define `basic type` but not including those `map`, `array`,
    `slice` etc...
    Ex.:
    type basic bool|int|int32|int64|uint|float32|float64|string...
    those basic types?

    2. OO and PO?
    if they are the same thing, why not when creating:
    func Add(a, b int) int {
    return a + b
    }
    also generating the method (to make things simple):
    func (a int) Add (b int) int {
    return a + b
    }
    and vise versa.

    I mean when create a function `Add`, the compiler will automatically
    create a method for the type of the first argument (as an alias or
    something...)
    - of cause, there may be name conflicts, so i support func overload
    - anonymous func won't have this feature

    3. Runtime channel
    Why not the channel is running in runtime mode? I mean, if so, it seems
    there's no need `go` and `channel` keywords. Ex.:
    func test(ch chan int) {
    ch <- 1
    }

    func main() {
    ch := make(chan int)
    test(ch)
    i := <-ch
    fmt.Println(i)
    }

    It seems useless cause if i can:
    func test() int {
    return 1
    }

    func main() {
    i := <-test()
    // i := test()
    fmt.Println(i)
    }
    operator <- has already figure out `test()` is running in gorountine mode,
    and the return value will be sent in a channel, comparing to the 2nd
    statement.
    So, we don't have to change the `test` function. (the definition is same
    as in concurrency mode or normal, no need special parameter `chan`, it
    seems like an output parameter in my eyes...why not just return it?)


    (Maybe here, what i'm thinking is the features based on runtime...i'm not
    sure...)
    But i will feel more comfortable if golang has those features.
    --
    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/d/optout.
  • Wang Yarco at May 24, 2016 at 1:47 am
    // a normal function
    Actually, the normal function is just `no channel keyword in its returning
    type`...
    But i'm not sure, cause `no channel in its arguments and returnning type`
    is more sensitive.
    On Tuesday, May 17, 2016 at 10:37:27 PM UTC+8, Wang Yarco wrote:

    1. Where is `union`?
    golang uses `struct` as in c. But i noticed `union` is dropped. There is
    composition for interfaces and structs, but it does mean `one and another`
    not `one or another`.
    Then how to define `basic type` but not including those `map`, `array`,
    `slice` etc...
    Ex.:
    type basic bool|int|int32|int64|uint|float32|float64|string...
    those basic types?

    2. OO and PO?
    if they are the same thing, why not when creating:
    func Add(a, b int) int {
    return a + b
    }
    also generating the method (to make things simple):
    func (a int) Add (b int) int {
    return a + b
    }
    and vise versa.

    I mean when create a function `Add`, the compiler will automatically
    create a method for the type of the first argument (as an alias or
    something...)
    - of cause, there may be name conflicts, so i support func overload
    - anonymous func won't have this feature

    3. Runtime channel
    Why not the channel is running in runtime mode? I mean, if so, it seems
    there's no need `go` and `channel` keywords. Ex.:
    func test(ch chan int) {
    ch <- 1
    }

    func main() {
    ch := make(chan int)
    test(ch)
    i := <-ch
    fmt.Println(i)
    }

    It seems useless cause if i can:
    func test() int {
    return 1
    }

    func main() {
    i := <-test()
    // i := test()
    fmt.Println(i)
    }
    operator <- has already figure out `test()` is running in gorountine mode,
    and the return value will be sent in a channel, comparing to the 2nd
    statement.
    So, we don't have to change the `test` function. (the definition is same
    as in concurrency mode or normal, no need special parameter `chan`, it
    seems like an output parameter in my eyes...why not just return it?)


    (Maybe here, what i'm thinking is the features based on runtime...i'm not
    sure...)
    But i will feel more comfortable if golang has those features.
    --
    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/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMay 17, '16 at 2:37p
activeMay 24, '16 at 2:10a
posts28
users7
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase