Jochen
December 21, 2023, 10:50am
1
Hi, I read about @type in macros in the docs, and found @def in the code, but are there any other variables available?
I’m preparing a pull request to update the docs, if there are any others that should be added it would be nice to know about them.
3 Likes
That’s great, thanks for picking this up
There’s also @top_level which refers to the Program i.e. the top level scope.
There’s an additional var, @caller coming in (Expose macro `Call` context via new `@caller` macro ivar by Blacksmoke16 · Pull Request #14048 · crystal-lang/crystal · GitHub ) and it already has a docs PR: Document new `@caller` macro ivar by Blacksmoke16 · Pull Request #724 · crystal-lang/crystal-book · GitHub
1 Like
And please note that the semantics of @type are a bit… wanky . This may need refinement.
opened 05:31PM - 06 Dec 23 UTC
kind:bug
status:discussion
topic:lang:macros
tough-cookie
The [documentation for `@type`](https://crystal-lang.org/reference/1.10/syntax_a… nd_semantics/macros/index.html#type-information) reads:
> When a macro is invoked you can access the current scope, or type, with a special instance variable: `@type`. [...]
> Note that `@type` is always the *instance* type, even when the macro is invoked in a class method.
This is a bit unspecific about what "current scope" actually means. It could be the scope where the macro is defined or the caller scope.
The note about the instance type seems to point towards the latter, though because it doesn't seem to make sense for the macro scope.
The attached example also shows "current scope" as the caller's scope. However, this was added at a later point (in https://github.com/crystal-lang/crystal-book/pull/153) and just documents the actual behaviour, not necessarily the original intention.
This is quite different from `@type` in a [macro method](https://crystal-lang.org/reference/1.10/syntax_and_semantics/macros/macro_methods.html) (a `def` with `{% @type %}`) which refers to the def's scope.
Either way, the actual behaviour is quite surprising. The caller scope semantics seems to apply only in macros defined in the top-level scope. Otherwise `@type` actually refers to the macro's scope!
In the following example, the caller's scope would be `<Program>` and `C`, respectively. But `@type` in `M.foo` is always `M`.
```cr
module M
macro foo
{% p @type %}
end
end
macro bar
{% p @type %}
end
bar # => <Program>
M.foo # => M
class C
bar # => C
M.foo # => M
end
```
This seems pretty wrong. The semantics of `@type` should not depend on whether the macro is defined in the top-level scope or not.
However, it's not immediately clear which semantics are actually intended / "correct". The documentation seems to indicate the caller's scope, but that contradics with `@type` in macro methods. It's quite disturbing for the same feature to swap semantics depending on context.
A related discussion is the introduction of the `@caller` meta var (#14048). It references a macro's caller. A reference to the caller's scope could be well integrated for example as `@caller_scope`, `@caller.@scope` or the like (IMO `scope` fits better than `type` and clearly distinguishes from `@type`.
So I think I would tend to prefer `@type` to mean the macro's scope as the ideal semantics, exactly like in macro methods.
But it's not trivial to resolve this to a congruent state either way because it may break existing code depending on one semantic or the other.
Jochen
December 23, 2023, 1:02am
4
Well, it seems to magically have resolved itself
