* Speaking of the error message, "error: cannot assign to const" seems more general than "cannot assign to l-value", because it also includes l-value consts, which should not be assignable.
One way to take that out of the compiler might be to have a fall-back function (or two) in the module that would be resolved to when the actuals are non-lvalues or const lvalues. Those functions would throw a compilerError(). Maybe proc =(in a, b) and proc =(const ref a, b) ? * Tom, you mention that proc = would still have a 'return' value in some cases. This seems like an unfortunate complication, although I am sure you have reasons for it. Are you envisioning this as a temporary measure? Could you give an example? Vass On 01/17/2014 05:42 PM, 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
