On Wednesday, September 27, 2017 at 10:44:41 AM UTC-6, José Valim wrote: > > First of all, because that macro will return true and false at compile > time, which is not what we want. :) >
Er, yes, I forgot to add the `quote`, which a wrapper macro with a stored variable (since called twice) (perhaps call this macro `defguard`? ^.^) could just do implicitly (like the current proposal into 1.6 is doing). ^.^ On Wednesday, September 27, 2017 at 10:44:41 AM UTC-6, José Valim wrote: > The code above unquotes the value twice, which means that when used > outside of a guard, such as in "if is_even(some_expr())", some_expr is > evaluated twice. One option would be to use bind_quoted or similar but keep > in mind we can't define variables inside guards so we need to account for > both cases. The final solution would look like this: > Eyup, it is indeed quite a pain, but a simple macro that creates that macro can handle all that pain for you, which is basically what the current 1.6.0 proposal already does. On Wednesday, September 27, 2017 at 10:44:41 AM UTC-6, José Valim wrote: > Which is quite complex compared to: > Entirely so, which is why it should not be done. However my style handles this *and* adds structural matching abilities, rather than just being a simple, say, library function that adds a `defguard` macro that just does that wrapping for you that you specified (which already exists somewhere I ran across once). Specifically though, I want to structurally match far *far* more often than I add guards to functions (I often design just for this as pattern matching executes faster than guards do) and thus defguard becomes even more useless. It still cannot even define something as fairly trivially simple as an `is_struct/1`/`is_struct/2`. Though yes, I do conceed that defining these structural matches has a more front-end one-time cost (via PR) in that you have to add loaders to various syntax constructs in addition to potentially having to duplicate bodies into different heads (as heads may need to be duplicated at times since you cannot match an 'or' of structures), but that is all still only a one-time cost to be able to define new guards that are *significantly* more powerful than what a comparatively simple macro could do, thus allowing you to make things like `is_struct/1`/`is_struct/2` or `is_exception/...` and others, including for very specific internal information that a library may want to expose a guard for that the current 1.6.0 proposal is entirely incapable of. -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/5dc425ae-34cc-4b0b-8697-b375f8b5c52b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
