4 ms·

It might be a small thing, but I am most excited about @defguard. I find that splitting a function to match on different inputs and using guards creates elegant

It might be a small thing, but I am most excited about @defguard. I find that splitting a function to match on different inputs and using guards creates elegant, clear, and maintainable code, but if a guard statement is too large, that effect is diminished and I fall back to `if` or `case`. @defguard allows me to stick to the more elegant (in my opinion) solution.

davidkuhta 9y ago
For those interested in some of the thought-process of defguard check out Chris Peele's gist of his development process: https://gist.github.com/christhekeele/76c3e37cb9082274f52f79fa94bab6fe https://gist.github.com/christhekeele/76c3e37cb9082274f52f79... While not the final spec per his PR, a really good look at the internals nonetheless.
- christhekeele 9y ago
  You can follow my development even further—the lingering question in that gist is how to expand the guard code to see if it is valid in a guard. I tried my hand at a pure-Elixir guard expansion in an earlier PR, documenting my thoughts as I went: https://github.com/elixir-lang/elixir/pull/5854 https://github.com/elixir-lang/elixir/pull/5854 After José gave me some direction in response to that, I produced the ultimate PR: https://github.com/elixir-lang/elixir/pull/5857 https://github.com/elixir-lang/elixir/pull/5857 It simply relies on calling the :elixir_expand.expand function that the compiler uses, with a guard context—so the defguard implementation is always up-to-date with what the compiler allows in guards. Waaay more elegant than munging AST myself. Funnily enough, the tests I wrote for defguard actually uncovered some missing assertions in that function. Some invalid expressions would make it past that step and return a different error much deeper in. It's kinda cool I indirectly contributed to the compiler. I took on the feature mostly because over 4 years ago I'd made a gist to do exactly that, minus the validation, and when I found the issue on github for it, it gave me a lot of pleasant closure to get it merged in! https://gist.github.com/christhekeele/8284977/revisions#diff-ba11d4e6b23e5ea4fc590c7da3988661R65 https://gist.github.com/christhekeele/8284977/revisions#diff...
qaq 9y ago
+1 very welcome addition for exactly the reasons you have outlined.

davidkuhta 9y ago

For those interested in some of the thought-process of defguard check out Chris Peele's gist of his development process: https://gist.github.com/christhekeele/76c3e37cb9082274f52f79fa94bab6fe https://gist.github.com/christhekeele/76c3e37cb9082274f52f79... While not the final spec per his PR, a really good look at the internals nonetheless.

christhekeele 9y ago
You can follow my development even further—the lingering question in that gist is how to expand the guard code to see if it is valid in a guard. I tried my hand at a pure-Elixir guard expansion in an earlier PR, documenting my thoughts as I went: https://github.com/elixir-lang/elixir/pull/5854 https://github.com/elixir-lang/elixir/pull/5854 After José gave me some direction in response to that, I produced the ultimate PR: https://github.com/elixir-lang/elixir/pull/5857 https://github.com/elixir-lang/elixir/pull/5857 It simply relies on calling the :elixir_expand.expand function that the compiler uses, with a guard context—so the defguard implementation is always up-to-date with what the compiler allows in guards. Waaay more elegant than munging AST myself. Funnily enough, the tests I wrote for defguard actually uncovered some missing assertions in that function. Some invalid expressions would make it past that step and return a different error much deeper in. It's kinda cool I indirectly contributed to the compiler. I took on the feature mostly because over 4 years ago I'd made a gist to do exactly that, minus the validation, and when I found the issue on github for it, it gave me a lot of pleasant closure to get it merged in! https://gist.github.com/christhekeele/8284977/revisions#diff-ba11d4e6b23e5ea4fc590c7da3988661R65 https://gist.github.com/christhekeele/8284977/revisions#diff...

qaq 9y ago

+1 very welcome addition for exactly the reasons you have outlined.