why define methods on values rather than pointers?

Looking through sample Go codes, some things are not consistent. Many codes define their methods on pointer types, like:

func (p *parser) parse () {...}

But some other code define methods on just the type, not pointer to it:

func (s scanner) scan () {...}

Is there good reason to do the latter? Can it really be more efficient to pass object by value instead by pointer?

One reason is "I can't change this object", but this is problem with large objects anyway (would you pass big struct by value just to mark that it can not be changed by method?)

Luckily, this is in the Go FAQ:

> Should I define methods on values or pointers?
>
func (s *MyStruct) pointerMethod() { } // method on pointer
func (s MyStruct) valueMethod() { } // method on value`
>
> For programmers unaccustomed to pointers, the distinction between
> these two examples can be confusing, but the situation is actually
> very simple. When defining a method on a type, the receiver (s in the
> above examples) behaves exactly as if it were an argument to the
> method. Whether to define the receiver as a value or as a pointer is
> the same question, then, as whether a function argument should be a
> value or a pointer. There are several considerations.
>
> First, and most important, does the method need to modify the
> receiver? If it does, the receiver must be a pointer. (Slices and maps
> act as references, so their story is a little more subtle, but for
> instance to change the length of a slice in a method the receiver must
> still be a pointer.) In the examples above, if pointerMethod modifies
> the fields of s, the caller will see those changes, but valueMethod is
> called with a copy of the caller's argument (that's the definition of
> passing a value), so changes it makes will be invisible to the caller.
>
> By the way, pointer receivers are identical to the situation in Java,
> although in Java the pointers are hidden under the covers; it's Go's
> value receivers that are unusual.
>
> Second is the consideration of efficiency. If the receiver is large, a
> big struct for instance, it will be much cheaper to use a pointer
> receiver.
>
> Next is consistency. If some of the methods of the type must have
> pointer receivers, the rest should too, so the method set is
> consistent regardless of how the type is used. See the section on
> method sets for details.
>
> For types such as basic types, slices, and small structs, a value
> receiver is very cheap so unless the semantics of the method requires
> a pointer, a value receiver is efficient and clear.

So yes, it is mainly used for semantics. Knowing that a method is side-effect free is a good thing to know when dealing with concurrency as this automatically means that no locking is required. Global variables and reference types aside, a value receiver is a strong hint that your method is side-effect free.

Method chaining is also a consideration. If you want to be able to write

one.Two().Three()

then either Two() needs to return a pointer, or Three() needs to have a value receiver, because the result of a method call isn't addressable. If Two returns a value, it's not possible to take its address in order to call a pointer-receiver method on it. However, if Three() has a value receiver, it will work whether Two() returns a pointer or not.