Hey José! https://github.com/ericmj/ex2ms is pretty cool--very much what I had in mind!
Re: the tracing problem, as far as I'm aware there are only two match_spec contexts--ETS, and tracing (a superset of ETS). In my mind this could be obviated by an additional optional `context` parameter, supporting differentiation of the tracing context but defaulting to whatever the most common accepted representation of a match_spec is. That is, rather than see someone solving the tracing problem and then we could explore smaller > functions I was thinking we might explore the smaller functions and extend support to additional options with a context argument, empty by default. This would allow creation of a MatchSpec module sooner that would probably delegate heavy lifting to Macro much as Macro.pipe does. Learn You Some Erlang decides to introduce <http://learnyousomeerlang.com/ets> parse transforms just to address the pseudo-AST of MatchSpecs in ETS, so I feel as if this is an opportunity for our macros to shine. But it's a hard call to decide how such a convenience would work--quite beyond my experience with MatchSpecs to date, and that's before addressing the discrepancy between Elixir and Erlang guards in such a format. Thanks for filling me in on previous discussion! Cheers, Chris On Friday, February 24, 2017 at 2:24:16 AM UTC-8, José Valim wrote: > > 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] <javascript:>> > 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] <javascript:>. >> 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/46e696d9-61d3-490c-ac3f-dc294971e177%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
