"imported and not used" AND "undefined"

[Zac Burns]

Greetings,

If I create a package like so:

package1/
a.go
b.go

And eventually decide that b should get it's own package and refactor

package1/
a.go

b/
b.go

Now an import of b in package1/a will say "imported and not used: b",
where uses of b later on in the same file will say "undefined: b".
This seems to me a bug, or am I doing something wrong? It has happened
to me more than once, and usually I resign to undo the refactor...
which is undesirable.

-Zac

[bflm]

On Jun 12, 8:28 am, Zac Burns <z...@exoweb.net> wrote:
> Now an import of b in package1/a will say "imported and not used: b",
> where uses of b later on in the same file will say "undefined: b".
> This seems to me a bug, or am I doing something wrong? It has happened
> to me more than once, and usually I resign to undo the refactor...
> which is undesirable.

Try to reproduce the error in a minimal example for others to
investigate.

Without that I can only guess that package b was maybe:
- Not installed when compiling package a.
- Installed, but in a different path than used while importing to a.

Anyway, I guess it's not a compiler bug but rather something like the
above.

HTH

[⚛]

I know what you mean. The answer is that it is not a bug - it is
intentional.

In the first case (files "a.go" and "b.go" belong to the same
package), the Go compiler is treating their contents as a general
graph-like structure. Imagine the symbols used in the file as nodes of
the graph, and usage-relationships as edges.

In the second case (file "package1/a.go" and file "package2/b.go"),
the Go compiler is treating the relationship between the files as a
partial ordering. Every partial ordering is a graph, but not all
graphs are partial orderings. This is why you cannot (in the case you
are referring to) simply move the file "a.go" to a separate package.

To solve the issue and move "a.go" to a different package, you have to
realize what the relationships among the symbols in the *original*
files "a.go" and "b.go" are. After you know the relationships, you
will have to devise a strategy of how to modify *both* "a.go" and
"b.go" so that the *new* relationships among symbols between the files
form a partial ordering or a tree-like structure. One method of
achieving this is to define a couple of Go interface types. Another
method is to define a public struct type in one file, with some public
fields in there, and then use it to communicate data between "a.go"
and "b.go".

On Jun 12, 8:28 am, Zac Burns <z...@exoweb.net> wrote:

[Russ Cox]

On Sun, Jun 12, 2011 at 02:28, Zac Burns <z...@exoweb.net> wrote:
> Greetings,
>
> If I create a package like so:
>
> package1/
>   a.go
>   b.go
>
> And eventually decide that b should get it's own package and refactor
>
> package1/
>   a.go
>
> b/
>   b.go
>
> Now an import of b in package1/a will say "imported and not used: b",
> where uses of b later on in the same file will say "undefined: b".

What does the package line in b.go say? Does it say 'package b'?

Russ

[Zac Burns]

Yes, I believe this was the problem. I forgot to change the package declaration.

-Zac

[⚛]

