[nem-en] Nemerle try catch behaviour

[Snaury]

Hi everyone,

I've been working on bug 695 (http://nemerle.org/bugs/view.php?id=695)
today (forgot to set severity to major back when I reported it, and
now I've changed it to major) and finally got a relatively working
patch. This patch is big, intrusive (changes compiler parsetree and
typetree, though parsetree is left compatible [for now] since
otherwise boot won't compile it) and very experimental so I'd like
someone to review it (because I'm almost sure that due to my lack of
deep understanding of compiler I messed up with several things which
might not surface themselves straight away).

In short, it replaces Try fault/catch/finally node types with single
Try node type which has a body and a list of Try cases (borrowed idea
from how Match cases are organized). This way we can later generate
single exception block with multiple catch blocks.

As an additional feature catch now supports exception filters (i.e.
conditions under which handler should be executed or skipped):

  try {
    // do something
  } catch {
    | e when (e.Message == "some message") => // do something
  }

This is not a full blown match (and I don't think full blown match is
possible here, because variables binding really won't be easy between
exception filter and handler, although..... if we can divide match and
handler still retaining variable bindings in handler context then we
could just br from filter to the endfilter and then reappear in
handler with all the variable bindings... could someone do this?), but
still may be useful for some people in some situations.

There are, however, some problems I can see:

1) Macros. I don't understand it at all how quoted expressions are
parsed. O.o Thus I don't get where expressions like <[ try $body catch
{ $exn is $exn_ty => $handler } ]> are parsed and how. The question
is, due to change in parsetree, if expressions like <[ try $body catch
{.. $cases} finally $fcase ]> would be possible or not? And where a
relevant code should be added for this?

2) Perhaps I was too quick to get rid of TryFinally, because generated
IL for finally clause has one more level of try anyway. The question
is whether we should have Try node for catches only and TryFinally for
finally, or as it is now a single Try node which has both catches and
finallys? (having separate TryFinally actually has benefits, both in
quoted expressions (<[ try $body catch {.. $cases} ]> then won't have
finally case and <[ try $body finally $handler ]> would match
TryFinally only) and in the mess I had to do with yields (detecting
whether we have only one finally, or a finally in-between which is
impossible but still, etc)). So what do you think?

3) I'm sure I messed up with either typing expected type of condition
(hard coding <[ bool ]> is not the way I should go, isn't it?), or
with WalkTry/Walk or with something else. I didn't understand what
these things for, so just tried do it in a similar way. It won't break
existing code, of course, but might allow something wrong in filters
in catch. Could someone check to make sure the proper way for this?

The patch can be downloaded here:

http://snaury.googlepages.com/nemerle-experimental-try-catch-2006-07-29.patch

As well as from attach if it passes thru to you.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nemerle-experimental-try-catch-2006-07-29.patch
Type: application/octet-stream
Size: 46324 bytes
Desc: not available
Url : /mailman/pipermail/devel-en/attachments/20060730/be48a8fc/nemerle-experimental-try-catch-2006-07-29-0001.obj