Re: [elixir-core:8323] [Proposal] Allow guards to be interspersed anywhere in clause heads

2018-09-24 Thread Louis Pilfold
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 
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 elixir-lang-core+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/9e9be43d-b772-480c-afe9-bb07a7e01119%40googlegroups.com
> 
> .
> 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 elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/CABu8xFDw%2B30jQ%2BhfsLS7OxXSFf3gT7XSxBZr-qGuBC6_kY-Tww%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [elixir-core:8323] [Proposal] Allow guards to be interspersed anywhere in clause heads

2018-09-24 Thread Christopher Keele
 > *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 elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/9e9be43d-b772-480c-afe9-bb07a7e01119%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.