Stream: general

Topic: hygiene-opt-out


Alexander Regueiro (Aug 20 2018 at 23:31, on Zulip):

@Vadim Petrochenkov Hey. Let me know when you're around for a brief chat.

Vadim Petrochenkov (Aug 20 2018 at 23:42, on Zulip):

I'm here.

Vadim Petrochenkov (Aug 20 2018 at 23:44, on Zulip):

If you want some comment regarding https://github.com/rust-lang/rfcs/pull/2498, then I don't know what to say.

Alexander Regueiro (Aug 20 2018 at 23:44, on Zulip):

Hi. So... I was just chatting with @nrc about expanding the proc macro API to allow the creation of hyg_lift and hyg_swap proc macros.

Vadim Petrochenkov (Aug 20 2018 at 23:44, on Zulip):

The comment section looks like a bunch of people talking past each other.

Alexander Regueiro (Aug 20 2018 at 23:45, on Zulip):

Apart from tmcombs coming in from the cold, I don't think so really.

Vadim Petrochenkov (Aug 20 2018 at 23:45, on Zulip):

Proc macro API already provides all possible operations to get and set spans and split them into location and hygiene data.

Alexander Regueiro (Aug 20 2018 at 23:45, on Zulip):

Just @nrc proposed a new approach (different from what I wrote up) and I agreed it made sense

Alexander Regueiro (Aug 20 2018 at 23:45, on Zulip):

I see

Alexander Regueiro (Aug 20 2018 at 23:45, on Zulip):

@nrc Was thinking of a more abstract proc macro API for hygiene but I'm open...

Vadim Petrochenkov (Aug 20 2018 at 23:46, on Zulip):

But that RFC is not about proc macros at all.

Alexander Regueiro (Aug 20 2018 at 23:46, on Zulip):

No, it's not.

Alexander Regueiro (Aug 20 2018 at 23:46, on Zulip):

But the idea is to solve the problem of hygiene opt-out.

Vadim Petrochenkov (Aug 20 2018 at 23:47, on Zulip):

Proc macros can do any operations, but proc-macros are a big gun that shouldn't be pulled on every occasion.

Alexander Regueiro (Aug 20 2018 at 23:47, on Zulip):

And I concur with @nrc that the best way to do it is just to expand the proc macro API

Vadim Petrochenkov (Aug 20 2018 at 23:47, on Zulip):

For proc macros hygiene opt-out is a solved problem, it was just stabilized in the previous release.

Alexander Regueiro (Aug 20 2018 at 23:47, on Zulip):

Hmm... so you prefer the existing approach, more or less?

Alexander Regueiro (Aug 20 2018 at 23:48, on Zulip):

(yes, but I mean using proc macros within declarative macros for the purpose of hygiene opt-out)

Alexander Regueiro (Aug 20 2018 at 23:48, on Zulip):

from the user-perspective they're the same. macros are macros, when you use them.

Vadim Petrochenkov (Aug 20 2018 at 23:48, on Zulip):

Decl macros just need some syntax for it usable in common case so that proc macros are not commonly necessary.

Alexander Regueiro (Aug 20 2018 at 23:49, on Zulip):

but that's what @nrc is saying I guess: why not make use of proc macros for that hygiene opt-out syntax?

Vadim Petrochenkov (Aug 20 2018 at 23:49, on Zulip):

Why?

Vadim Petrochenkov (Aug 20 2018 at 23:49, on Zulip):

To get some horrible macro invocation syntax instead of just #ident?

Alexander Regueiro (Aug 20 2018 at 23:50, on Zulip):

heh

Alexander Regueiro (Aug 20 2018 at 23:50, on Zulip):

I know what you mean... the question is, how common will this be?

Alexander Regueiro (Aug 20 2018 at 23:50, on Zulip):

Also, what about the case when one wants to set the syntax context of one token to that of another token?

Vadim Petrochenkov (Aug 20 2018 at 23:51, on Zulip):

Also, what about the case when one wants to set the syntax context of one token to that of another token?

Proc macros

Alexander Regueiro (Aug 20 2018 at 23:51, on Zulip):

Okay, so you agree to proc macros there...

Alexander Regueiro (Aug 20 2018 at 23:51, on Zulip):

hmm

Alexander Regueiro (Aug 20 2018 at 23:51, on Zulip):

I feel like I'm the man-in-the-middle between you and nrc now, hah.

Alexander Regueiro (Aug 20 2018 at 23:52, on Zulip):

So to be clear... can one already implement opt-out syntax as a proc macro? e.g. lift!(...)?

Alexander Regueiro (Aug 20 2018 at 23:52, on Zulip):

is it possible to get the SyntaxContext of expansions, up the chain?

Vadim Petrochenkov (Aug 20 2018 at 23:53, on Zulip):

Could you describe what lift!(...) does?

Vadim Petrochenkov (Aug 20 2018 at 23:53, on Zulip):

What arguments it takes and what it returns.

Alexander Regueiro (Aug 20 2018 at 23:55, on Zulip):

Just an arbitrary token stream, and it returns the same token stream but with its syntax context changed to that of the the call-site (i.e. outside of the current expansion) relative to where it is used/invoked.

Vadim Petrochenkov (Aug 20 2018 at 23:57, on Zulip):

Yes, sure this can be implemented as a procedural macro.

Vadim Petrochenkov (Aug 20 2018 at 23:58, on Zulip):

Or as a built-in syntactic extension if it needs to live in the standard library.

Vadim Petrochenkov (Aug 21 2018 at 00:01, on Zulip):

I don't think it will be convenient to use in the common case though.

Alexander Regueiro (Aug 21 2018 at 00:01, on Zulip):

Yeah. I mentioned to @nrc that the stdlib approach might be better... is the syntax extension API different to the proc macro API? Is that the "raw" interface to rustc?

Vadim Petrochenkov (Aug 21 2018 at 00:01, on Zulip):

Say, you need to generate a struct visible from outside of the macro struct #S;

Alexander Regueiro (Aug 21 2018 at 00:01, on Zulip):

inconvenient because it's too verbose?

Vadim Petrochenkov (Aug 21 2018 at 00:02, on Zulip):

Then you can't write struct lift!(S); because macro invocations are not allowed in arbitrary identifier positions.

Alexander Regueiro (Aug 21 2018 at 00:02, on Zulip):

They're not allowed in arbitrary identifier positions because it creates parsing difficulties, or what?

Vadim Petrochenkov (Aug 21 2018 at 00:05, on Zulip):

This is an interesting question, but I can't answer it right now.
They certainly make parsing more complex, but I'm not sure how much more complex.

Vadim Petrochenkov (Aug 21 2018 at 00:05, on Zulip):

There was an old RFC about this, IIRC.

Alexander Regueiro (Aug 21 2018 at 00:21, on Zulip):

yeah, looking at it now hmm

Alexander Regueiro (Aug 21 2018 at 00:22, on Zulip):

seems the concerns were mainly about a) macro-names being defined by expansions of other macros, b) readability.

Alexander Regueiro (Aug 21 2018 at 00:22, on Zulip):

I could be mistaken though

Last update: Nov 20 2019 at 12:00UTC