This is interesting (in a positive way): we presented you with 3
possible explanations of what the cause of the problem might be. One
of those 3 possibilities (Russ's option) matched the actual cause.

It is worth noting that all the 3 people who responded to your post
had the same assumption: it is not a compiler bug. In other words, all
3 options were actively *protecting* the compiler from being modified.
And so it is, the compiler won the fight once again. I am wondering,
how is the compiler doing this (the winning)? Any ideas?

[chris dollin]

On 13 June 2011 08:58, ⚛ <0xe2.0x...@gmail.com> wrote:
> This is interesting (in a positive way): we presented you with 3
> possible explanations of what the cause of the problem might be. One
> of those 3 possibilities (Russ's option) matched the actual cause.
>
> It is worth noting that all the 3 people who responded to your post
> had the same assumption: it is not a compiler bug.

I think the assumption is more "it is /unlikely/ that it is a compiler
bug in this well-trod area; it is /more likely/ that it is a
user mistake."

> In other words, all 3 options were actively *protecting*
> the compiler from being modified.

I don't think that's "other words" for the assumption.

> And so it is, the compiler won the fight once again. I am wondering,
> how is the compiler doing this (the winning)?   Any ideas?

By being pretty close to an implementation of the spec.

Chris

--
Chris "allusive" Dollin

[⚛]

On Jun 13, 10:39 am, chris dollin <ehog.he...@googlemail.com> wrote:

> On 13 June 2011 08:58, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
>
> > This is interesting (in a positive way): we presented you with 3
> > possible explanations of what the cause of the problem might be. One
> > of those 3 possibilities (Russ's option) matched the actual cause.
>
> > It is worth noting that all the 3 people who responded to your post
> > had the same assumption: it is not a compiler bug.
>
> I think the assumption is more "it is /unlikely/ that it is a compiler
> bug in this well-trod area; it is /more likely/ that it is a
> user mistake."

I don't think the subject I am talking about is about likely-ness. You
can count your post as the 4th post which is trying to protect the
compiler. I am wondering: how is the compiler doing this?

> > In other words, all 3 options were actively *protecting*
> > the compiler from being modified.
>
> I don't think that's "other words" for the assumption.
>
> > And so it is, the compiler won the fight once again. I am wondering,
> > how is the compiler doing this (the winning)?   Any ideas?
>
> By being pretty close to an implementation of the spec.

Well, but that would imply that the Go spec existed before the
compiler had even 1 line of source code in it. I don't think that's
the case (or even possible). The spec and the compiler were developed
in concert with each other. Some parts of the spec are based on the
compiler (i.e: (1) you try to implement idea X from a spec, (2) it
does not work, (3) you change the spec to meet what works and is
actually implementable; or (1) you implement something in the compiler
and (2) add it to the spec afterwards because it works, or just
because it already exists in the compiler and you are too lazy to
delete the source code).

[chris dollin]

On 13 June 2011 13:14, ⚛ <0xe2.0x...@gmail.com> wrote:
> On Jun 13, 10:39 am, chris dollin <ehog.he...@googlemail.com> wrote:
>> On 13 June 2011 08:58, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
>>
>> > This is interesting (in a positive way): we presented you with 3
>> > possible explanations of what the cause of the problem might be. One
>> > of those 3 possibilities (Russ's option) matched the actual cause.
>>
>> > It is worth noting that all the 3 people who responded to your post
>> > had the same assumption: it is not a compiler bug.
>>
>> I think the assumption is more "it is /unlikely/ that it is a compiler
>> bug in this well-trod area; it is /more likely/ that it is a
>> user mistake."
>
> I don't think the subject I am talking about is about likely-ness.

I'm not sure what you're talking about, but I am sure you're
over-assuming about what people's assumptions are. And
your case, it seems to me, relies on the correctness of your
absoluteness assumption.

> You can count your post as the 4th post which is trying to
> protect the compiler.

Assuming that an error like the one described is more likely
to be a user error than a compiler bug is not "trying to protect
the compiler". The compiler doesn't need "protecting"; it needs
fixing, or not.

> I am wondering: how is the compiler doing this?

The compiler isn't "doing this". If there's a doing involved
it's our doing. The compiler is a bunch of code for checking
and translating a formal language, and is relaible to some
degree in doing this -- reliable enough that when problems
using it are reported, one doesn't automatically assume that
it's a bug in that code. Multiple alternatives are available
and once needs more information to winnow them out; but
a preliminary guess isn't "protection".

>> By being pretty close to an implementation of the spec.
>
> Well, but that would imply that the Go spec existed before the
> compiler had even 1 line of source code in it.

No it wouldn't, not if by "the Go spec" you meant exactly the
document we have today ...

> I don't think that's the case (or even possible).

I don't see why it wouldn't be /possible/. Very many things
are /possible/, just not locally true.

> The spec and the compiler were developed
> in concert with each other. Some parts of the spec are based on the
> compiler (i.e: (1) you try to implement idea X from a spec, (2) it
> does not work, (3) you change the spec to meet what works and is
> actually implementable; or (1) you implement something in the compiler
> and (2) add it to the spec afterwards because it works, or just
> because it already exists in the compiler and you are too lazy to
> delete the source code).

Usually -- not always, but usually -- we use the spec to decide
what the behaviour of the compiler and the code it compiles
should be, and if they're different, the spec "wins", (You might
ask "how is the spec doing this?", but I won't.) The compiler
"protects" itself by "allowing" itself to be modified into agreement
with the spec and "evolving" into a "bug-free" descendent.

Sometimes the compiler is a tool to explore new options for the spec.
But the fact that the code is in the compielr doesn't make it right.

[Kyle Lemons]

This is interesting (in a positive way): we presented you with 3
possible explanations of what the cause of the problem might be. One
of those 3 possibilities (Russ's option) matched the actual cause.

This is why we have a mailing list.  Not just so everyone can have the benefit of Russ's insight (though that is certainly one argument ;-)), but so that the community as a whole can chip in their own experience to help out other members of the community.  We can't all be correct in all cases, but even when we are wrong in assessing a problem, there is a better-than-zero chance that someone reading our answer will file that away and not make the suggested mistake.

 

It is worth noting that all the 3 people who responded to your post
had the same assumption: it is not a compiler bug.

I wouldn't say that was their assumption at all.  In fact, if you assumed it WAS a compiler bug, you would probably make the same suggestions, because (without actual code on which to experiment) you have to eliminate all of the possible non-compiler sources of the bug to whittle down a useful test case.

 

In other words, all
3 options were actively *protecting* the compiler from being modified.

That implies that we think the compiler needs protection.  I don't think anyone really thinks that; in fact, there are certainly a lot of people who think that the compiler needs work (though not for the reason that it is incorrect, per-se).

 

And so it is, the compiler won the fight once again. I am wondering,
how is the compiler doing this (the winning)?   Any ideas?

The compiler didn't win.  The OP won, because he got his question answered.  The community won, because it successfully helped one of its own.  If it had been a compiler issue, it would have been whittled down, filed as a bug, fixed, and submitted; also, in my mind, a "win" scenario for everyone involved...  Perhaps this is the answer to your question: the compiler "wins" both by being correct and by having its issues identified and fixed, and thus should keep "winning" as long as we keep this up.

~K

[Ian Lance Taylor]

⚛ <0xe2.0x...@gmail.com> writes:

> It is worth noting that all the 3 people who responded to your post
> had the same assumption: it is not a compiler bug. In other words, all
> 3 options were actively *protecting* the compiler from being modified.
> And so it is, the compiler won the fight once again. I am wondering,
> how is the compiler doing this (the winning)? Any ideas?

My experience over many years is that 99% of the cases where a
programmer suspects a compiler bug turn out to be a bug in the program.
Because the Go compiler is newer than most compilers, I think one could
reasonably reduce that to 90%.

Anyhow, the compiler isn't somehow being protected from being modified.
It's the spec that matters. If the spec says one thing, and the
compiler does another, then we fix the compiler.

Ian

[Russ Cox]

> My experience over many years is that 99% of the cases where a
> programmer suspects a compiler bug turn out to be a bug in the program.
> Because the Go compiler is newer than most compilers, I think one could
> reasonably reduce that to 90%.

Also, the probability here varies dramatically with who the programmer is.
It's still well over 99% for new Go programmers.

Russ

[⚛]

On Jun 13, 2:43 pm, chris dollin <ehog.he...@googlemail.com> wrote:
> > I am wondering: how is the compiler doing this?
>
> The compiler isn't "doing this". If there's a doing involved
> it's our doing. The compiler is a bunch of code for checking
> and translating a formal language, and is relaible to some
> degree in doing this -- reliable enough that when problems
> using it are reported, one doesn't automatically assume that
> it's a bug in that code. Multiple alternatives are available
> and once needs more information to winnow them out; but
> a preliminary guess isn't "protection".

An analogy: A wasp (the little animal) is (supposedly) just a bunch of
atoms connected together in a specific pattern. Despite this, most
people think it is correct to say that "The wasp is doing this" or
"The wasp is doing that".

If it is normal to say about a wasp that it is "doing something", then
it is probably also correct to say that a compiler is "doing
something".

[⚛]

On Jun 13, 6:21 pm, Kyle Lemons <kev...@google.com> wrote:
> > This is interesting (in a positive way): we presented you with 3
> > possible explanations of what the cause of the problem might be. One
> > of those 3 possibilities (Russ's option) matched the actual cause.
>
> This is why we have a mailing list.  Not just so everyone can have the
> benefit of Russ's insight (though that is certainly one argument ;-)),

I wouldn't call it insight. I call it luck. (But by this I do *not*
mean disrespect to anyone.)

There are stages in every programmer's intellectual development. Once
the programmer passes stage X of understanding, he or she will never
make a certain type of errors while programming in the future. That is
why we call it an understanding: once you know what you are doing, you
will stop making certain type of errors. The question implicitly posed
by the 1st post in this forum thread was "What is the 'stage' in which
Zac Burns is?". Nobody who read the 1st post knew the answer. This is
why there were multiple options presented to Zac Burns about the
possible cause of the error.

> but
> so that the community as a whole can chip in their own experience to help
> out other members of the community.  We can't all be correct in all cases,
> but even when we are wrong in assessing a problem, there is a
> better-than-zero chance that someone reading our answer will file that away
> and not make the suggested mistake.
>
> > It is worth noting that all the 3 people who responded to your post
> > had the same assumption: it is not a compiler bug.
>
> I wouldn't say that was their assumption at all.  In fact, if you assumed it
> WAS a compiler bug, you would probably make the same suggestions,

No. If I assumed it was a compiler bug, I would assume that Zac's
source code *is correct*. The reasoning would then go like this:

- Zac's source code is correct.
- Since Zac's source code is correct, then there is a bug in the
compiler and in the Go language specification.
- Therefore we need to fix both the compiler and the specification.
- All people affected by the change in the compiler and specification
need to fix their codes.

Once again: How is it possible that the compiler+spec won?

> because
> (without actual code on which to experiment) you have to eliminate all of
> the possible non-compiler sources of the bug to whittle down a useful test
> case.
>
> > In other words, all
> > 3 options were actively *protecting* the compiler from being modified.
>
> That implies that we think the compiler needs protection.  I don't think
> anyone really thinks that; in fact, there are certainly a lot of people who
> think that the compiler needs work (though not for the reason that it is
> incorrect, per-se).
>
> > And so it is, the compiler won the fight once again. I am wondering,
> > how is the compiler doing this (the winning)?   Any ideas?
>
> The compiler didn't win.  The OP won, because he got his question answered.
>  The community won, because it successfully helped one of its own.  If it
> had been a compiler issue,

Well, the only rational explanation why it isn't a compiler issue is
that Zac Burns tacitly agreed to respect the current specification of
the Go language. The program he wrote is a demonstration of the
mentioned agreement to respect the spec and the compiler. So,
logically, if he agreed to respect ("submit to") the spec and the
compiler implementation, then it cannot be a compiler bug.

But he wrote in his post that "This seems to me a bug ...". This
implies that he did *not* agree to respect the spec or the compiler.
Or alternatively, he wasn't conscious of making the agreement.

How is that possible?

[chris dollin]

On 14 June 2011 09:43, ⚛ <0xe2.0x...@gmail.com> wrote:

> If it is normal to say about a wasp that it is "doing something", then
> it is probably also correct to say that a compiler is "doing
> something".

The compiler is "doing something", insofar as a purely abstract
pattern of bits can be a doer. What it's doing is compiling. What
it's not doing is protecting itself in any useful sense.

[Jan Mercl]

On Tuesday, June 14, 2011 10:43:04 AM UTC+2, ⚛ wrote:

On Tuesday, June 14, 2011 10:43:08 AM UTC+2, ⚛ wrote:

alt.Zen.Philosophy <- nil

[chris dollin]

On 14 June 2011 09:43, ⚛ <0xe2.0x...@gmail.com> wrote:

> There are stages in every programmer's intellectual development. Once
> the programmer passes stage X of understanding, he or she will never
> make a certain type of errors while programming in the future.

False. I mean, completely clearly and obviously false. Falser
than a very false thing.

Mere understanding is not a Circle of Protection: Mistake.

> Once again: How is it possible that the compiler+spec won?

There was no fight. Nobody (no thing) "won". I really don't see
what's to be gained by casting the problem-solving that went
on as a "fight" with items being "protected" and something
"winning".

> Well, the only rational explanation

Really? The /only/ rational explanation?

> So,
> logically, if he agreed to respect ("submit to") the spec and the
> compiler implementation, then it cannot be a compiler bug.

Submit? Where did that come from?

It's a compiler bug if the compiler doesn't conform to the behaviour
described in the spec, unless the behaviour described in the spec is
not the behaviour that relevant interested parties think is appropriate,
in which case we don't know whether it's a compiler bug or not, just as is
true for any program.

> But he wrote in his post that "This seems to me a bug ...". This
> implies that he did *not* agree to respect the spec or the compiler.

"... or am I doing something wrong?" This implies he is willing to
respect the spec and/or the compiler (which are two different things).

[⚛]

On Jun 13, 6:51 pm, Ian Lance Taylor <i...@google.com> wrote:

> ⚛ <0xe2.0x9a.0...@gmail.com> writes:
> > It is worth noting that all the 3 people who responded to your post
> > had the same assumption: it is not a compiler bug. In other words, all
> > 3 options were actively *protecting* the compiler from being modified.
> > And so it is, the compiler won the fight once again. I am wondering,
> > how is the compiler doing this (the winning)?   Any ideas?
>
> My experience over many years is that 99% of the cases where a
> programmer suspects a compiler bug turn out to be a bug in the program.

Yes. But why is that?

> Because the Go compiler is newer than most compilers, I think one could
> reasonably reduce that to 90%.
>
> Anyhow, the compiler isn't somehow being protected from being modified.
> It's the spec that matters.  If the spec says one thing, and the
> compiler does another, then we fix the compiler.

Is it theoretically possible that the spec contains an error which
will be revealed to us sometime in the future thanks to the compiler
implementation of the spec?

In reality, an idea is added to the spec *after*:

- the idea has been implemented in a compiler, or
- the idea has been "implemented" in somebody's mind, or
- the idea has been proved useful by history, or
- the idea has been consciously recognized as an experimental idea
(nobody knows whether it will work)

If a spec contains ideas that do not fall into any of the 4 mentioned
categories, the spec is probably doomed.

[chris dollin]

On 14 June 2011 10:14, ⚛ <0xe2.0x...@gmail.com> wrote:
> On Jun 13, 6:51 pm, Ian Lance Taylor <i...@google.com> wrote:
>> ⚛ <0xe2.0x9a.0...@gmail.com> writes:
>> > It is worth noting that all the 3 people who responded to your post
>> > had the same assumption: it is not a compiler bug. In other words, all
>> > 3 options were actively *protecting* the compiler from being modified.
>> > And so it is, the compiler won the fight once again. I am wondering,
>> > how is the compiler doing this (the winning)?   Any ideas?
>>
>> My experience over many years is that 99% of the cases where a
>> programmer suspects a compiler bug turn out to be a bug in the program.
>
> Yes. But why is that?

Because compilers get fixed.

> Is it theoretically possible that the spec contains an error which
> will be revealed to us sometime in the future thanks to the compiler
> implementation of the spec?

Of course. This is neither novel nor a problem.

> In reality, an idea is added to the spec *after*:
>
> - the idea has been implemented in a compiler, or
> - the idea has been "implemented" in somebody's mind, or
> - the idea has been proved useful by history, or
> - the idea has been consciously recognized as an experimental idea
> (nobody knows whether it will work)

Ditto.

> If a spec contains ideas that do not fall into any of the 4 mentioned
> categories, the spec is probably doomed.

We (and our specs) are all doomed, yet life goes on.

[⚛]

This is not Zen, for Gods sake. I just want to know the rational
explanations of why in almost 100% of cases when people suggest that
the Go compiler might be wrong, it is concluded that the compiler is
not wrong and the spec is also not wrong. I just want to know *how* it
is possible that thousands of people are able to accept that their
source codes are wrong.

Give it a try. Write your explanation. "Accusing" me of Zen philosophy
cannot be an answer (and you know it cannot be the answer).

[Jan Mercl]

On Tuesday, June 14, 2011 11:47:23 AM UTC+2, ⚛ wrote:

I was not accusing you of anything. It was, I thought obviously, meant as a pointer to where this discussion about the secrets of wasp life and compilers self defense tactics IMHO fits better.

[chris dollin]

On 14 June 2011 10:47, ⚛ <0xe2.0x...@gmail.com> wrote:
> On Jun 14, 11:05 am, Jan Mercl <jan.me...@nic.cz> wrote:
>> On Tuesday, June 14, 2011 10:43:04 AM UTC+2, ⚛ wrote:
>> On Tuesday, June 14, 2011 10:43:08 AM UTC+2, ⚛ wrote:
>>
>> alt.Zen.Philosophy <- nil
>
> This is not Zen, for Gods sake. I just want to know the rational
> explanations of why in almost 100% of cases when people suggest that
> the Go compiler might be wrong, it is concluded that the compiler is
> not wrong and the spec is also not wrong.

My explanation would be that the compiler and spec are not
wrong, and so it is rational to conclude that they are not wrong.

> I just want to know *how* it
> is possible that thousands of people are able to accept that their
> source codes are wrong.

Headology.

[⚛]

"alt.Zen.Philosophy <- discussion" would better convey what you meant
than sending "nil" through the connection ...

[⚛]

On Jun 14, 12:02 pm, chris dollin <ehog.he...@googlemail.com> wrote:

> On 14 June 2011 10:47, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
>
> > On Jun 14, 11:05 am, Jan Mercl <jan.me...@nic.cz> wrote:
> >> On Tuesday, June 14, 2011 10:43:04 AM UTC+2, ⚛ wrote:
> >> On Tuesday, June 14, 2011 10:43:08 AM UTC+2, ⚛ wrote:
>
> >> alt.Zen.Philosophy <- nil
>
> > This is not Zen, for Gods sake. I just want to know the rational
> > explanations of why in almost 100% of cases when people suggest that
> > the Go compiler might be wrong, it is concluded that the compiler is
> > not wrong and the spec is also not wrong.
>
> My explanation would be that the compiler and spec are not
> wrong, and so it is rational to conclude that they are not wrong.

Yes, but I thought someone would be able to pinpoint the moment(s)
when a person accepts that the compiler&spec are not wrong and
determines that it is his/her code that needs to be fixed, and provide
some rational description/model of how and why it is happening so that
we can better understand the process.

I think I am going to stop pushing the subject, without getting any
sensible answer (from my perspective). Someone from the Go team
writing "Take this discussion somewhere else please" is imminent.

[Ian Lance Taylor]

⚛ <0xe2.0x...@gmail.com> writes:

> On Jun 13, 6:51 pm, Ian Lance Taylor <i...@google.com> wrote:
>>
>> My experience over many years is that 99% of the cases where a
>> programmer suspects a compiler bug turn out to be a bug in the program.
>
> Yes. But why is that?

When Alice's program does not work as she expects, she has to figure out
what is wrong. She looks at her program: she understands her program,
her program is simple, she has written what she wanted and it looks
right. She looks at the compiler: she does not understand the compiler,
the compiler is complex. Add to that the natural inclination to prefer
to think that she has not made a mistake, and it becomes natural to
conclude that the compiler is in error.

I've seen many people follow this line of reasoning when reporting a
compiler bug. Generally they are not sufficently considering that the
compiler is being used satisfactorily by thousands of people, and that
all the simple bugs have been squeezed out by the pressure of all those
people. Their program has been used by one person, and no such pressure
has been applied.

> Is it theoretically possible that the spec contains an error which
> will be revealed to us sometime in the future thanks to the compiler
> implementation of the spec?

Of course. It's not particularly likely but it's certainly
theoretically possible. Implementation often reveals issues in the
spec, but it usually does so immediately, not in the future. I think
it's worth noting that when that happens--when the compiler reveals an
error in the spec--the action taken is not normally to adjust the spec
to conform to the compiler; it is to try to consider the spec by itself
and figure out what the right solution is.

> In reality, an idea is added to the spec *after*:
>
> - the idea has been implemented in a compiler, or
> - the idea has been "implemented" in somebody's mind, or
> - the idea has been proved useful by history, or
> - the idea has been consciously recognized as an experimental idea
> (nobody knows whether it will work)
>
> If a spec contains ideas that do not fall into any of the 4 mentioned
> categories, the spec is probably doomed.

Sure, but what does that have to do with anything? The point is that in
a language like Go the spec is primary and the compilers are secondary.

Ian

[Ian Lance Taylor]

⚛ <0xe2.0x...@gmail.com> writes:

Because programming means writing down the actions that you want an
abstract machine to take. Those actions must be ones that the abstract
machine can perform.

In writing a compiler and/or a language spec, the compiler/language
writer is defining a new abstract machine. (The compiler is itself a
program written in an abstract machine, which may or may not be the same
as the abstract machine that the compiler provides for its users.)

When your program doesn't work, and when somebody points out that you
violated some specific rule of the abstract machine, you conclude that
your program is wrong. To conclude that the abstract machine is wrong
is a level shift. It's worth thinking about that if you are in the
business of defining a new abstract machine, as is the case for language
designers. For most people, who are not defining a new abstract
machine, thinking about how the abstract machine could be changed can be
amusing but is time taken away from actually getting their program to
work.

Ian

[Pete Wilson]

On Jun 14, 5:02 am, chris dollin <ehog.he...@googlemail.com> wrote:

> > I just want to know *how* it
> > is possible that thousands of people are able to accept that their
> > source codes are wrong.
>
> Headology.
>

Pratchett rules!

[Russ Cox]

> This is not Zen, for Gods sake. I just want to know the rational
> explanations of why in almost 100% of cases when people suggest that
> the Go compiler might be wrong, it is concluded that the compiler is
> not wrong and the spec is also not wrong.

So you are asking why is it that the Go developers do not reply
to every invalid program by saying "oh, that's our mistake, that
should have worked, we'll change the language and implementations
so that is valid"?

Because Go is not C++.

Russ

[John Asmuth]

Because for some case in the future, almost 100% of the cases in the past are such that the compiler was not wrong. We choose the option that is most likely to be correct, given what we know.

This is rational and can be explained by bayesian statistics.

Let's say that we start with some compiler that we know nothing about. You might have some kind of baseline faith in its correctness. A skeptic might say that if a given piece of code does not create the expected program, 99 times out of 100 it is the compiler's fault. Certainly if I wrote the compiler, this would be the case. However, we're not pulling compilers from the wild each time - we are using the same compiler over and over again (pretending it is never fixed). Any compiler might have an error rate (.99 corresponding to the compiler being at fault 99 times out of 100), and we need some likelihood for any given error rate.

The natural distribution to use here is the Beta distribution. I'm not going to go into details (wikipedia), but if I say the compiler is drawn from Beta(1,99) is an assumption that the compiler is probably junk. The first number represents the confidence in the code being at fault, the 2nd being confidence in the compiler being at fault. The ratio between these two numbers can be turned into the probability, and the magnitude represents my confidence in that probability.

Now we start seeing examples. Out of 1000 examples of problems involving code and the compiler, the code was at fault 999 times. Now someone gives a new problem. Given what has been stated so far (and assuming we use the same compiler each time), what can we say about the likelihood that the compiler is at fault?

We can answer this question exactly (if our prior assumption on compiler effectiveness is true, and some other things). The probability is 999+1 vs 1+99, or the number of examples of fault added to our initial confidence in either case. That is, 9 times out of 10, it's the code.

Now, lots of assumptions are made here about the purity of statistics. These probabilities are only as "true" as the assumptions (which are not true). However, it has been shown that humans think along these lines (google scholar bayesian decision making in humans), and it can explain the tendency of posters on this list to defend the compiler when given the choice of a compiler mistake or a code mistake.

- John

[⚛]

I am writing this just to clarify the meaning of what I wrote before.

By "passing stage X of understanding" I meant that X is an arbitrary
variable that one can substitute with anything appropriate. X is *not*
some kind of a mysterious stage. The one word "learning" would be a
good description of what I meant - although the problem is that it
fails to convey the idea that learning is happening in stages.

[Brendan Tracey]

I just had a similar situation to the OP (got both package undeclared and package not used). The resolution was the same as Russ's suggestion. Is it possible to give a better error? (For example, check if both errors are present and suggest that maybe there is a package name issue). Just a thought.