This proposal would also allow an expansion of `defguard` to cover my previous recommended functionality to it as well.
On Monday, September 24, 2018 at 2:32:47 PM UTC-6, Louis Pilfold wrote: > > Hey > > > is there a good reason *not* to expand the expressivity of guard > clauses in the core of the language beyond that which erlang offers? > > I've no strong opinion on the proposal, but I'd just like to point out > that expressivity has a formal CS definition and implementing this > proposal will not increase the expressive power of guard clauses as they > will not be capable of any functionality they did not have before. > > This is a matter of style and syntax. > > Cheers, > Louis > > On Mon, 24 Sep 2018 at 21:13 Christopher Keele <[email protected] > <javascript:>> wrote: > >> > *If the goal were primarily macro usage, wouldn't this type of thing >> already be possible with a macro today?* >> >> > *Macros are more than capable of providing this functionality, you'd >> just need to define your own `def` like macro that generates the desired >> function.* >> >> This is absolutely true, and expat does something similar today. It could >> be done easier and better in core, of course. I think the heart of the >> proposal is: given that this is straightforwardly possible today, and the >> implementation identical and completely deterministic no matter the >> application, is there a good reason *not* to expand the expressivity of >> guard clauses in the core of the language beyond that which erlang offers? >> >> The macro-authors-over-common-coding argument is me simply saying, let's >> consider this from the perspective of increasing the language's >> extensibility first, since I suspect the discussion around whether or not >> it makes day-to-day coding more productive to be far more opinion-oriented. >> >> I am not sold on the idea myself, which is why I dug into the >> implementation a bit so I could present it better. It absolutely could be >> done via macro, but I think it exists at an interesting low-hanging fruit, >> low-risk way to make the language itself more powerful today. >> >> > *IIRC, macros do not allow to abstract both the pattern match and the >> guard within the same expression.* >> >> You do a better job of summarizing how this could be used in core today >> than I did. I am not sure how common the use-case is either, but I do have >> one concrete example in expat and I wonder what might embraced in the >> future if this purely historical grammatical restriction were lifted. >> >> -- >> 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] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/9e9be43d-b772-480c-afe9-bb07a7e01119%40googlegroups.com >> >> <https://groups.google.com/d/msgid/elixir-lang-core/9e9be43d-b772-480c-afe9-bb07a7e01119%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- 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/013d7e04-1227-47ee-a4fc-e61c57a1adbd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
