Return-Path: <michel@digirati.com.br> X-Spam-HitLevel: X-Spam-DCC: sonic.net: cs3.bu.edu 1117; 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=-2.6 required=10.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Pyzor: Received: from nobelio.k8.com.br (nobelio.k8.com.br [200.185.109.96]) by cs3.bu.edu (8.13.6/8.13.6) with ESMTP id k9RJ3KJk021305 for <cs520@cs.bu.edu>; Fri, 27 Oct 2006 15:03:31 -0400 Received: from localhost (localhost [127.0.0.1]) by smtpa.k8.com.br (Postfix) with ESMTP id 3F38B5000253 for <cs520@cs.bu.edu>; Fri, 27 Oct 2006 16:03:16 -0300 (BRT) Received: from smtpa.k8.com.br ([127.0.0.1]) by localhost (nobelio.k8.com.br [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15787-01-52 for <cs520@cs.bu.edu>; Fri, 27 Oct 2006 16:03:16 -0300 (BRT) Received: from dark (c-71-232-158-11.hsd1.ma.comcast.net [71.232.158.11]) by smtpa.k8.com.br (Postfix) with ESMTP id 86762500016E for <cs520@cs.bu.edu>; Fri, 27 Oct 2006 16:03:15 -0300 (BRT) Message-ID: <00c701c6f9fa$90402160$60b6a8c0@dark> From: "Michel Machado" <michel@digirati.com.br> To: <cs520@cs.bu.edu> References: <003f01c6f6da$603c5d30$f0f7000a@csnt.bu.edu> Subject: Re: Implementation 3 - Details Date: Fri, 27 Oct 2006 15:03:13 -0400 Organization: Digirati Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Clamav-Status: No Status: RO Content-Length: 2576 X-UID: 32 X-Keywords:
Hi Rui,
Since ty-raise gives any type to raise t1, the following two terms
type-check:
1. try 2 with (raise 1) => 3
2. raise (raise 1)
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