[Grace-core] New errors

[Kim Bruce]

I'm happy to take it out, but I tried eliminating all of them from staticTypes.grace (see the file I attached), and the result was that the program never executed -- it seemed to somehow die while executing the checker.  I don't understand at all why this happened, but that was my major frustration.  It's especially frustrating in that the code before adding the arity check seemed to work fine, but the new version does not, even after eliminating all of those else statements!

Kim

P.S.  I just realized that I didn't include my rewrite of staticTypes.grace.  I've added it here.

P.P.S.  I agree there is no reason for the else clause.  In my rewrite of staticTypes.grace I replaced occurrences generally by
case{n:Object -> ...}

On Aug 8, 2014, at 9:43 PM, Andrew P. Black <black at cs.pdx.edu> wrote:

> Update (back from dinner)
> 
> I read the spec (and updated the name from catch()case()):  try()case() does not have an else clause, at least, not according to the spec.
> 
> I propose that we continue not to have one, and take it out of the parser.    If you don’t like that, we can discuss it further.
> 
> 	Andrew
> 
> 
> On 8 Aug 2014, at 18:33, Andrew P. Black <black at cs.pdx.edu> wrote:
> 
>> Kim,
>> 
>> The cause of the problem is simple. 
>> 
>> I never knew that match()case() had an else part — I’ve always written { param ->  … } as the final case to catch any cases not otherwise caught.   But it does — and they are applied to the scrutinee as argument.   
>> 
>> There are some match statements in the static types dialect that have else branches with no arguments, for example, line 160, line 401.  When you get an error message, it should tell you the offending line number.
>> 
>> So, if the structure of the code that is being checked is such that the else case is executed, and it has no argument, it will indeed generate an error.
>> 
>> There are two fixes.  One is to add parameters to all of the offending else cases.  The other is to change the language so that else cases aren’t applied to arguments.   It’s trivial to make the change in the code generator, but it should also be made in the parser.
>> 
>> It seems to me that the second option is best, since a parameter in the else part serves no purpose — one may as well use the scruitnee.  And if one does need a parameter, one can write case { p -> … }
>> 
>> But we would need to agree on this!
>> 
>> 	Andrew
>> 
>> 
>> On 8 Aug 2014, at 17:08, Kim Bruce <kim at cs.pomona.edu> wrote:
>> 
>>> Hi Andrew,
>>> 
>>> I hope your trip home went smoothly.  I think it was very productive having you down here.
>>> 
>>> Alas, I have a problem that seems to have arisen resulting from the fix that raises errors when blocks/methods have the wrong number of parameters.  This issue shows up with the dialect staticTypes.
>>> 
>>> When I compile it under the system at 
>>> 	http://www.cs.pomona.edu/~kim/minigrace/js/
>>> it compiles OK.  However, when I use it in code like the following:
>>> 
>>> dialect "staticTypes"
>>> print "hello"
>>> 
>>> method m(n:Number) -> Number {5}
>>> 
>>> print (2)
>>> 
>>> var x:Number := 2
>>> 
>>> -------------------
>>> then I get run-time errors complaining about wrong numbers of arguments in "else" clauses that follow match statements.  I can make those error statements go away by either commenting out the else clause (many are empty) or replacing them with a generic case:
>>>   case{n -> ...}
>>> that should match anything.
>>> 
>>> Changing those (there are about 4 of them that show up with different code using the dialect), results in an execution of the code that seems to get stuck in the checker and just terminates without executing the code (e.g., nothing gets printed in the above program)
>>> 
>>> On the other hand, if I leave off the declaration of the var above, then it works fine.  I get similar problems with defs, if then else, etc.
>>> 
>>> If I run all this on the code at your web site: http://web.cecs.pdx.edu/~black/minigrace/js/index.html
>>> I get the same problem, while running at
>>> http://web.cecs.pdx.edu/~grace/minigrace/js/index.html
>>> is fine.
>>> 
>>> So, I'm not at all sure what is causing this very frustrating problem.  I'm attaching the revised staticTypes.grace file that has been
>>> modified to respond to the error messages on else.  I've made the changes twice and get the same behavior each time.  Essentially it means that I can't do anything about static typing with this version of Grace.
>>> 
>>> I did manage to get the "requiredTypes" dialect to be combined with "objectdrawDialect" so I can now check to make sure the students insert types everywhere in their program.  Finishing that was delayed by some errors in requiredTypes, but even more importantly be the issue that if a print statement is inserted into a dialect (not the program written in the dialect) then the dialect silently dies (much like the experience described above.
>>> 
>>> So, at this point I'm tempted to say if we can't figure out what is wrong here, we should roll back to the previous version (the one currently active at ~grace in Portland) that does not check that arities match.  I'd really like to get the type-checker working properly!!
>>> 
>>> Hope you have a good weekend.
>>> 
>>> Kim
>>> 
>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20140808/0cbe8157/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: staticTypes.grace
Type: application/octet-stream
Size: 39017 bytes
Desc: not available
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20140808/0cbe8157/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20140808/0cbe8157/attachment-0003.html>