On Thu, Mar 5, 2009 at 10:30 AM, Geoffrey Irving <[email protected]> wrote:
> On Thu, Mar 5, 2009 at 6:17 AM, 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
>
> How is this different from C?
The difference is seen in the second case:
# let x = 1 in begin x end; let y = x + 2 in y;;
In EVERY other language I can think of, that begin/end pair would
define the scope of the let, and because of that history, it is
guaranteed to be read that way by humans. Which is why so many
examples in the OCaml reference manual are incorrectly indented. The
authors of the reference manual apparently cannot read their own code.
Which is a pretty good indicator of a weak syntactic choice.
> Most of the constructs involving ";" that one ends up writing in ocaml
> look something like
>
> let x in f(1) in
> let y = g(x) in
> let z = h(y) in
> print_string "blah";
> print_string "another string"
> let w = q(z) in
> ...
Let us please indent things properly in this discussion. The example
you give above is wonderful, because it is illegal anyplace other than
top level. It is only legal at top level and in structures because the
grammar has been hacked (and note that the grammar production for
OCaml structure implementations appears to be wrong -- expressions are
not required after definitions).The fact that a different parse
structure is used for expressions at top level is another good
indicator of flawed syntax.
> It would get annoying very quickly if variables went out of scope as
> soon as you added a semicolor, just like it would in C.
In C, you would rely on curly braces to tell you where the scope
ended, and simultaneously to keep the variables in scope.
What I'm trying to say here is that we should chose one of two
positions on binding constructs:
1. Avoid the keyword LET, because it has traditionally defined an
inner scope that ended at the end of the LET.
2. Alter the syntax of LET to be something like:
let BINDING { and BINDING } in EXPR end
so that the historically expected behavior of LET is respected.
3. Or perhaps both, which is effectively what we are doing with inner
define in BitC right now. The BitC inner define syntax behaves liike
OCamls "scopeless let", but it is not subjectively confusing.
>> 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.
>
> Do any of those examples have actual errors? Having a variable
> syntactically live for slightly longer than one might imagine isn't
> much of a problem in a garbage collected language with no finalizers.
I would say that ALL of them are errors -- and quite serious ones --
because what they seem to say is not consistent with what they do. If
*expert* programmers cannot understand the scoping behavior of their
own work, how can novices?
Keeping variables live can lead to various sorts of undiagnosed
errors, particularly when inner bindings shadow outer bindings. And
your statement about liveness is (unfortunately) incorrect. False
liveness is one of the primary sources of garbage retention, and
consequently a primary source of heap size penalties for garbage
collected languages. Andrew Appel wrote a good paper on this issue.
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
