Most irritating feature of Go syntax
teales
For me it is the following:
Import declaration Local name of Sin
import "lib/math" math.Sin
import M "lib/math" M.Sin
import . "lib/math" Sin
I have to type the annoying dot in front of each package name in order
to refer to an imported item without qualification. From my very
limited experience, you can mostly get away with this without
ambiguity, and if you find that something is ambiguous, it would be
simple to zoom up to the top of the file and correct it if the rule
was:
import . "lib/math" math.Sin
import M "lib/math" M.Sin
import "lib/math" Sin
I also have some difficulty leaving out the semicolons and the
parentheses around ifs and so on. And if I get used to it, then I'm
going to start making stupid mistakes in D.
Peter Bourgon
> to refer to an imported item without qualification.
I'd suggest getting used to using fully qualified names. Explicit is
better than implicit.
teales
just take the dot away. What you're suggesting goes against the Go
language motivations - less to type.
Jessta
> I have to type the annoying dot in front of each package name in order
> to refer to an imported item without qualification.
If having to type the dot is that annoying then you are definitely
importing too many packages in to your package's namespace.
"Namespaces are one honking great idea", and it's really f**king
annoying trying to find out which package a function is from without
them.
Remember, any code you write is going to be read many more times then
it is written, any time you can save the reader is good.
The amount of time spent typing is a small fraction of the time spent
programming and conciseness in go isn't about the writing, it's more
about the reading.
> I also have some difficulty leaving out the semicolons and the
> parentheses around ifs and so on. And if I get used to it, then I'm
> going to start making stupid mistakes in D.
>
You can put the semicolons in if you want to, and gofmt will take them out.
The lack of parentheses around if conditions still trips me up too,
but it's much cleaner to read.
- jessta
--
=====================
http://jessta.id.au
Ostsol
part of the type or function name being imported. Look at the 'heap'
package, for example. The name 'heap.Interface' clearly implies that
'Interface' is the interface that defines a heap. Without the
qualifier you have an ambiguous name from a readability standpoint.
Granted one could argue in favour of taking a C-like approach and
prefix such names with the package name, but to me that seems
redundant when there already exists a mechanism for removing ambiguity
in the form of requiring explicit qualifiers as the default behaviour.
-Ostsol
teales
> You can put the semicolons in if you want to, and gofmt will take them out.
> The lack of parentheses around if conditions still trips me up too,
> but it's much cleaner to read.
>
OK, so we've discussed my irrational prejudices. The question I was
asking is what is yours - a bit of light relief after a long day.
Vincent Foley
if (...) {
} else {
}
instead of my preferred
if (...) {
}
else {
}
Rob 'Commander' Pike
foo.New
the function must be called something like
foo.NewFoo
to avoid colliding with New from other packages. And then what if Foo is itself a common name such as Buffer? You rapidly end up in the Java space of very long names for everything.
This convention we have, using the package names always, is deliberate. Yes, sometimes it makes for more typing but we believe in the long run it means less typing.
-rob
Brian Slesinsky
On Jan 23, 8:43 am, teales <steve.te...@britseyeview.com> wrote:
> I also have some difficulty leaving out the semicolons and the
> parentheses around ifs and so on. And if I get used to it, then I'm
> going to start making stupid mistakes in D.
A nice transition for programmers coming from a C-style language might
be if parens were optional around around the condition in an if
statement, but gofmt takes them out. (This assumes the habit of
running all code through gofmt catches on.)
- Brian
Kris.Z
declarations be made optional?
Rob 'Commander' Pike
On 24/01/2010, at 11:55 AM, Kris.Z wrote:
> Since package names are used in qualified identifiers could import
> declarations be made optional?
Technically yes, but that would make it less obvious what the dependencies are and one of the important elements of Go is clear dependency declarations.
-rob
Russ Cox
> Since package names are used in qualified identifiers could import
> declarations be made optional?
No. Does vector refer to container/vector or my/local/vector?
Russ
Kris.Z
K.
Ryanne Dolan
Nigel Tao
> In some languages, a set of standard packages are imported by default. What
> if Go silently imported packages from the standard library, but required
> import otherwise? Maybe just a subset of the library: fmt and math at least
> are in nearly all of my files.
fmt and math are in nearly none of my go packages. As you said, not
much of anything would be gained, but IIUC it complicates the
compiler, which currently does not have to know about any specific
packages.
Let's keep imports explicit.
teales
functions within functions ;=(
Jessta
> Another one that I wasn't aware of before is that you can't declare
> functions within functions ;=(
huh? sure you can.
http://golang.org/doc/go_spec.html#Function_literals
--
=====================
http://jessta.id.au
Ryanne Dolan
fmt and math are in nearly none of my go packages
it complicates the compiler
[the compiler] currently does not have to know about any specific packages
teales
> huh? sure you can.http://golang.org/doc/go_spec.html#Function_literals
>
> --
I think you know what I mean. At top level scope I can write
func outer() int { ... }
In a function scope I must write
inner := func() int { ... }
Why the irregularity?
Peter Bourgon
> import fmt or io. If you are writing a package, you would not notice this
> proposed feature.
I've written plenty of packages _and_ programs that have used fmt and
io only for testing/debugging purposes. I would not appreciate having
them auto-imported for me.
Shift your thinking on this issue. Explicit is better than implicit.
Namespaces are a good idea. There is no real downside to typing
"fmt.Printf" and there are many upsides.
Ryanne Dolan
I would not appreciate having them auto-imported for me.
Ryanne
--
www.ryannedolan.info
Ivan Krasin
>> I would not appreciate having them auto-imported for me.
>
> I'm not sure what you'd be upset about. If you don't use them, they need
> not be auto-imported; and even if they were _always_ imported, the compiler
> wouldn't generate any code unless you used them. What is lost?
example, Wprint) and at some point the function with the same name is
added to fmt package. Would you be happy that your code is failed to
compile on more recent version of go library?
Ivan
Kai Backman
>> I would not appreciate having them auto-imported for me.
>
> I'm not sure what you'd be upset about. If you don't use them, they need
> not be auto-imported; and even if they were _always_ imported, the compiler
> wouldn't generate any code unless you used them. What is lost?
The compiler would still need to find the packages during compilation
or somehow magically recognize that those packages are exempt from
lookup rules. This becomes a problem when you work with targets that
don't support the standard library, either by accident or choice. E.g.
my current work is with a small embedded target that only has a small
custom runtime and none of the standard packages.
Aside from my inconvenience, auto-import would add an element of
unnecessary surprise.
Kai
Ryanne Dolan
Ivan Krasin
> Ivan,
> I think you and Peter are misunderstanding me. This thread so far has
> addressed:
> 1) dumping package functions into the main namespace
> 2) automatically importing packages based on usage
> 3) automatically importing a small number of "default" packages
> I'm talking about (3), tho your point is valid for (1). Specifically, I
> still would like to keep [ fmt.Println ] and [ import "somepackage" ] but
> not necessarily [ import "fmt" ]
you're right, I missed your point. Sorry.
Ryanne Dolan
The compiler would still need to find the packages during compilation
auto-import would add an element of unnecessary surprise
Jessta
> Exactly. Tho some people (e.g. non-C-types) would be surprised to see that
> they need to import a package to print something.
Thankfully you don't need to import anything to print something in go.
The print() and println() functions are built-ins.
--
=====================
http://jessta.id.au
Vesa Kaihlavirta
> It would be interesting to have an informal poll on this ;=)
>
>
> Import declaration Local name of Sin
>
> import "lib/math" math.Sin
> import M "lib/math" M.Sin
> import . "lib/math" Sin
>
> I have to type the annoying dot in front of each package name in order
> to refer to an imported item without qualification. From my very
> limited experience, you can mostly get away with this without
> ambiguity, and if you find that something is ambiguous, it would be
> simple to zoom up to the top of the file and correct it if the rule
> was:
>
> import . "lib/math" math.Sin
> import M "lib/math" M.Sin
> import "lib/math" Sin
-1 on your suggestion, +1 on how it is now.
Non-qualified names are such a pain when trying to figure out what a
certain piece of code means that people who use them should be made to
jump through a hoop or two.
--vk
nsf
+1 on Vesa's thoughts.
I call it non-grepable sources. C++ has them, mostly because of
function overloading by type. Unfortunately Go has them too, because
there is polymorphic method dispatch (interfaces and their
method) and you can have same names in different modules. Personally I
find it very confusing sometimes. For example we have io.Reader and
flate.Reader. I mean.. it's really bad even that way. One of the
features I like in C is unique naming in everything. If you see
some_long_function_name, you can just grep all the sources for it and
find out what it means. No kind of redirection is necessary. C++ for
example is really horrible on this, there are: function/operator
overloading, dynamic polymorphism, preprocessor, templates and other
horrible things. It's _very_ hard to grep over C++ sources.
Well, Go has few of this problems too.. unfortunately. And I really
want that no one will make it even worse. By worse I mean encouraging
full namespace import to the current namespace.
However, Go has simple syntax and it is possible to create nice tools
for jumping over Go's sources. But currently there are no such tools.
So.. I use grep. ;-)
Peter Froehlich
> "packages" is the operative word here, since practically all _programs_ will
> import fmt or io. If you are writing a package, you would not notice this
> proposed feature.
> Why is this a good thing? The change wouldn't necessarily change any
> non-Go-specific code, so what's the big deal? Does it violate some religion
> I'm not aware of?
The religion you're not aware of has this commandment:
Just because Ryanna doesn't like to type import "fmt" import "io"
doesn't mean the language has to change. Typing less than 20
characters is a respectful bow to the keyboard and not eternal
damnation.
So there, we got religious too. :-D
--
Peter H. Froehlich <http://www.cs.jhu.edu/~phf/>
Senior Lecturer | Director, Johns Hopkins Gaming Lab
Ryanne Dolan
Typing...is a respectful bow
Ostsol
imported: (1) into the global namespace, or (2) implicitly whenever a
package is referenced (ie: when the compiler sees 'math.Sin' it
imports 'math'). The first is not worth discussing. The second is
possible, though it could also be extended to all packages -- not just
the standard library. Import declarations would then be relegated to
overriding this mechanism, such as when one the package exists
locally, rather than in GOROOT/pkg.
However, there are potential readability issues and also other
situations where explicit import declarations would be necessary. For
example, if there are two packages 'foo' and 'stuff/foo', which does
Go import? It must match the identifier being referenced to those
that are available in the two packages -- and there is still room for
ambiguity when both packages share an identifier.
My preference: keep explicit import declarations in all cases. It
keeps code clear and it keeps this aspect of the compiler simple.
-Ostsol
On Jan 24, 10:40 am, Ryanne Dolan <ryannedo...@gmail.com> wrote:
> Peter,
>
> "Go attempts to reduce the amount of typing"
>
> http://golang.org/doc/go_lang_faq.html#principles
>
> Typing...is a respectful bow
>
> If we are trading one religion for another, I should like to know why!
>
> I'm not necessarily a firm believer in either; I'm just saying we should
> stick with one, and boilerplate like importing the standard library seems to
> violate the first commandment of Go's religion.
>
> Thanks.
> Ryanne
>
> --www.ryannedolan.info
>
> On Sun, Jan 24, 2010 at 9:33 AM, Peter Froehlich <
>
>
>
> peter.hans.froehl...@gmail.com> wrote:
> > On Sun, Jan 24, 2010 at 1:16 AM, Ryanne Dolan <ryannedo...@gmail.com>
Ryanne Dolan
Thanks.
Ryanne
--
www.ryannedolan.info
OK, so we've discussed my irrational prejudices. The question I was
> You can put the semicolons in if you want to, and gofmt will take them out.
> The lack of parentheses around if conditions still trips me up too,
> but it's much cleaner to read.
>
asking is what is yours - a bit of light relief after a long day.
Ryanne Dolan
...I see two ways in which the standard library can be automatically imported: (1) into the global namespace, or (2) implicitly whenever a package is referenced...
Russ Cox
> would reduce some boilerplate without confusing anyone. I don't know what
> that balance is, or even what the default packages might be.
How does one compile those packages now that they import themselves?
Seems like a giant cycle to me, and hardly worth the effort.
Suppose you pick a set of auto-imported packages:
* Now you've saved what, one or two lines per file?
* Do we start to argue about which packages should be in the standard set?
* What happens when I add import "my/fmt" to the top of a file that was
referring to the standard fmt before? Is that an error immediately, or
do all the references silently convert? What if I wasn't using fmt before?
* How do you compile fmt if it auto-imports itself? Isn't that a cycle?
Implicit dependencies are perhaps the biggest problem in C and C++
when trying to change code in very large code bases. This is one of
the problems that Go tries to clean up, and explicit imports are a large
part of that effort.
> Notice that built-in "print" and fmt.Print are different, but probably
> shouldn't be. Clearly the Go team thinks printing should come with Go
> without asking.
No. The Go team recognizes that when you're bootstrapping a new
system it's important to be able to print before you've got enough
working to implement fmt or even import. That's why the spec refers
to them as bootstrapping functions:
http://golang.org/doc/go_spec.html#Bootstrapping
As it also says, they are not guaranteed to stay in the language.
Russ
Ryanne Dolan
Bob Cunningham
> One thing that irritates me about Go's syntax:
>
> type my struct {
> v vector.Vector
> m matrix.Matrix
> }
>
> func (v vector.Vector) Add (v vector.Vector) vector.Vector ....
>
> There is a lot less stuttering than Java, but still stuttering all
> over the place. If packages had a "default type", then they could be
> used a lot like classes. For example, the vector package implements
> the Vector struct, so:
>
> func (v vector) Add (v vector) vector ...
>
> ...could expand to the earlier version.
>
> I'm always tempted to name my structs "Class" or "Type": vector.Class,
> matrix.Type, etc. This isn't any worse than heap.Interface from the
> standard library. But again, it would be nicer just to use vector,
> matrix, heap, etc as types themselves.
>
> Since package names are currently never used on their own, this
> wouldn't break any existing code either.
I'd go with the upper-case Vector (func (v Vector) Add (v Vector) Vector
...), so the compiler can know it is a type that, if not defined in the
current context, had to have been explicitly provided by a previously
imported package. Multiple definitions would be a compile-time error.
What if I wanted to extend vector.Vector by adding fields and methods to
it, then exposing it as myVector.Vector? Code written using "vector"
would fail, because the user imported myVector instead of vector. But
code written using Vector could run unaffected.
I can't count the times I've had to do global search-and-replace to
handle such situations. It would be great if Go provided a neat
work-around by permitting the package name to be omitted from a reference.
Oh, wait, Go already does this by the 'import . "package"' syntax.
Adding a single dot doesn't seem like much of a hassle.
Never mind.
-BobC
Russ Cox
This is not a valid program. You can't define a method on
a type in another package, so this would have to be in package
vector, at which point it would become:
func (v Vector) Add(u Vector) Vector { ... }
which is much more reasonable.
Russ
Eleanor McHugh
>> [the compiler] currently does not have to know about any specific packages
>
> Why is this a good thing? The change wouldn't necessarily change any non-Go-specific code, so what's the big deal? Does it violate some religion I'm not aware of?
>
> The parser would just need to know the names of a few "default" packages. I'm not ready to clamor loudly for this feature, but I think you dismiss the idea too eagerly.
This is my first post here so treat my 2¢ accordingly :)
Making the compiler knowledgeable about specific packages so that it automagically provides support for them is a premature optimisation.
Firstly the Go language and its standard library are still very young so its entirely plausible that both will change significantly in the coming years. However by giving certain packages a special significance to the compiler at this stage there'll be a constant pressure to retain their use regardless of viable and more idiomatic alternatives.
Secondly building unnecessary dependencies into the reference implementation of the language will mean that future implementations will also have to support them, regardless of whether or not they're appropriate.
Ellie
Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason
Ryanne Dolan
Russ Cox
> usual
> import . "vector" // a class-like package
> import "os" // not a class-like package
> Does that make sense?
As Rob said earlier, import . is really for special cases,
not general use.
Suppose that you do write
import . "container/vector"
import "os"
in one of your packages, and that package defines func New().
If os decides to add a func New, no big deal, it's os.New in
your package and not a problem. If vector decides to bring
its func New back, your package breaks because of the naming
conflict. If you want your packages to work long term, it's
best to avoid import . unless you control the thing being importing
that way.
That is, overusing import . makes code fragile, overly
dependent on details of other packages.
It only makes sense when the package doing the import
and the package being imported are coordinated,
like fmt_test and fmt.
Russ
Ryanne Dolan
...that package defines func New()....
Thanks for the insight.
Eleanor McHugh
func (t Type) Method(p Param) {}
I'd love to have a shortcut such as:
method (t Type) (
func Method_1(p Param) {};
func Method_2(p Param) {};
)
or maybe even:
T method (
func Method_1(p Param) {};
func Method_2(p Param) {};
)
where type T would be bound to 'self' in each of the contained methods.
Rob 'Commander' Pike
were also a few days where function declarations had annotations for
the various pieces. Eventually we settled on the current syntax.
It's a compromise, but function declaration syntax is almost always a
compromise because it must specify so many things. Methods must
specify even more.
The current syntax certainly has drawbacks but it also has advantages:
1) It avoids the pitfalls of function declarations in C and C++.
2) Function arguments and multiple return values have the same
syntax. (Single return values are treated specially as a compromise
to brevity.)
3) As the one place in the language where types are always explicit,
the apparent verbosity can be justified as clarity.
4) The func keyword makes the meaning always clear.
Regarding the syntax of methods:
5) It's a regular extension of function syntax.
6) The receiver syntax is exactly a (one-argument) parameter list.
7) The receiver name is, like all other names, chosen by the
programmer. Because of that, it can be short yet clear, often one
letter, unlike automatically chosen ones (self, this) that must be
longer because they must not conflict with user-chosen names. If the
method doesn't use the receiver, it doesn't even need to name it.
Finally, and most important, it parses unambiguously. (There's a now-
unnecessary requirement to parenthesize a single return value of
function type, but that will be removed.)
You may think the disadvantages outweigh the advantages but we are
comfortable with the tradeoffs we made. Compromises, by definition,
do not satisfy everyone.
-rob
Eleanor McHugh
> You may think the disadvantages outweigh the advantages but we are comfortable with the tradeoffs we made. Compromises, by definition, do not satisfy everyone.
Too true, and good language design is always a compromise.
The one thing I'd say in defence of my 'method' syntax suggestions (which strictly speaking are an analogue to import and const rather than a replacement for func) is that to people coming from class-based OO languages they might feel more natural. Of course that could just be a bias I've picked up from years of Ruby coding :)
Steven Blenkinsop
func (
F1() {}
F2() int {}
)
or
func (t *T) (
M1() {}
M2() int {}
)
Though this would be ambiguous. Oh well.
Mike Ramirez
> It would be interesting to have an informal poll on this ;=)
>
For me, i'm coming from the last few years of Python, this feels so much like
it that I love using `:` for something do things like `for k,v := range vmap:`
and write the short declaration incorrect, i.e. `i = 0` instead of `i := 0`
--
"IBM uses what I like to call the 'hole-in-the-ground technique'
to destroy the competition..... IBM digs a big HOLE in the
ground and covers it with leaves. It then puts a big POT
OF GOLD nearby. Then it gives the call, 'Hey, look at all
this gold, get over here fast.' As soon as the competitor
approaches the pot, he falls into the pit"
- John C. Dvorak
Mike Ramirez
> It would be interesting to have an informal poll on this ;=)
>
My 2 cents, this thread is about what you don't like in Go syntax, not "What I
want Go to be."
Following this list since the new year and it seems to me that a majority of
threads are this style. While I won't disagree to, these threeads are a good
thing for the developers to know what we want, It's the follow up posts, not
from the developers, but from those who disagree with the developers or
consensus reasoning and fight for what they want. That makes me wonder if Go
should already be forked into something else for those people.
This also leads me to this question, why can't people let Go be what the
developers believe is the 'correct' way for the language? From their answers,
the FAQ, Docs, and before I started with Go, just the reputation of yhr people
behind Go, you knew they put a lot of thought into this.
Personally, I think Go will be a major language in the future, but I don't
believe it will be the be all-end all in languages. I don't know if one
language will cover all needs, without becoming C/C++ or similar, with a lot
of convulution in the compiler (or interpretter) and tricky syntatic rules.
If I offended anyone, sorry, I'm just venting my own little frustrations.
Mike
--
Let's just be friends and make no special effort to ever see each other again.