FAQ
What is the rationale for the ++ and -- operators as syntactic sugar for
+=1 and -=1 respectively?

Does this not introduce unnecessary choices and make it difficult to
simplify statements such as:

a++
b++

--
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.

Search Discussions

•  at Feb 13, 2013 at 12:52 pm ⇧

On Wed, Feb 13, 2013 at 1:25 PM, Starfish wrote:
What is the rationale for the ++ and -- operators as syntactic sugar for +=1
and -=1 respectively?
I guess b/c `a++` is half the characters of `a += 1`
Does this not introduce unnecessary choices and make it difficult to
simplify statements such as:

a++
b++
Here you lost me. What simplification of `a++`, beyond the single CPU
instruction produced by many compilers, is to be expected?

-j

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
•  at Feb 13, 2013 at 1:01 pm ⇧
I guess b/c `a++` is half the characters of `a += 1`
Yes, but Go's philosophy is that it terseness isn't a goal--being clear is.
I don't see why this exists either, but I don't feel very strongly about it.

On Wed, Feb 13, 2013 at 1:52 PM, Jan Mercl wrote:
On Wed, Feb 13, 2013 at 1:25 PM, Starfish wrote:
What is the rationale for the ++ and -- operators as syntactic sugar for +=1
and -=1 respectively?
I guess b/c `a++` is half the characters of `a += 1`
Does this not introduce unnecessary choices and make it difficult to
simplify statements such as:

a++
b++
Here you lost me. What simplification of `a++`, beyond the single CPU
instruction produced by many compilers, is to be expected?

-j

--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an

--
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.
•  at Feb 13, 2013 at 1:04 pm ⇧

On Wed, Feb 13, 2013 at 2:01 PM, Patrick Mylund Nielsen wrote:
I guess b/c `a++` is half the characters of `a += 1`
Yes, but Go's philosophy is that it terseness isn't a goal--being clear is.
I don't see why this exists either, but I don't feel very strongly about it.
Well, I think `i++` or `x--` _clearly_ communicates its semantics.

-j

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
•  at Feb 13, 2013 at 1:06 pm ⇧
I disagree. That "++" mutates wouldn't be intuitive to anyone who doesn't
know a C-like language.

On Wed, Feb 13, 2013 at 2:04 PM, Jan Mercl wrote:

On Wed, Feb 13, 2013 at 2:01 PM, Patrick Mylund Nielsen
wrote:
I guess b/c `a++` is half the characters of `a += 1`
Yes, but Go's philosophy is that it terseness isn't a goal--being clear is.
I don't see why this exists either, but I don't feel very strongly about
it.

Well, I think `i++` or `x--` _clearly_ communicates its semantics.

-j
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
•  at Feb 13, 2013 at 1:37 pm ⇧

On Wed, Feb 13, 2013 at 2:06 PM, Patrick Mylund Nielsen wrote:
I disagree. That "++" mutates wouldn't be intuitive to anyone who doesn't
know a C-like language.
Why should non programmers read Go source code?

-j

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
•  at Feb 13, 2013 at 1:42 pm ⇧
Python doesn't have ++ or --, and somehow it manages to be a programming
language.

On Wed, Feb 13, 2013 at 2:37 PM, Jan Mercl wrote:

On Wed, Feb 13, 2013 at 2:06 PM, Patrick Mylund Nielsen
wrote:
I disagree. That "++" mutates wouldn't be intuitive to anyone who doesn't
know a C-like language.
Why should non programmers read Go source code?

-j
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
•  at Feb 13, 2013 at 1:46 pm ⇧

On 13 February 2013 13:37, Jan Mercl wrote:
On Wed, Feb 13, 2013 at 2:06 PM, Patrick Mylund Nielsen
wrote:
I disagree. That "++" mutates wouldn't be intuitive to anyone who doesn't
know a C-like language.
Why should non programmers read Go source code?
You don't have to be a non-programmer to not know a C-like
language: there are plenty of them out there, and sometimes
they are someone's first language.

Chris

Common Lisp, Scheme, Prolog, Standard ML, Pop11, Pascal,
Basic, Smalltalk ...

--
Chris "allusive" Dollin

--
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.
•  at Feb 13, 2013 at 2:04 pm ⇧

On Wed, Feb 13, 2013 at 2:46 PM, chris dollin wrote:
You don't have to be a non-programmer to not know a C-like
language: there are plenty of them out there, and sometimes
they are someone's first language.
Impossible, can't be true. Every _programmer_ must know C. Q.E.D.

-j

PS: Yeah, I deserve whatever comes next ;-)

--
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.
•  at Feb 13, 2013 at 1:38 pm ⇧

On Wed, Feb 13, 2013 at 11:06 AM, Patrick Mylund Nielsen wrote:
I disagree. That "++" mutates wouldn't be intuitive to anyone who doesn't
know a C-like language.
I could argue about the delta of intuitiveness of "+=" vs. "++" to
heat up that conversation, but really.. this is a done deal, and a
pretty insignificant one. Let's all go coding.

gustavo @ http://niemeyer.net

--
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.
•  at Feb 13, 2013 at 1:46 pm ⇧
Completely agree. I responded because these knee-jerk responses that all
the choices Go have made are perfect because <insert a fitting argument
that contradicts a basic tenent of the language> are annoying. Starfish
asked what the rationale was, not for the language to be changed.

So far the rationale seems to be that Ken likes ++. That's fine. Just don't
try to sell it as something different.

On Wed, Feb 13, 2013 at 2:38 PM, Gustavo Niemeyer wrote:

