std: remove deprecation for macros.callsite

[saem]

Summary

macros.callsite was marked deprecated and is no longer deprecated, because it's still very useful.

Details

It was initially thought that the main use case for macros.callsite was fetching arbitrary arguments to a macro call. That use case was taken over by varargs[untyped], but this is obvious short sighted. The routine still has utility and is no longer marked deprecated.

---

Notes for Reviewers

• came up in a discussion in matrix chat with Robyn (link)

[zerbina]

Hm, besides fetching the source location information of the macro invocation (which I agree is useful), what's a practical use case for callsite?

One language-level problem I see with callsite is that it encourages writing macros that are dependent on their invocation syntax, which is something I think macros should not be. Implementation wise, the feature doesn't add significant complexity, as the AST returned by callsite is currently typed (it originally wasn't, if I remember correctly).

In any case, varargs[untyped] is most definitely not a replacement for callsite, and at the very least, the deprecation message is wrong. Personally, I think callsite should only return a node capturing the invocation's source location information.

[saem]

Hm, besides fetching the source location information of the macro invocation (which I agree is useful), what's a practical use case for callsite?

That is a big part of the utility, imo.

Implementation wise, the feature doesn't add significant complexity, as the AST returned by callsite is currently typed (it originally wasn't, if I remember correctly).

I'd have to look at it again but returning the typed variety might be the right thing to do as it happens after the overload has been resolved, so witnessing that makes sense.

One language-level problem I see with callsite is that it encourages writing macros that are dependent on their invocation syntax, which is something I think macros should not be.

In my mind, that's the thing with macros, they work on syntax, so their sensitivity to forms of expression is a feature not necessarily a bug, such as a DSL where on wants to ensure that prefix call notation is only used for calls, and dot notation for field access. Much of the transform level facilities could be taken over by the dot operator overloading experimental feature, however.

In any case, varargs[untyped] is most definitely not a replacement for callsite, and at the very least, the deprecation message is wrong. Personally, I think callsite should only return a node capturing the invocation's source location information.

That might suit the name better, as the reading could well be, "tell me the source location of the callsite", as opposed to, "give me the shape of the call at the callsite".

---

Maybe the better thing to do is make dot operator no longer experimental, and then change callsite to return an nkEmpty with line info set (or just the line info itself)?

[zerbina]

That is a big part of the utility, imo.

Yep, I know, but I'm not sure what callsite is really useful for besides, hence the question.

In my mind, that's the thing with macros, they work on syntax, so their sensitivity to forms of expression is a feature not necessarily a bug, such as a DSL where on wants to ensure that prefix call notation is only used for calls, and dot notation for field access.

No no, I very much agree that macros should be to differentiate between call forms. What I meant is something else: the various call syntax (command form, prefix form, string call, etc.) are generally said to not affect semantics, being purely syntactic information. With current-day callsite a macro can inspect how it's invoked, e.g., the macro could distinguish whether it's invoked via prefix or via command call syntax.

Macros don't have to do so, of course, but the ability being there does encourage this somewhat. To reiterate, nothing regarding syntax form sensitivity for macro arguments should change, I just don't think this sensitivity should extend to the macro invocation itself (like it is possible now, via callsite).

Maybe the better thing to do is make dot operator no longer experimental, and then change callsite to return an nkEmpty with line info set (or just the line info itself)?

That sounds good to me.