dimitriv / Ziria

A domain-specific-language and compiler for low-level bitstream processing.
92 stars 18 forks source link

Parsing error #39

Closed bradunov closed 9 years ago

bradunov commented 9 years ago

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.

edsko commented 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 takes 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.

dimitriv commented 9 years ago

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.

bradunov commented 9 years ago

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.

edsko commented 9 years ago

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.

bradunov commented 9 years ago

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.