Return-Path: <shearer@cs.bu.edu> X-Spam-HitLevel: X-Spam-DCC: : cs3.bu.edu 1049; Body=1 Fuz1=1 Fuz2=1 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on cs3.bu.edu X-Spam-Level: X-Spam-Status: No, score=-1.1 required=10.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL autolearn=no version=3.1.0 X-Spam-Pyzor: Received: from shearershot (c-24-60-255-210.hsd1.ma.comcast.net [24.60.255.210]) by cs3.bu.edu (8.13.6/8.13.6) with ESMTP id k9S3Udig027308 for <cs520@cs.bu.edu>; Fri, 27 Oct 2006 23:30:49 -0400 From: "Rui Shi" <shearer@cs.bu.edu> To: "'Michel Machado'" <michel@digirati.com.br>, <cs520@cs.bu.edu> Subject: RE: Implementation 3 - Details Date: Fri, 27 Oct 2006 23:30:44 -0400 Message-ID: <008a01c6fa41$79db47f0$6400a8c0@csnt.bu.edu> Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <00c701c6f9fa$90402160$60b6a8c0@dark> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb5+pfEV+1tVN7sSiS9upJoCXryogARhVCg X-Clamav-Status: No Status: RO Content-Length: 2865 X-UID: 33 X-Keywords:
-----Original Message-----
From: Michel Machado [mailto:michel@digirati.com.br]
Sent: Friday, October 27, 2006 3:03 PM
To: cs520@cs.bu.edu
Subject: Re: Implementation 3 - Details
Hi Rui,
Since ty-raise gives any type to raise t1, the following two terms
type-check:
1. try 2 with (raise 1) => 3
- This is not syntactically correct, so can't be parsed.
2. raise (raise 1)
- It is ok to make it type-checked. No hurt.
The first doesn't seem to make sense because as far as I understood
"patn" should work as a label, not like a term. If the first term doesn't
make sense, the following shouldn't be possible because a label can't raise
an exception.
Can I assume that those terms that are pointed in ty-raise and ty-try as
exn must be just exn? I mean they can not be of type "any."
[ ]'s
Michel Machado
----- Original Message -----
From: "Rui Shi" <shearer@cs.bu.edu>
To: "'Michel Machado'" <michel@digirati.com.br>; <cs520@cs.bu.edu>
Sent: Monday, October 23, 2006 3:35 PM
Subject: RE: Implementation 3 - Details
>
>
> -----Original Message-----
> From: Michel Machado [mailto:michel@digirati.com.br]
> Sent: Monday, October 23, 2006 1:41 PM
> To: cs520@cs.bu.edu
> Subject: Implementation 3 - Details
>
> Dears,
>
> I have some questions about the implementation 3.
>
> 1. Type stp doesn't have a way to represent "any type". So, what stp
> should be returned by typecheck function to the term "raise 10"? Shoud
> typecheck return TpExn?
>
> - You can come up with a base type like TpBase "Any" to do that.
>
> 2. The rule ty-exn conflits with the following rules from the previous
> assignment: ty-bool, ty-int, ty-unit, ty-var, and the implicitly-defined
> ty-string (it's not listed in the assignment, but it must exist to
> typecheck
> terms like 'print "hello"'). Should I consider that ty-exn has to be used
> only inside typecheck just to typecheck the premises of ty-raise and
> ty-try?
>
> NOTE, ty-exn is indeed needed, when pat is a variable, it's used as a
> label
> in the test file "prodfun.stlc", so, without ty-exn, prodfun.stlc isn't a
> closed term.
>
> - Yes, exception can only be used with raise.
>
> 3. Shouldn't the conclusion of the rule eval-tryExn be "try raise pati
> with ..." rather than "try pati with ..."?
>
> - Yes. Thanks for correcting it.
>
> 4. The rule eval-tryExn assumes that pati (t0) is allways listed in
> with
> clause (cls). However, the rule ty-try does not check that it's true.
> Should
> I just raise pati when it doesn't occur in cls?
>
> - propogate the exception if not being caught.
>
> 5. There's no reference to the operator "mod" in the in the previous
> assignment and the current one, but it's defined in parser.mly and used in
> the test file "perfect.stlc". I assumed it as being int * int -> int.
>
> - Yes.
>
> [ ]'s
> Michel Machado
>
This archive was generated by hypermail 2b29 : Thu Dec 14 2006 - 16:31:59 EST