Closed bradunov closed 9 years ago
I don't think this is a parser bug -- this means sense. If you use in
you are explicitly saying what the let
should scope over; if you want it to scope over both take
s then it makes sense you have to bracket it explicitly. But there is a simple solution: just remove the in
. Now the let
becomes a command as part of the definition of test
and implicitly scopes over the rest of the function definition.
I agree with Edsko here. What we do is consistent with what Haskell does, for instance. We should properly document this though, perhaps with an example.
Oh, yes, sorry, we will transform this into take; take, without assignment, and then it works. And I think there was a different issue here before (as x<-take on its own used to work), but with the new structure and "in" gone, the issue is gone as well. So I agree to close it. Thanks.
Uh, I'm confused. Why is this related to the x <- take
in isolation thing? Your example with just two take
should have the same behaviour.
Sorry, that was a different topic. You can't just write: fun comp f() { x<-take; } Because x is not used afterwards, so x<-take is not a proper computer. But the following is correct: fun comp f() { take; } When I tried compiling the example I realized it failed now because of that change that you did to the parser (it used to work), but we agreed that it is fine (and I think that is what Dimitrios was referring to). Now the original issue is also gone, so if I replace in with ; everything works fine. So there was a double confusion, but it is all gone.
The following code won't compile let comp test() = let f(x:int) = return x in x <- take; y <- take; in Instead, we have to write: let comp test() = let f(x:int) = return x in { x <- take; y <- take; } in which is tedious, and we don't have to do it if we remove let f.