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
