[go-nuts] Suggest a new key word "in"

No. Sorry.

Ian

Nope, sorry this adds nothing to the language, it merely rearranges the form of the range syntax to be more familiar to some, and less familiar to anyone who's already invested in the exisiting syntax.

The existing syntax allows to either create new, loop scoped variables
(with :=) or reuse existing, outer scoped ones and that's an important
feature. The proposal seems to not consider it.

-j

Indeed. It would also seem the existing syntax composes better with other
functions being introduced later. It would be a shame to close down the
generalization since it would mean you would have to open the door for
Python-like special interface names.

I agree with Jan, and others in this thread. Clearly the Go authors knew
about the "in" keyword in other languages, and specifically chose not to
include it. Range does the job better, without (much) special syntax. While
I missed "in" at first, now range seems perfectly natural. One thing that
hasn't been mentioned is how range enables capturing key, value pairs using
the same multiple-return-value syntax used elsewhere in the language,
unlike other languages I will refrain from mentioning, which need
additional functions like keys(), values(), items(), iterkeys(), etc. to
enable the same functionality.

Why?

`:= range` (and its sibling `= range`) do the job. I don't see the change
as providing a benefit exceeding the pain of maintaining an extra syntax.

[Imagines all the questions "what's the difference in using `in` rather
than `:= range` and the baffled look when we say "there isn't one."]


Chris "allusive" Dollin

I've become a fan of sugar being an editor/IDE concern. Give yourself a
keystroke or snippet that expands in to := range.

I could think about the 'in' and 'out' keywords in Ada when used with
function arguments. That makes sense to me.

I'm not a fan of new symbols, I don't even like the symbols := and <- , but
that is just me. An example would be that channels could have been updated
with new methods that operated differently to fix the perceived flaws
without breaking go 1 guarantee. Instead of just being a builtin library,
channels are hard coded into the language, making certain issues impossible
to fix.

In order for channels to work reasonably, they must be built into the
language, so that the select statement can work with a reasonable
syntax.

Ian

If there was going to be a new keyword or other lexical change (yes, I
know, not likely) my favorite suggestions of the big debates a few years
ago were:

a. "become" which was Ken Thompson's generalized way of tail recursion.

b. Unicode right and left arrows ("→" and "←") as synonyms for "<-" and
"->". This is clean and can change no existing program's meaning. (Though
old Stanford Sail programmers may be confused that it means send/receive
rather than assignment.)

oops. no right arrow needed, though I think I remember pushing for tight
arrow for some reason. don't remember now.

Actually "become" as a keyword originates in Newsqueak.

-rob

Scheme doesn't give you a way to look at your call stack. Go has
runtime.Callers, and people use it for purposes other than debugging.
(I don't know about Newsqueak.)

Ian

Newsqueak flattened its stacks whenever a function returning T "became" a
call to another function returning T. Newsqueak no return keyword, so in
this sense it was equivalent to Scheme. State machines were pretty,
debugging was a little harder.

-rob

Ah. In that case it seems "become" would be only useful as a
low level performance hack.

Tail recursion probably has not much of a win for Go in any case.

"Must" is a strong word. It could have been done with just another special
function like make and append.

select(
   c1, func(i int) { println(i, "came from c1") },
   c2, func(s string) { println(s, "came from c2") },
   c3, func() bool { println("Sending true on c3"); return true},
)

The syntactic sugar of the current select statement is nice of course, but
the above syntax isn't so bad IMO. The function could be implemented today
using reflect.Select. Go can't typecheck it, but that would be easier to
add to the hypothetical language "Go minus channels" than first class
channels would be.

some of the authors of Go have spent considerable time dealing with "X
minus channels". for an example see the "Alt" construct from Plan 9's
libthread: http://plan9.bell-labs.com/magic/man2html/2/thread

limbo's "alt"[1] is comparatively much nicer and the step to select {}
is much smaller after that.

If you're trying to explain to me why the Go authors included first class
channels, I already know the history and I'm not at all suggesting the
language would be better without them. I was merely responding to the
statement by Ian Taylor that channels "must" be built in to the language in
order for select to have a reasonable syntax.

If you're suggesting that libthread's Alt struct is comparable to the
select function I presented, I definitely don't agree with that. However
it's hard to do better in C, unlike in [Go minus channels].

Anyway this discussion is a digression from the thread's topic.

I've done enough nodejs to know that replacing blocks with functions
is generally horrible.
You lose the ability to use 'break', 'continue', 'goto', 'return'. To
get values out of the functions you have to assign them to variables
from the outside scope and then use that state to figure out which
function got called so you know what do do with those values after the
select.

That's interesting but I don't find it convincing.

I'm sticking with "must."

Ian

From a practical point of view, "must" may be correct. From a theoretical
point of view, I don't think special syntax is necessary to make channels
usable. Go is a practical language. Therefore, I concede the point. :-)

From a theoretical point of view you could replace most of the
keywords and syntax in Go with just functions that take function
parameters....but then you'd have a lisp.

If you want more python like syntax in Go, then Gython is what you need. It
supports enumerate loops, and `for key,value in map` loops.
https://github.com/gython/Gython