Hello the list, Hello Jonathan (kudos for your great work on programming languages BTW).I'v been using C in the past, mostly python and OCaml nowadays, and yes, the mix of imperative statements (sequences) and functional binding is a bit weird, ugly in exactly the case you describe.
IMHO the ocaml syntax is nice (I needed some time to get used to it, more than switching from C to Python for example, but simple and effective after a while), maybe re-using it while replacing this exact part with something clearer? You may ask on ocaml mailing list or get in touch with the INRIA team on "how the would do it today", I doubt they will be a bunch of zealotic bigots about this issue, I've been thinking about it myself but I'm not profficient enough in caml to come up with enough experiences and a clear idea of a better alternative. There's an issue for ocaml beginners which is solved by using emacs tuareg mode, I should check, but I think that's the problem you describe. Sometime you get a syntax error on the last line of the file, while the human error is on the first half of it. On Thu, Mar 5, 2009 at 3:17 PM, Jonathan S. Shapiro <[email protected]>wrote: > Let me start over. The issue is that the following input to ocaml > produces 3 when it should produce an unbound reference error (x should > be unbound in "x + 2"). > > # let x = 1 in x; let y = x + 2 in y;; > - : int = 3 > > The problem is that the *following* expression is equivalent and > *terribly* confusing: > > # let x = 1 in begin x end; let y = x + 2 in y;; > - : int = 3 > > The desired behavior can apparently be obtained only with begin/end or > parenthesis: > > # (let x = 1 in x); let y = x + 2 in y;; > Unbound value x > > There are many examples even in the ocaml reference manual that are > indented incorrectly w.r.t. the actual binding rules. The sheer number > of these errors in the document strongly argues that scoping forms > should have a syntactic end marker. It might be okay if that turns out > to be indentation, but it needs to be something. > > This is really too bad. It might have been pleasant for BitC to be a > dialect of OCaml. > > shap > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
