-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New quasiquote implementation #182
Conversation
…fixing # Conflicts: # shared/src/main/scala/mlscript/codegen/Scope.scala # shared/src/test/diff/nu/ArrayProg.mls # shared/src/test/diff/nu/FlatMonads.mls # shared/src/test/diff/nu/MissingTypeArg.mls
It is just because a fun foo =
let x = ...
mut let y = ... // ok, because both `let`s are statements. To write fun foo =
`let x = `1 in
mut let v = x
`let x = `true
x
//│ fun foo: Code[true, nothing] Similar reasons for the second case. I just fixed the pretty-printing of qq. |
It is probably related to the let foo =
let r = Ref(`0)
x `=> ((set r.value = x), `0), r.value
//│ let foo: Code[0, nothing]
let foo =
mut let r = `0
x `=> ((set r = x), `0), r
//│ let foo: Code[0, nothing] | Var['a, in ??x out ??x0]
:e
run(foo)
//│ ╔══[ERROR] Type error in application
//│ ║ l.121: run(foo)
//│ ║ ^^^^^^^^
//│ ╟── type variable `?x` leaks out of its scope
//│ ╟── into type `nothing`
//│ ╟── adding a type annotation to any of the following terms may help resolve the problem
//│ ╟── • this definition:
//│ ║ l.116: mut let r = `0
//│ ╙── ^^^^^^
//│ 0 | error |
Ok but there's no reason that this should be the case. We should be able to write the code I wrote above. And we should not get the really weird and broken parse shown in one of my example, where the let rhs somehow includes the next lines in the current block. |
At, that's probably an instance of unsound distributivity (which shouldn't be used in the presence of mutation). Can you try with |
Seems the same: :DontDistributeForalls
class Ref[A](init: A) { mut val value: A = init }
//│ class Ref[A](init: A) {
//│ val value: A
//│ }
let foo =
let r = Ref(`0)
x `=> ((set r.value = x), `0), r.value
//│ let foo: Code[0, nothing]
let foo =
mut let r = `0
x `=> ((set r = x), `0), r
//│ let foo: Code[0, nothing] | Var['a, in ??x out ??x0] |
I suggest that we force requiring an |
It does to me. Look, you can always convert let x = a in
log(x)
x to let x = a
log(x)
x Why couldn't one convert `let x = a in
`log`(x)
x to `let x = a
`log`(x)
x using the exact same logic?
Anyway, for now I'd be fine with the kludge of forcing In any case, the parser should be fixed so the RHS of a let binding doesn't parse past the newline. |
The first two cases are not equivalent. Notice that in the first case :NewDefs
let a = 42
//│ let a: 42
//│ a
//│ = 42
let x = a in // * expression
log(x)
x
//│ 42
//│ res
//│ = 42
//│ // Output
//│ 42
:e
x
//│ ╔══[ERROR] identifier not found: x
//│ ║ l.18: x
//│ ╙── ^
//│ error
//│ Code generation encountered an error:
//│ unresolved symbol x
let x = a // * statement
log(x)
x
//│ let x: 42
//│ 42
//│ x
//│ = 42
//│ res
//│ = undefined
//│ // Output
//│ 42
//│ res
//│ = 42
x
//│ 42
//│ res
//│ = 42
case ModifierSet(mods, (KEYWORD(kwStr @ ("fun" | "val" | "let")), l0) :: c) => That's why I said The third case works and just warns that
Yes |
You're saying it "doesn't make sense" from the implementation perspective. You have to take a step back and consider the high-level semantic perspective. It makes perfect sense for users to write this code.
Why would you say that? I do care to write the code I provided above. It happened when I was actually trying to write a real example. Why do you say you don't care about that? It's kind of rude TBH.
Unit, not nothing... |
They ARE equivalent. I don't care whether things are statements or expressions under the hood. I just care about user-facing syntax and semantics. And you should too. |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Otherwise LGTM, finally! Thanks for pushing this through until it reached the expected quality standard.
I'll make the merge when you finish addressing the comments.
Co-authored-by: Lionel Parreaux <[email protected]>
Co-authored-by: Lionel Parreaux <[email protected]>
Co-authored-by: Lionel Parreaux <[email protected]>
Co-authored-by: Lionel Parreaux <[email protected]>
Adapted from #164.