Conversation
| } | ||
| implicit class ArrayOps[A: Manifest](x: Rep[Array[A]]) { | ||
| def apply(i: Rep[Int]): Rep[A] = | ||
| x match { |
There was a problem hiding this comment.
prefer the old format
There was a problem hiding this comment.
do you mean x match { should be on the same line of def ...?
There was a problem hiding this comment.
yeah, I tried to fix it myself but didn't got too much time to read the documentation for formatting
There was a problem hiding this comment.
I agree - the x match { should be on the same line
feiwang3311
left a comment
There was a problem hiding this comment.
LGTM (or rather, Idk how to fight the formatter, so I surrender)
Whatever formatting is fine with me :)
There was a problem hiding this comment.
Uniformity is good, and it's good to try automatic tools that enforce it.
With the results right now there is too much "de-densification" for my taste, e.g. code broken across many lines where it doesn't need to, which I think makes it harder to read, not easier. But I'm pretty sure that can be fixed.
Another question is if we really want to depend on another external tool (need to keep track of versions, etc). Are the benefits worth it?
| def copyToLongArray(arr: Rep[LongArray[A]], start: Rep[Long], len: Rep[Int]) = | ||
| Adapter.g.reflectEffect("array_copyTo", Unwrap(x), Unwrap(arr), Unwrap(start), Unwrap(len))(Unwrap(x))( | ||
| Unwrap(arr) | ||
| ) |
There was a problem hiding this comment.
These formatting changes also don't seem like improvements to me. It may be worth looking at refactoring the code for clarity, but just putting the last Unwrap(...) on another line make it more difficult to read IMO.
| Adapter.g.Def("list-new", mA :: (xs: List[Backend.Exp])), | ||
| Adapter.g.Def("list-new", _ :: (ys: List[Backend.Exp])) | ||
| ) => | ||
| val unwrapped_xsys = Seq(mA) ++ xs ++ ys |
This PR proposes to adopt a unified coding style and to use
scalafmtto format the code. When running insbt, you can uselms-clean/scalafmtto automatically reformat all source code files.However, this PR is by no means enforcing a style we eventually should use, but just initiating such effort. There are tons of config options (https://scalameta.org/scalafmt/docs/configuration.html) we can tweak to find a style that everyone is comfortable with.