Hi Greg:
There is some danger of going too far the other way -- of so simplifying the
error message that it is no longer useful in identifying and correcting the
problem. To a certain extent, a programmer must understand the underlying
computational model to use the language effectively. The mark of a truly
elegant language would be that no interpretation is required. If you (or the
user) can put, "Duh!" at the end of every error message, I think that comes
pretty close to the goal.
I also tend to think that too much information is better than too little. So
whatever the accompanying explanation, providing the name of the function being
called and the index (or name) of the mismatched formal argument would surely
be a help. In my initial patch, I have mirrored the existing behavior for the
sake of keeping the patch minimal, but I don't think the wording of the message
is idea.
Regarding the language question anent the error message under discussion: At
one point in the development of GNU C++, the compiler would insert reference
temps in certain contexts a non-lvalue argument was supplied where an lvalue
was expected, and then warn the user not to expect the original to be updated.
I'd have to write a test program to see how that case is handled these days,
but I don't recall seeing that warning message in quite a while. I suspect
they simply flag it as an error, since the other alternative -- silently
failing to update an argument -- is confusing.
That still leaves the question of how to relate that one cannot take the
address of an entity without using the term "rvalue". "Constant" does not
capture all of the cases of interest. I was reading the Python spec yesterday,
and they use "immutable" for objects whose values cannot change. Numbers
(including constants and computed values) fall into this category. It's
actually a handy conceptual distinction that we might work into our own spec.
For consideration:
"error: Attempt to pass an immutable value by reference, in argument 1 'a'
of function '='."
(Duh! ;-)
The eventual goal -- well after the assign-to-ref patch gets checked in -- is
to use the "=" operator only where it is explicitly mentioned by the user
(ignoring places where it is currently interpreted as 'initialization' rather
than 'assignment'). At that point in time, there would be nothing special
about the operator '='. The compiler could (in theory) treat it uniformly with
any other operator, and after parsing like any other function. Only the module
code would superimpose the convention that '=' means assignment. So it would
seem reasonable to also push into the module code the responsibility for
detecting and reporting the undesirability of supplying an immutable value on
the left side. To do that, it would probably be desirable to support overloads
of a function in which one version can bind to an immutable object while
another binds to a mutable one. To some extent, this is what is done in C++11
to support the "move" constructor and similar functions.* So if Chapel
is to support move-constructors etc. sometime, we will have to move in that
direction.
All of this is to say that doing a string-match against the function name "="
so we can say something about "assignment" is a bit out-of-place in the
compiler code. Again, I am willing to mimic existing behavior at this point,
but I don't particularly care for it.
THH
*The magic is all in overloading and binding, not related to whether the
functions involved are constructors, assignment operators or something else.
________________________________________
From: Greg Titus [[email protected]]
Sent: Wednesday, January 22, 2014 8:10 AM
To: Brad Chamberlain
Cc: Chapel Sourceforge Developers List
Subject: Re: [Chapel-developers] Attention: Upcoming noisy changes in Chapel
assignment. (fwd)
I'm late to this party, but this will still be useful ...
I think messages are more helpful when they can easily be tied back to
the code the user wrote, rather than some underlying abstraction
reflecting the language as formally specified or the IR to which the
compiler has reduced the user's code. So, "cannot assign to a const" is
FAR better than "non-lvalue actual is passed to a 'ref' formal of =".
This is particularly true if the language is at all expected to be used
as a teaching tool for novice programmers, and I believe that's a role
we would like to see Chapel fill.
greg
On Fri, 17 Jan 2014, Brad Chamberlain wrote:
>
> Taking this part of this message to the developers list (so as not to bias
> users prematurely... I don't mind trying to bias you guys :):
>
>> A consequence of this change is that the error message issued when an
>> attempt is made to supply a non-lvalue as the left operand of assignment
>> will change from
>> error: illegal lvalue in assignment
>> to
>> error: non-lvalue actual is passed to a 'ref' formal of =
>> Suggestions for further improvements in the error message would be
>> welcome.
>
> I've proposed to Tom that for the new/naive user to Chapel, the current
> message seems more instructive than the latter to me. In particular, if I
> write:
>
> const x = 1;
> ...
> x = 2;
>
> the second message seems pretty confusing given that I may not (yet) think
> of =() as being a function, may not think of it as having a formal, may
> not even know what a 'ref' argument is; whereas the former is a bit more
> plain/intuitive/direct. To that end, I've advocated for keeping the
> status quo message as we change the =() signatures and considering
> rewording/clarifications as a separate change, if at all.
>
> If we were looking at rewording, I could easily get behind moving away
> from the term 'l-value' in error message(s) like this, as I think it's
> pretty technical for a typical user. In what cases would it be
> wrong/misleading to say something simpler like "error: cannot assign to
> const"?
>
> I think Tom's main argument against the status quo is one of getting rid
> of special cases in the compiler. I view special cases to make error
> messages clearer worthwhile (And in this case, I say that knowing that
> the special case is not particularly fragile or difficult to put in --
> in fact, it's much easier in Tom's patch he's working on than it is
> in trunk).
>
> I think lack of special cases for error messages is why so many error
> messages (ours, and in other languages) can be hard to understand, esp.
> for a non-expert. Put another way, I think we should sacrifice a bit of
> our time/effort in special casing error messagse if we think it will make
> users more productive. In this case, I think it will.
>
> -Brad
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Chapel-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/chapel-developers
>
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
