Hi Chris,
We have discussed match specs a couple times and the tricky part about them
is that different parts of Erlang support a different subsets of match
specs. For example, the tracing specs adds a bunch of tracing related
functions, so the mechanism would need to be extensible.
Implementation wise, we thought about adding a function to the Macro
module, which is where we keep AST related functions:
Macro.to_matchspec(quoted, extra_functions :: [{name, arity}])
A MatchSpec module could be useful but, because every part of OTP uses a
different subset, it may be limited in usage. I would rather see someone
solving the tracing problem and then we could explore smaller functions,
such as Macro.to_matchspec, that we could extract from tracing.
For some ideas on the topic, please also see:
https://github.com/ericmj/ex2ms
*José Valim*
www.plataformatec.com.br
Skype: jv.ptec
Founder and Director of R&D
On Fri, Feb 24, 2017 at 10:37 AM, <[email protected]> wrote:
> Hey all!
>
> Sitting apparently forever in my personal backlog of stuff to do is
> implement defguard
> <https://github.com/elixir-lang/elixir/issues/2469#issuecomment-239637739>
> .
>
> Waaay back in the day
> <https://gist.github.com/christhekeele/8284977/revisions> I actually
> conceptualized this as living in a Guard module. Since then I've
> occasionally advocated adding trivial new modules to the core
> Elixir namespace, even if just for the sake of representing and furnishing
> core types with conversion functions (like Atom
> <https://hexdocs.pm/elixir/Atom.html#content>).
>
> Anyhow, I've been implementing a toy library that demands *really really
> fast* ETS selection. So I've been poking around the ETS functions match
> <http://erlang.org/doc/man/ets.html#match-2> and select
> <http://erlang.org/doc/man/ets.html#select-2>.
>
> Currently Elixir guards are macros that expand Elixir own features and
> abstractions to generate guard clauses compatible with Erlang. However,
> Erlang match_specs <http://erlang.org/doc/apps/erts/match_spec.html> kind
> of introduce their own AST for building guards dynamically. You can use
> this advanced functionality from Elixir, but you have to be pretty
> comfortable with Erlang, and if you want to use an Elixir guard you're
> familiar with, you have to at least check its origins, if not know its
> direct implementation.
>
> So I've been thinking: how might we harmonize with this Erlang concept of
> match specs?
>
> We could introduce an intermediary representation of a guard as a Guard
> module with associated struct, and offer a to_match function. Possibly we
> could hook in another to_definition macro for defguard. Or skip the
> intermediate struct representation of a guard but offer more robust
> capabilities at the macro layer to slice and dice our version of guards in
> different ways, by adding clauses for all known guards and demanding new
> ones furnish that with an entry.
>
> Alternatively/additionally a pretty cool notion would be to introduce a
> whole MatchSpec module with macros capable of converting something more
> Elixir-ish into a proper Erlang MatchSpec, guard input and charlist output
> and all. I'm thinking of Ecto's query DSL, but for matching.
>
> This ties in nicely with Yurko's thought
> <https://groups.google.com/forum/#!topic/elixir-lang-core/SXNog8I-UYw> on
> supporting MatchSpecs within native Elixir features, and begs the question:
> where else might we adopt this or leverage our macros to provide even
> better tooling for this? Any thoughts on this concept?
>
> --
> 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/831757cd-70ae-4386-a4fb-
> 8c2fd9610129%40googlegroups.com
> <https://groups.google.com/d/msgid/elixir-lang-core/831757cd-70ae-4386-a4fb-8c2fd9610129%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/CAGnRm4%2B7L7Y45Zu9%3DTKYvxk18CJ02Js0yQ9gype4Bs_hskmmDA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
