On Tue, May 19, 2015 at 10:26 PM, Jonathan S. Shapiro <s...@eros-os.org> wrote: > On Mon, May 18, 2015 at 9:52 AM, Keean Schupke <ke...@fry-it.com> wrote: >> >> >> On 18 May 2015 17:07, "Jonathan S. Shapiro" <s...@eros-os.org> wrote: >> > >> > On Sun, May 3, 2015 at 7:36 AM, Keean Schupke <ke...@fry-it.com> wrote: >> >> >> >> To clarify I am suggesting a single, multi equals let as the way it >> >> should be done, not necessarily the way other people do it. >> > >> > Clear, but not what we are going to do. >> >> Then I would vote for no lets at the top level at all. > > > Right. I think I said that elsewhere already. Top-level forms don't enclose > a scope, so they shouldn't overload the LET keyword.
Egads, I think I finally understand what you mean by top-level let now e.g. In the following code there is a top-level let which is never closed by a subsequent 'in', static let moduleInstance = new 'PriorityQueueModule () and thus the let remain open throughout the top-level scope https://github.com/jack-pappas/experimental-functors/blob/master/PriorityQueues/Functors.fs I'm not very fond of this, to try and restate my opinion above (in the idea that i'm not fundamentally opposed to multi-let statements: let x = 0 let y = 1 in (x, y) // fine by me... let x = 0 let y = x + 1 // evil! in (x,y) let x = 0 let y = x + 1 // I don't understand why this would be chosen over multi-equals let, but I guess? in (x,y) The F# stuff, seems to me to be breaking a very fundamental idea that things which depend on the sequentially constructed computations above them should be indented to the right as well so when I see something to the effect of: let x = 0 static member foo() x + 1 I think the indentation scheme is all messed up, and it'd be better to consider let DECL of DECL end let DECL in EXPR end before I ever start considering an 'open let' _______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