On Wed, Feb 13, 2013 at 11:06 AM, Patrick Mylund Nielsen
wrote:
I disagree. That "++" mutates wouldn't be intuitive to anyone who doesn't
know a C-like language.
I could argue about the delta of intuitiveness of "+=" vs. "++" to
heat up that conversation, but really.. this is a done deal, and a
pretty insignificant one. Let's all go coding.

gustavo @ http://niemeyer.net
--
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.
•  at Feb 13, 2013 at 6:08 pm ⇧
A great many languages have increment/decrement operators, many with c++ semantics (it's an expression, prefixed use allowed). Javascript it's one example of this, and since js has a monopoly on browser-based programming, anyone wanting programmatic access to that medium will eventually notice ”++” anyway. Go compilers will quickly and thoroughly teach the semantic difference.

Anyway, I've encountered many languages which don't have += style constructs, or c-style character escaping in strings, or even any concept of mutable variables. go was, not surprisingly, designed to not be particularly surprising to c programmers, and it's not possible to be unsurprising to everyone. C is arguably the dominant reference language for the ”imperative” programming paradigm, and it's semantics are (at least indirectly) well known to a great many programmers -- since go follows the same overarching paradigm, it's reasonable the language family's greatest common denominator is used as the conceptual base for its core imperative syntax.

--
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.
•  at Feb 13, 2013 at 7:39 pm ⇧
The axiomatic development of number systems, "natural numbers" and integers
in particular, depends on the idea of a successor for each number. This
means that many people will have a natural understanding of the concept.

Integral types in the C-family have n++ as the "become the successor"
function for n, and n-- as the "become the predecessor" for n. Pascal and
Ada have SUCC(n) for the successor and PRED(n) for the predecessor (which
is n+1 and n-1 respectively, but is more sophisticated in Ada and Pascal
when advancing through enumerant values.) When I see ++ I always read
"next" and likewise "previous" or "prior" for --. It made sense to me from
day one of C.

The operator_equal functions in C are more natural than the plain equal to
one who has studied, designed, or built computers, as well as one who
programs actual computers rather than the virtualized conception of
computers suggested by high-level languages.

If a, b, and c are in memory, is there a computer in use today that can
compute a=b+c where the operands come from memory and the result goes to
memory? Is there one that can compute b+c where the operands come from
memory and the result goes to a register? This is certainly not likely.
Instead, actual computers can do either of the following:

r2 = r0 + r1 // aka, r2 = r0 + r1
a = store r2

or

r0 = r0 + r1 // aka, r0 += r1
a = store r0

If you've dealt with this, and learned to do the second "+=" version
wherever possible to accomplish more with a limited supply of registers,
then the idea of "+=" in a high-level language a pleasing window into the
soul of the machine. In olden times, there was one register, the
accumulator, and all the operations were of the operator_equals variety. In
modern times, there are many registers, and fancy compilers do everything
they can to save registers in just this way.

It is also a practical aid to comprehension. Just this morning I wrote this:

func (p *Plan) ClearZero(length, sum, residue int) {
index := (length*(p.sum+1)+sum)*p.words + (residue >> 6) // residue/64
mask := uint64(1) << uint(residue&0x3f) // residue%64
p.zero[index] &^= mask // tuple known to
be zero
}

Personally, I like find it simpler as written than would be:

Because (a) it's telling me that the left hand side value is being updated
in place so I don't have to look closely to see that the two array indices
are the same, it's shouting to the compiler to use the same address for the
load and store. It's also the "half of the compiler's optimizations are in
the developer's source code" mindset that several on the Go team believe.
Imagine the ugly and expanded case:

p.zero[(length*(p.sum+1)+sum)*p.words + (residue >> 6)] =
p.zero[(length*(p.sum+1)+sum)*p.words
+ (residue >> 6)] &^ uint64(1) << uint(residue&0x3f)

There are many cases where a compiler gets this as input. It has to deduce
that the LHS index and the RHS indices are common expressions, that the
slices are the same, and so that the same address can be used for bounds
check, load, and store, that only one bounds check is needed, and so on.
Optimizing compilers do this, but imperfectly at times and slowly as well.
The "+=" style helps hugely here because all the things that need to be
understood are as clear for the compiler as they are for the programmer.

One of my favorite things about C, perhaps my favorite thing, is that it
embraces the true nature of computers. My least favorite thing about it is
the other side of this same truth--it embraces and exposes a tiny subset of
the true nature of computers (the "greatest hits" say) and leaves the rest
out. This makes programs less efficient than they could be and worst,
discourages CPU designers from extending computers in ways they otherwise
might.
On Wed, Feb 13, 2013 at 10:08 AM, Kevin Gillette wrote:
A great many languages have increment/decrement operators, many with c++
semantics (it's an expression, prefixed use allowed). Javascript it's one
example of this, and since js has a monopoly on browser-based programming,
”++” anyway. Go compilers will quickly and thoroughly teach the semantic
difference.
Anyway, I've encountered many languages which don't have += style
constructs, or c-style character escaping in strings, or even any concept
of mutable variables. go was, not surprisingly, designed to not be
particularly surprising to c programmers, and it's not possible to be
unsurprising to everyone. C is arguably the dominant reference language for
the ”imperative” programming paradigm, and it's semantics are (at least
indirectly) well known to a great many programmers -- since go follows the
same overarching paradigm, it's reasonable the language family's greatest
common denominator is used as the conceptual base for its core imperative
syntax.
--
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

--
650-335-5765

--
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.
•  at Feb 13, 2013 at 9:16 pm ⇧
Does the compiler optimise

x % 64

into

x & 63

?

(Then you wouldn't need the comments.)
On Wednesday, 13 February 2013 19:38:33 UTC, Michael Jones wrote:

The axiomatic development of number systems, "natural numbers" and
integers in particular, depends on the idea of a successor for each number.
This means that many people will have a natural understanding of the
concept.

Integral types in the C-family have n++ as the "become the successor"
function for n, and n-- as the "become the predecessor" for n. Pascal and
Ada have SUCC(n) for the successor and PRED(n) for the predecessor (which
is n+1 and n-1 respectively, but is more sophisticated in Ada and Pascal
when advancing through enumerant values.) When I see ++ I always read
"next" and likewise "previous" or "prior" for --. It made sense to me from
day one of C.

The operator_equal functions in C are more natural than the plain equal to
one who has studied, designed, or built computers, as well as one who
programs actual computers rather than the virtualized conception of
computers suggested by high-level languages.

If a, b, and c are in memory, is there a computer in use today that can
compute a=b+c where the operands come from memory and the result goes to
memory? Is there one that can compute b+c where the operands come from
memory and the result goes to a register? This is certainly not likely.
Instead, actual computers can do either of the following:

r2 = r0 + r1 // aka, r2 = r0 + r1
a = store r2

or

r0 = r0 + r1 // aka, r0 += r1
a = store r0

If you've dealt with this, and learned to do the second "+=" version
wherever possible to accomplish more with a limited supply of registers,
then the idea of "+=" in a high-level language a pleasing window into the
soul of the machine. In olden times, there was one register, the
accumulator, and all the operations were of the operator_equals variety. In
modern times, there are many registers, and fancy compilers do everything
they can to save registers in just this way.

It is also a practical aid to comprehension. Just this morning I wrote
this:

func (p *Plan) ClearZero(length, sum, residue int) {
index := (length*(p.sum+1)+sum)*p.words + (residue >> 6) // residue/64
mask := uint64(1) << uint(residue&0x3f) // residue%64
p.zero[index] &^= mask // tuple known
to be zero
}

Personally, I like find it simpler as written than would be:

Because (a) it's telling me that the left hand side value is being updated
in place so I don't have to look closely to see that the two array indices
are the same, it's shouting to the compiler to use the same address for the
load and store. It's also the "half of the compiler's optimizations are in
the developer's source code" mindset that several on the Go team believe.
Imagine the ugly and expanded case:

p.zero[(length*(p.sum+1)+sum)*p.words + (residue >> 6)] = p.zero[(length*(p.sum+1)+sum)*p.words
+ (residue >> 6)] &^ uint64(1) << uint(residue&0x3f)

There are many cases where a compiler gets this as input. It has to deduce
that the LHS index and the RHS indices are common expressions, that the
slices are the same, and so that the same address can be used for bounds
check, load, and store, that only one bounds check is needed, and so on.
Optimizing compilers do this, but imperfectly at times and slowly as well.
The "+=" style helps hugely here because all the things that need to be
understood are as clear for the compiler as they are for the programmer.

One of my favorite things about C, perhaps my favorite thing, is that it
embraces the true nature of computers. My least favorite thing about it is
the other side of this same truth--it embraces and exposes a tiny subset of
the true nature of computers (the "greatest hits" say) and leaves the rest
out. This makes programs less efficient than they could be and worst,
discourages CPU designers from extending computers in ways they otherwise
might.
On Wed, Feb 13, 2013 at 10:08 AM, Kevin Gillette wrote:
A great many languages have increment/decrement operators, many with c++
semantics (it's an expression, prefixed use allowed). Javascript it's one
example of this, and since js has a monopoly on browser-based programming,
”++” anyway. Go compilers will quickly and thoroughly teach the semantic
difference.
Anyway, I've encountered many languages which don't have += style
constructs, or c-style character escaping in strings, or even any concept
of mutable variables. go was, not surprisingly, designed to not be
particularly surprising to c programmers, and it's not possible to be
unsurprising to everyone. C is arguably the dominant reference language for
the ”imperative” programming paradigm, and it's semantics are (at least
indirectly) well known to a great many programmers -- since go follows the
same overarching paradigm, it's reasonable the language family's greatest
common denominator is used as the conceptual base for its core imperative
syntax.
--
Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send

--
--
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.
•  at Feb 13, 2013 at 9:23 pm ⇧
On checking the spec, no - since x is signed.
http://golang.org/ref/spec#Arithmetic_operators

If the dividend is positive and the divisor is a constant power of 2, the
division may be replaced by a right shift, and computing the remainder may
be replaced by a bitwise "and" operation:
On Wednesday, 13 February 2013 21:16:47 UTC, Peter wrote:

Does the compiler optimise

x % 64

into

x & 63

?

(Then you wouldn't need the comments.)
On Wednesday, 13 February 2013 19:38:33 UTC, Michael Jones wrote:

The axiomatic development of number systems, "natural numbers" and
integers in particular, depends on the idea of a successor for each number.
This means that many people will have a natural understanding of the
concept.

Integral types in the C-family have n++ as the "become the successor"
function for n, and n-- as the "become the predecessor" for n. Pascal and
Ada have SUCC(n) for the successor and PRED(n) for the predecessor (which
is n+1 and n-1 respectively, but is more sophisticated in Ada and Pascal
when advancing through enumerant values.) When I see ++ I always read
"next" and likewise "previous" or "prior" for --. It made sense to me from
day one of C.

The operator_equal functions in C are more natural than the plain equal
to one who has studied, designed, or built computers, as well as one who
programs actual computers rather than the virtualized conception of
computers suggested by high-level languages.

If a, b, and c are in memory, is there a computer in use today that can
compute a=b+c where the operands come from memory and the result goes to
memory? Is there one that can compute b+c where the operands come from
memory and the result goes to a register? This is certainly not likely.
Instead, actual computers can do either of the following:

r2 = r0 + r1 // aka, r2 = r0 + r1
a = store r2

or

r0 = r0 + r1 // aka, r0 += r1
a = store r0

If you've dealt with this, and learned to do the second "+=" version
wherever possible to accomplish more with a limited supply of registers,
then the idea of "+=" in a high-level language a pleasing window into the
soul of the machine. In olden times, there was one register, the
accumulator, and all the operations were of the operator_equals variety. In
modern times, there are many registers, and fancy compilers do everything
they can to save registers in just this way.

It is also a practical aid to comprehension. Just this morning I wrote
this:

func (p *Plan) ClearZero(length, sum, residue int) {
index := (length*(p.sum+1)+sum)*p.words + (residue >> 6) // residue/64
mask := uint64(1) << uint(residue&0x3f) // residue%64
p.zero[index] &^= mask // tuple known
to be zero
}

Personally, I like find it simpler as written than would be:

Because (a) it's telling me that the left hand side value is being
updated in place so I don't have to look closely to see that the two array
indices are the same, it's shouting to the compiler to use the same address
for the load and store. It's also the "half of the
compiler's optimizations are in the developer's source code" mindset that
several on the Go team believe. Imagine the ugly and expanded case:

p.zero[(length*(p.sum+1)+sum)*p.words + (residue >> 6)] = p.zero[(length*(p.sum+1)+sum)*p.words
+ (residue >> 6)] &^ uint64(1) << uint(residue&0x3f)

There are many cases where a compiler gets this as input. It has to
deduce that the LHS index and the RHS indices are common expressions, that
the slices are the same, and so that the same address can be used for
bounds check, load, and store, that only one bounds check is needed, and so
on. Optimizing compilers do this, but imperfectly at times and slowly as
well. The "+=" style helps hugely here because all the things that need to
be understood are as clear for the compiler as they are for the programmer.

One of my favorite things about C, perhaps my favorite thing, is that it
embraces the true nature of computers. My least favorite thing about it is
the other side of this same truth--it embraces and exposes a tiny subset of
the true nature of computers (the "greatest hits" say) and leaves the rest
out. This makes programs less efficient than they could be and worst,
discourages CPU designers from extending computers in ways they otherwise
might.

On Wed, Feb 13, 2013 at 10:08 AM, Kevin Gillette <extempor...@gmail.com>
wrote:
A great many languages have increment/decrement operators, many with
c++ semantics (it's an expression, prefixed use allowed). Javascript it's
one example of this, and since js has a monopoly on browser-based
eventually notice ”++” anyway. Go compilers will quickly and thoroughly
teach the semantic difference.
Anyway, I've encountered many languages which don't have += style
constructs, or c-style character escaping in strings, or even any concept
of mutable variables. go was, not surprisingly, designed to not be
particularly surprising to c programmers, and it's not possible to be
unsurprising to everyone. C is arguably the dominant reference language for
the ”imperative” programming paradigm, and it's semantics are (at least
indirectly) well known to a great many programmers -- since go follows the
same overarching paradigm, it's reasonable the language family's greatest
common denominator is used as the conceptual base for its core imperative
syntax.
--
Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send

--
650-335-5765
--
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.
•  at Feb 13, 2013 at 9:24 pm ⇧

On Wed, Feb 13, 2013 at 1:16 PM, Peter wrote:
Does the compiler optimise

x % 64

into

x & 63
I hope not, because that is incorrect if x is negative.

-rob

--
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.
•  at Feb 13, 2013 at 9:39 pm ⇧
No, for the reason Rob states. My values are all >0, so it works for me,
but doing all the casts is just too ugly and having the parameter be of
type uint64 pushes the cast-contamination issue to the callers...
On Wed, Feb 13, 2013 at 1:24 PM, Rob Pike wrote:
On Wed, Feb 13, 2013 at 1:16 PM, Peter wrote:
Does the compiler optimise

x % 64

into

x & 63
I hope not, because that is incorrect if x is negative.

-rob

--
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

--
650-335-5765

--
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.
•  at Feb 14, 2013 at 10:31 pm ⇧
Michael,

"If a, b, and c are in memory, is there a computer in use today that can
compute a=b+c where the operands come from memory and the result goes to
memory? . . . This is certainly not likely."

Yes. Using IBM mainframe Assembler machine language SS instructions,

ZAP a,b
AP a,c

IBM z/Architecture Reference Summary, Eighth Edition (September, 2012),
SA22-7871-07.

Peter
On Wednesday, February 13, 2013 2:38:33 PM UTC-5, Michael Jones wrote:

The axiomatic development of number systems, "natural numbers" and
integers in particular, depends on the idea of a successor for each number.
This means that many people will have a natural understanding of the
concept.

Integral types in the C-family have n++ as the "become the successor"
function for n, and n-- as the "become the predecessor" for n. Pascal and
Ada have SUCC(n) for the successor and PRED(n) for the predecessor (which
is n+1 and n-1 respectively, but is more sophisticated in Ada and Pascal
when advancing through enumerant values.) When I see ++ I always read
"next" and likewise "previous" or "prior" for --. It made sense to me from
day one of C.

The operator_equal functions in C are more natural than the plain equal to
one who has studied, designed, or built computers, as well as one who
programs actual computers rather than the virtualized conception of
computers suggested by high-level languages.

If a, b, and c are in memory, is there a computer in use today that can
compute a=b+c where the operands come from memory and the result goes to
memory? Is there one that can compute b+c where the operands come from
memory and the result goes to a register? This is certainly not likely.
Instead, actual computers can do either of the following:

r2 = r0 + r1 // aka, r2 = r0 + r1
a = store r2

or

r0 = r0 + r1 // aka, r0 += r1
a = store r0

If you've dealt with this, and learned to do the second "+=" version
wherever possible to accomplish more with a limited supply of registers,
then the idea of "+=" in a high-level language a pleasing window into the
soul of the machine. In olden times, there was one register, the
accumulator, and all the operations were of the operator_equals variety. In
modern times, there are many registers, and fancy compilers do everything
they can to save registers in just this way.

It is also a practical aid to comprehension. Just this morning I wrote
this:

func (p *Plan) ClearZero(length, sum, residue int) {
index := (length*(p.sum+1)+sum)*p.words + (residue >> 6) // residue/64
mask := uint64(1) << uint(residue&0x3f) // residue%64
p.zero[index] &^= mask // tuple known
to be zero
}

Personally, I like find it simpler as written than would be:

Because (a) it's telling me that the left hand side value is being updated
in place so I don't have to look closely to see that the two array indices
are the same, it's shouting to the compiler to use the same address for the
load and store. It's also the "half of the compiler's optimizations are in
the developer's source code" mindset that several on the Go team believe.
Imagine the ugly and expanded case:

p.zero[(length*(p.sum+1)+sum)*p.words + (residue >> 6)] = p.zero[(length*(p.sum+1)+sum)*p.words
+ (residue >> 6)] &^ uint64(1) << uint(residue&0x3f)

There are many cases where a compiler gets this as input. It has to deduce
that the LHS index and the RHS indices are common expressions, that the
slices are the same, and so that the same address can be used for bounds
check, load, and store, that only one bounds check is needed, and so on.
Optimizing compilers do this, but imperfectly at times and slowly as well.
The "+=" style helps hugely here because all the things that need to be
understood are as clear for the compiler as they are for the programmer.

One of my favorite things about C, perhaps my favorite thing, is that it
embraces the true nature of computers. My least favorite thing about it is
the other side of this same truth--it embraces and exposes a tiny subset of
the true nature of computers (the "greatest hits" say) and leaves the rest
out. This makes programs less efficient than they could be and worst,
discourages CPU designers from extending computers in ways they otherwise
might.
On Wed, Feb 13, 2013 at 10:08 AM, Kevin Gillette wrote:
A great many languages have increment/decrement operators, many with c++
semantics (it's an expression, prefixed use allowed). Javascript it's one
example of this, and since js has a monopoly on browser-based programming,
”++” anyway. Go compilers will quickly and thoroughly teach the semantic
difference.
Anyway, I've encountered many languages which don't have += style
constructs, or c-style character escaping in strings, or even any concept
of mutable variables. go was, not surprisingly, designed to not be
particularly surprising to c programmers, and it's not possible to be
unsurprising to everyone. C is arguably the dominant reference language for
the ”imperative” programming paradigm, and it's semantics are (at least
indirectly) well known to a great many programmers -- since go follows the
same overarching paradigm, it's reasonable the language family's greatest
common denominator is used as the conceptual base for its core imperative
syntax.
--
Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send

--
--
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.
•  at Feb 14, 2013 at 10:37 pm ⇧
Ha! I knew there would a counter example. Thanks! The DEC VAX could too...
and arguably the TI CPUs.
On Feb 14, 2013 2:31 PM, "peterGo" wrote:

Michael,

"If a, b, and c are in memory, is there a computer in use today that can
compute a=b+c where the operands come from memory and the result goes to
memory? . . . This is certainly not likely."

Yes. Using IBM mainframe Assembler machine language SS instructions,

ZAP a,b
AP a,c

IBM z/Architecture Reference Summary, Eighth Edition (September, 2012),
SA22-7871-07.

Peter
On Wednesday, February 13, 2013 2:38:33 PM UTC-5, Michael Jones wrote:

The axiomatic development of number systems, "natural numbers" and
integers in particular, depends on the idea of a successor for each number.
This means that many people will have a natural understanding of the
concept.

Integral types in the C-family have n++ as the "become the successor"
function for n, and n-- as the "become the predecessor" for n. Pascal and
Ada have SUCC(n) for the successor and PRED(n) for the predecessor (which
is n+1 and n-1 respectively, but is more sophisticated in Ada and Pascal
when advancing through enumerant values.) When I see ++ I always read
"next" and likewise "previous" or "prior" for --. It made sense to me from
day one of C.

The operator_equal functions in C are more natural than the plain equal
to one who has studied, designed, or built computers, as well as one who
programs actual computers rather than the virtualized conception of
computers suggested by high-level languages.

If a, b, and c are in memory, is there a computer in use today that can
compute a=b+c where the operands come from memory and the result goes to
memory? Is there one that can compute b+c where the operands come from
memory and the result goes to a register? This is certainly not likely.
Instead, actual computers can do either of the following:

r2 = r0 + r1 // aka, r2 = r0 + r1
a = store r2

or

r0 = r0 + r1 // aka, r0 += r1
a = store r0

If you've dealt with this, and learned to do the second "+=" version
wherever possible to accomplish more with a limited supply of registers,
then the idea of "+=" in a high-level language a pleasing window into the
soul of the machine. In olden times, there was one register, the
accumulator, and all the operations were of the operator_equals variety. In
modern times, there are many registers, and fancy compilers do everything
they can to save registers in just this way.

It is also a practical aid to comprehension. Just this morning I wrote
this:

func (p *Plan) ClearZero(length, sum, residue int) {
index := (length*(p.sum+1)+sum)*p.words + (residue >> 6) // residue/64
mask := uint64(1) << uint(residue&0x3f) // residue%64
p.zero[index] &^= mask // tuple known
to be zero
}

Personally, I like find it simpler as written than would be:

Because (a) it's telling me that the left hand side value is being
updated in place so I don't have to look closely to see that the two array
indices are the same, it's shouting to the compiler to use the same address
for the load and store. It's also the "half of the
compiler's optimizations are in the developer's source code" mindset that
several on the Go team believe. Imagine the ugly and expanded case:

p.zero[(length*(p.sum+1)+sum)***p.words + (residue >> 6)] = p.zero[
(length*(p.sum+1)+**sum)*p.words + (residue >> 6)] &^ uint64(1) <<
uint(residue&0x3f)

There are many cases where a compiler gets this as input. It has to
deduce that the LHS index and the RHS indices are common expressions, that
the slices are the same, and so that the same address can be used for
bounds check, load, and store, that only one bounds check is needed, and so
on. Optimizing compilers do this, but imperfectly at times and slowly as
well. The "+=" style helps hugely here because all the things that need to
be understood are as clear for the compiler as they are for the programmer.

One of my favorite things about C, perhaps my favorite thing, is that it
embraces the true nature of computers. My least favorite thing about it is
the other side of this same truth--it embraces and exposes a tiny subset of
the true nature of computers (the "greatest hits" say) and leaves the rest
out. This makes programs less efficient than they could be and worst,
discourages CPU designers from extending computers in ways they otherwise
might.

On Wed, Feb 13, 2013 at 10:08 AM, Kevin Gillette <extempor...@gmail.com>
wrote:
A great many languages have increment/decrement operators, many with
c++ semantics (it's an expression, prefixed use allowed). Javascript it's
one example of this, and since js has a monopoly on browser-based
eventually notice ”++” anyway. Go compilers will quickly and thoroughly
teach the semantic difference.
Anyway, I've encountered many languages which don't have += style
constructs, or c-style character escaping in strings, or even any concept
of mutable variables. go was, not surprisingly, designed to not be
particularly surprising to c programmers, and it's not possible to be
unsurprising to everyone. C is arguably the dominant reference language for
the ”imperative” programming paradigm, and it's semantics are (at least
indirectly) well known to a great many programmers -- since go follows the
same overarching paradigm, it's reasonable the language family's greatest
common denominator is used as the conceptual base for its core imperative
syntax.
--
Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send
.

--
650-335-5765
--
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

--
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.
•  at Feb 13, 2013 at 8:02 pm ⇧
If you don't think ++ mutates, what would you think it did?

On Wed, Feb 13, 2013 at 5:06 AM, Patrick Mylund Nielsen wrote:

I disagree. That "++" mutates wouldn't be intuitive to anyone who doesn't
know a C-like language.

On Wed, Feb 13, 2013 at 2:04 PM, Jan Mercl wrote:

On Wed, Feb 13, 2013 at 2:01 PM, Patrick Mylund Nielsen
wrote:
I guess b/c `a++` is half the characters of `a += 1`
Yes, but Go's philosophy is that it terseness isn't a goal--being clear is.
I don't see why this exists either, but I don't feel very strongly

Well, I think `i++` or `x--` _clearly_ communicates its semantics.

-j
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an

--
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.
•  at Feb 13, 2013 at 8:25 pm ⇧
n++ and n-- could just as well have been analogous to succ(n) and pred(n),
i.e.

n := 3
on := n++
# n is 3
# on is 4

With n += 1, this is much clearer (and yes, n = n + 1 would be more
straightforward still.)

On Wed, Feb 13, 2013 at 9:02 PM, Thomas Bushnell, BSG
wrote:
If you don't think ++ mutates, what would you think it did?

On Wed, Feb 13, 2013 at 5:06 AM, Patrick Mylund Nielsen <
patrick@patrickmylund.com> wrote:
I disagree. That "++" mutates wouldn't be intuitive to anyone who doesn't
know a C-like language.

On Wed, Feb 13, 2013 at 2:04 PM, Jan Mercl wrote:

On Wed, Feb 13, 2013 at 2:01 PM, Patrick Mylund Nielsen
wrote:
I guess b/c `a++` is half the characters of `a += 1`
Yes, but Go's philosophy is that it terseness isn't a goal--being clear is.
I don't see why this exists either, but I don't feel very strongly

Well, I think `i++` or `x--` _clearly_ communicates its semantics.

-j
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an

--
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.
•  at Feb 13, 2013 at 8:29 pm ⇧
Yes, but that isn't syntactically correct Go code.

Since "n++" is a statement, not an expression, I'm not sure what real
confusion happens.

On Wed, Feb 13, 2013 at 12:25 PM, Patrick Mylund Nielsen wrote:

n++ and n-- could just as well have been analogous to succ(n) and pred(n),
i.e.

n := 3
on := n++
# n is 3
# on is 4

With n += 1, this is much clearer (and yes, n = n + 1 would be more
straightforward still.)

On Wed, Feb 13, 2013 at 9:02 PM, Thomas Bushnell, BSG <
If you don't think ++ mutates, what would you think it did?

On Wed, Feb 13, 2013 at 5:06 AM, Patrick Mylund Nielsen <
patrick@patrickmylund.com> wrote:
I disagree. That "++" mutates wouldn't be intuitive to anyone who
doesn't know a C-like language.

On Wed, Feb 13, 2013 at 2:04 PM, Jan Mercl wrote:

On Wed, Feb 13, 2013 at 2:01 PM, Patrick Mylund Nielsen
wrote:
I guess b/c `a++` is half the characters of `a += 1`
Yes, but Go's philosophy is that it terseness isn't a goal--being clear is.
I don't see why this exists either, but I don't feel very strongly

Well, I think `i++` or `x--` _clearly_ communicates its semantics.

-j
--
Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send

--
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.
•  at Feb 13, 2013 at 8:42 pm ⇧
Alright, I'm going to give up now, but I leave you with this:

n is a value, not a reference. Why does "n++" mutate n if it doesn't
re-assign, especially when you need to do s = append(s, x) to grow a slice,
and a[i] = x rather than v = x to change a value in an array?

n += 1 / n = n + 1 are both clearer than n++. n++ makes sense because you
know what it does from C, not because anything else in Go has conditioned
you to find it intuitive. With less and less people actually starting out
learning C, and more and more educational institutions using Go as an
introductory language, you can't really say "++ is obvious, duh."

On Wed, Feb 13, 2013 at 9:29 PM, Thomas Bushnell, BSG
wrote:
Yes, but that isn't syntactically correct Go code.

Since "n++" is a statement, not an expression, I'm not sure what real
confusion happens.

On Wed, Feb 13, 2013 at 12:25 PM, Patrick Mylund Nielsen <
patrick@patrickmylund.com> wrote:
n++ and n-- could just as well have been analogous to succ(n) and
pred(n), i.e.

n := 3
on := n++
# n is 3
# on is 4

With n += 1, this is much clearer (and yes, n = n + 1 would be more
straightforward still.)

On Wed, Feb 13, 2013 at 9:02 PM, Thomas Bushnell, BSG <
If you don't think ++ mutates, what would you think it did?

On Wed, Feb 13, 2013 at 5:06 AM, Patrick Mylund Nielsen <
patrick@patrickmylund.com> wrote:
I disagree. That "++" mutates wouldn't be intuitive to anyone who
doesn't know a C-like language.

On Wed, Feb 13, 2013 at 2:04 PM, Jan Mercl wrote:

On Wed, Feb 13, 2013 at 2:01 PM, Patrick Mylund Nielsen
wrote:
I guess b/c `a++` is half the characters of `a += 1`
Yes, but Go's philosophy is that it terseness isn't a goal--being clear is.
I don't see why this exists either, but I don't feel very strongly

Well, I think `i++` or `x--` _clearly_ communicates its semantics.

-j
--
Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send

--
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.
•  at Feb 13, 2013 at 8:44 pm ⇧
I agree completely that someone without C-like experience might be
surprised that "i++" is mutating. However, what I'm saying is that there
isn't any *other *plausible interpretation it could have either. So someone
without C-like experience would go "hrm, I wonder what that does", which
isn't so bad. They would not go "ah, this does X" when it actually does
something else.

I'm not saying it's obvious or intuitive. I'm saying that someone without C
experience would not be able to form any conclusion about it.

This is true precisely because it can only occur as a statement. If it
could be used as an expression, then certainly it could cause confusion.

On Wed, Feb 13, 2013 at 12:42 PM, Patrick Mylund Nielsen wrote:

Alright, I'm going to give up now, but I leave you with this:

n is a value, not a reference. Why does "n++" mutate n if it doesn't
re-assign, especially when you need to do s = append(s, x) to grow a slice,
and a[i] = x rather than v = x to change a value in an array?

n += 1 / n = n + 1 are both clearer than n++. n++ makes sense because you
know what it does from C, not because anything else in Go has conditioned
you to find it intuitive. With less and less people actually starting out
learning C, and more and more educational institutions using Go as an
introductory language, you can't really say "++ is obvious, duh."

On Wed, Feb 13, 2013 at 9:29 PM, Thomas Bushnell, BSG <
Yes, but that isn't syntactically correct Go code.

Since "n++" is a statement, not an expression, I'm not sure what real
confusion happens.

On Wed, Feb 13, 2013 at 12:25 PM, Patrick Mylund Nielsen <
patrick@patrickmylund.com> wrote:
n++ and n-- could just as well have been analogous to succ(n) and
pred(n), i.e.

n := 3
on := n++
# n is 3
# on is 4

With n += 1, this is much clearer (and yes, n = n + 1 would be more
straightforward still.)

On Wed, Feb 13, 2013 at 9:02 PM, Thomas Bushnell, BSG <
If you don't think ++ mutates, what would you think it did?

On Wed, Feb 13, 2013 at 5:06 AM, Patrick Mylund Nielsen <
patrick@patrickmylund.com> wrote:
I disagree. That "++" mutates wouldn't be intuitive to anyone who
doesn't know a C-like language.

On Wed, Feb 13, 2013 at 2:04 PM, Jan Mercl wrote:

On Wed, Feb 13, 2013 at 2:01 PM, Patrick Mylund Nielsen
wrote:
I guess b/c `a++` is half the characters of `a += 1`
Yes, but Go's philosophy is that it terseness isn't a goal--being clear is.
I don't see why this exists either, but I don't feel very strongly

Well, I think `i++` or `x--` _clearly_ communicates its semantics.

-j
--
Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send

--
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.
•  at Feb 13, 2013 at 8:48 pm ⇧
Yeah, granted. I'm glad that you can't abuse it in Go.

On Wed, Feb 13, 2013 at 9:44 PM, Thomas Bushnell, BSG
wrote:
I agree completely that someone without C-like experience might be
surprised that "i++" is mutating. However, what I'm saying is that there
isn't any *other *plausible interpretation it could have either. So
someone without C-like experience would go "hrm, I wonder what that does",
which isn't so bad. They would not go "ah, this does X" when it actually
does something else.

I'm not saying it's obvious or intuitive. I'm saying that someone without
C experience would not be able to form any conclusion about it.

This is true precisely because it can only occur as a statement. If it
could be used as an expression, then certainly it could cause confusion.

On Wed, Feb 13, 2013 at 12:42 PM, Patrick Mylund Nielsen <
patrick@patrickmylund.com> wrote:
Alright, I'm going to give up now, but I leave you with this:

n is a value, not a reference. Why does "n++" mutate n if it doesn't
re-assign, especially when you need to do s = append(s, x) to grow a slice,
and a[i] = x rather than v = x to change a value in an array?

n += 1 / n = n + 1 are both clearer than n++. n++ makes sense because you
know what it does from C, not because anything else in Go has conditioned
you to find it intuitive. With less and less people actually starting out
learning C, and more and more educational institutions using Go as an
introductory language, you can't really say "++ is obvious, duh."

On Wed, Feb 13, 2013 at 9:29 PM, Thomas Bushnell, BSG <
Yes, but that isn't syntactically correct Go code.

Since "n++" is a statement, not an expression, I'm not sure what real
confusion happens.

On Wed, Feb 13, 2013 at 12:25 PM, Patrick Mylund Nielsen <
patrick@patrickmylund.com> wrote:
n++ and n-- could just as well have been analogous to succ(n) and
pred(n), i.e.

n := 3
on := n++
# n is 3
# on is 4

With n += 1, this is much clearer (and yes, n = n + 1 would be more
straightforward still.)

On Wed, Feb 13, 2013 at 9:02 PM, Thomas Bushnell, BSG <
If you don't think ++ mutates, what would you think it did?

On Wed, Feb 13, 2013 at 5:06 AM, Patrick Mylund Nielsen <
patrick@patrickmylund.com> wrote:
I disagree. That "++" mutates wouldn't be intuitive to anyone who
doesn't know a C-like language.

On Wed, Feb 13, 2013 at 2:04 PM, Jan Mercl wrote:

On Wed, Feb 13, 2013 at 2:01 PM, Patrick Mylund Nielsen
wrote:
I guess b/c `a++` is half the characters of `a += 1`
Yes, but Go's philosophy is that it terseness isn't a goal--being clear is.
I don't see why this exists either, but I don't feel very strongly

Well, I think `i++` or `x--` _clearly_ communicates its semantics.

-j
--
Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it,

--
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.
•  at Feb 13, 2013 at 3:12 pm ⇧

Does this not introduce unnecessary choices and make it difficult to
simplify statements such as:

a++
b++
Here you lost me. What simplification of `a++`, beyond the single CPU
instruction produced by many compilers, is to be expected?

-j
Yes, you're right. I was thinking it could be written 'a, b += 1, 1', but
it can't of course.

--
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.
•  at Feb 13, 2013 at 12:59 pm ⇧
ken likes ++.

--
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.
•  at Feb 13, 2013 at 1:26 pm ⇧
With it only being allowed as statements I don't see a real problem. I'll
continue to use += 1 because I think it's more clear overall and easier to
change to a different value if needed.

a++ as an expression and especially ++a as an expression tends to be
confusing at times and I'm glad they removed that. Sometimes you would have
to run something just to make sure what you think would happen actually
happens.

--
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.
•  at Feb 13, 2013 at 4:42 pm ⇧

Am Mittwoch, 13. Februar 2013 14:26:35 UTC+1 schrieb Robotic Artichoke:
With it only being allowed as statements I don't see a real problem. I'll
continue to use += 1 because I think it's more clear overall and easier to
change to a different value if needed.
But it comes with some surprises: a *= 2 + 2 means a = a * (2 + 2)

a++ as an expression and especially ++a as an expression tends to be
confusing at times and I'm glad they removed that. Sometimes you would have
to run something just to make sure what you think would happen actually
happens.
--
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.
•  at Feb 13, 2013 at 5:10 pm ⇧

On Thu, Feb 14, 2013 at 12:42 AM, Johann Höchtl wrote:
Am Mittwoch, 13. Februar 2013 14:26:35 UTC+1 schrieb Robotic Artichoke:
With it only being allowed as statements I don't see a real problem. I'll
continue to use += 1 because I think it's more clear overall and easier to
change to a different value if needed.
But it comes with some surprises: a *= 2 + 2 means a = a * (2 + 2)
the rhs is treated as a group here (*= here is part of the assignment
statement,
see http://golang.org/ref/spec#Assignments)
besides, i think making it expand to a = a * 2 + 2 will confuse a lot more.

--
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.

Related Discussions

Discussion Overview
 group golang-nuts categories go posted Feb 13, '13 at 12:25p active Feb 14, '13 at 10:37p posts 30 users 15 website golang.org

15 users in discussion

Content

People

Support

Translate

site design / logo © 2022 Grokbase