Return-Path: <shearer@cs.bu.edu> X-Spam-HitLevel: X-Spam-DCC: CTc-dcc2: cs3.bu.edu 1031; 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=-4.4 required=10.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Pyzor: Received: from csa2.bu.edu (csa2 [128.197.12.4]) by cs3.bu.edu (8.13.6/8.13.6) with ESMTP id kA54LS0G007982; Sat, 4 Nov 2006 23:21:28 -0500 Received: from localhost (shearer@localhost) by csa2.bu.edu (8.13.6/8.12.11/Submit) with ESMTP id kA54LSbf014306; Sat, 4 Nov 2006 23:21:28 -0500 Date: Sat, 4 Nov 2006 23:21:28 -0500 (EST) From: Rui Shi <shearer@cs.bu.edu> To: Michel Machado <michel@digirati.com.br> cc: cs520@cs.bu.edu Subject: Re: Implementation 3 - Details In-Reply-To: <029701c70047$eca71780$c0b6a8c0@dark> Message-ID: <Pine.LNX.4.58.0611042320260.13970@csa2.bu.edu> References: <008a01c6fa41$79db47f0$6400a8c0@csnt.bu.edu> <029701c70047$eca71780$c0b6a8c0@dark> Content-Type: TEXT/PLAIN; charset=US-ASCII X-Clamav-Status: No Status: RO Content-Length: 4139 X-UID: 44 X-Keywords:
On Sat, 4 Nov 2006, Michel Machado wrote:
> Hi Rui,
>
> > 1. try 2 with (raise 1) => 3
> >
> > - This is not syntactically correct, so can't be parsed.
>
> That term is syntactically correct according to the parser, it produces
> the following output:
>
> TtmTry (
> TtmInt 2,
> [
> TtmRaise (TtmInt 1")
> =>
> TtmInt 3,
> ])
>
> The non-terminal clause that's listed in parser.mly has the following
> form:
>
> clause :
> | term DARROW term { ($1, $3) }
>
> Currently, my code doesn't type check that term, is it ok? Are you going
> to change the parser?
What you are doing is ok.
>
> [ ]'s
> Michel Machado
>
> ----- Original Message -----
> From: "Rui Shi" <shearer@cs.bu.edu>
> To: "'Michel Machado'" <michel@digirati.com.br>; <cs520@cs.bu.edu>
> Sent: Friday, October 27, 2006 10:30 PM
> Subject: RE: Implementation 3 - Details
>
>
> >
> >
> > -----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