Discussion of the Go Programming Language ()

Scott Lawrence | 1 Aug 2012 01:02

Re: language spec. channel description problem

On Tue, 31 Jul 2012, simon.place@... wrote:

> being new to go, and using channels, i read the lang spec. (
> http://golang.org/ref/spec#Channel_types) and was confused by this;
>
> chan<- float64  // can only be used to send float64s
> <-chan int      // can only be used to receive ints
>
> and what appeared to be an illogical arrow semantic, after some checks i
> decided the arrows were right but the comments were wrong, so i reported it
> but was told it was right!!
>
> does anyone else think the sense of these is reversed?

No. They refer to the permitted actions on *this* end of the channel.

Think of it this way. If you have a "chan<-", you can only send values to the 
channel.

   channel <- value

If you have a "<-chan", you can only get values from the channel

   value = <-channel

The type symbols match up with the usage permitted by the type.

--

-- 
Scott Lawrence

(Continue reading)

headers

simon.place | 1 Aug 2012 01:41

Re: language spec. channel description problem

> does anyone else think the sense of these is reversed?

No. They refer to the permitted actions on *this* end of the channel.

chan<- float64 // can only be used to send float64

isn't that what i said, that the above means; this end (the chan<- object) can send???

what i think was intended was to say;

the program can send to this end (the chan<- object)

which would be, for example, like this;

chan<- float64 // can only be used to send float64 to

so by changing the subject from the channel itself to the user of the channel.

of course to be explicit is always preferred, so;

chan<- float64 // a channel to which you can only send float64

headers

Jesse McNelis | 1 Aug 2012 01:48

Re: language spec. channel description problem

On Wed, Aug 1, 2012 at 9:41 AM,  <simon.place@...> wrote:
> of course to be explicit is always preferred, so;
>
> chan<- float64  // a channel to which you can only send float64
>

You don't send things to a channel, you use channels to send things to
the receiver.

--

-- 
=====================
http://jessta.id.au

headers

John | 1 Aug 2012 02:01

How to document files belonging to a package

What is the Go idiom for documenting files belonging to a package.

Say I have a package(completely fictional), "sort", that is made up of files:

list.go

map.go

sort.go

The main documentation for godoc web digestion lives in sort.go . But I also want to have maintainer documentation on the purpose of list.go and map.go(since I divided the code up so neatly). I know if I put the comments below the package definition that it won't show up on the godoc web server, but is that go idiomatic? If not, what is idiomatic?

Thanks!

headers

kortschak | 1 Aug 2012 02:03

Re: Thoughts on channel semantics

That's currently illegal, so it's a non-issue it seems (though if something like the proposal were to be implemented the precedence would need to be determined). Having said that, it looks like an ugly construction. Not commenting on the rest of the thread.

Dan

On Wednesday, August 1, 2012 12:06:25 AM UTC+9:30, chl wrote:

and what would this do ?

c1 <- c2 <- "Hi"

Do we send a value from c2 to c1, or do we send a bool to c1 ?

headers

simon.place | 1 Aug 2012 02:15

Re: language spec. channel description problem

> of course to be explicit is always preferred, so;
>
> chan<- float64 // a channel to which you can only send float64
>

You don't send things to a channel, you use channels to send things to
the receiver

so what do you call the process of putting things into a channels buffer, if not sending to it?

headers

Kyle Lemons | 1 Aug 2012 02:20

Re: How to document files belonging to a package

Only the comments immediately before the package declaration are considered documentation for godoc:

// I am not displayed

// I am displayed

package example

On Tue, Jul 31, 2012 at 5:01 PM, John <johnsiilver-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

What is the Go idiom for documenting files belonging to a package.

Say I have a package(completely fictional), "sort", that is made up of files:

list.go

map.go

sort.go

The main documentation for godoc web digestion lives in sort.go . But I also want to have maintainer documentation on the purpose of list.go and map.go(since I divided the code up so neatly). I know if I put the comments below the package definition that it won't show up on the godoc web server, but is that go idiomatic? If not, what is idiomatic?

Thanks!

headers

kortschak | 1 Aug 2012 02:23

Re: language spec. channel description problem

Sending on it.

On Wednesday, August 1, 2012 9:45:04 AM UTC+9:30, simon...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org wrote:

> of course to be explicit is always preferred, so;
>
> chan<- float64 // a channel to which you can only send float64
>

You don't send things to a channel, you use channels to send things to
the receiver

so what do you call the process of putting things into a channels buffer, if not sending to it?

headers

Jan Mercl | 1 Aug 2012 02:32

Re: language spec. channel description problem

On Wed, Aug 1, 2012 at 2:15 AM, <simon.place-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:

> of course to be explicit is always preferred, so;
>
> chan<- float64 // a channel to which you can only send float64
>

You don't send things to a channel, you use channels to send things to
the receiver

so what do you call the process of putting things into a channels buffer, if not sending to it?

Sending puts transmitted values into a channel. Receiving (FIFO) gets received values from a channel. Channel is not a receiver nor a transmitter but a channel type may (optionally) be constrained to limit the available ops on it to be only put or get but not both.

-j

headers

simon.place | 1 Aug 2012 02:41

Re: language spec. channel description problem

before anyone starts forgetting;

this has nothing to do with what channel do, its about what English words you use to describe things.

seems to me what's developed is a consensus on this, that i didn't pick up from the documentation.

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31

1756	June 2013
3820	May 2013
2898	April 2013
2962	March 2013
3409	February 2013
3866	January 2013
2618	December 2012
2496	November 2012
3240	October 2012
3415	September 2012
2206	August 2012
2862	July 2012
2375	June 2012
2484	May 2012
3167	April 2012
3718	March 2012
2914	February 2012
1995	January 2012
1975	December 2011
2158	November 2011
2274	October 2011
1796	September 2011
1614	August 2011
1981	July 2011
2270	June 2011
2238	May 2011
1648	April 2011
1557	March 2011
1654	February 2011
1188	January 2011
1561	December 2010
1950	November 2010
1510	October 2010
1541	September 2010
1633	August 2010
1516	July 2010
1381	June 2010
1413	May 2010
1964	April 2010
1564	March 2010
1260	February 2010
1412	January 2010
2930	December 2009
3775	November 2009