-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: macros as variable declaration pragmas #6696
Comments
And for types as well! =) Question is to which AST macros should be applied though? let bar {.foo.} = 123 Might be transformed to foo(let bar = 123) or let foo(bar) = 123 or smth else? The first variant looks more useful and allows crazier things. However, what if the let section has more decls? let
bar {.foo.} = 123
buz = 456 Should the let section be split now to the following? foo(let bar = 123)
let buz = 456 |
Would also like this for Type declarations like: import macros
macro myMagicTypeMacro(ast: untyped): untyped =
result = ast
type MyMagicType {.myMagicTypeMacro.} = object of RootObj
foo: int |
In the case of Flatbuffers (and Capnproto, any serializer, etc) this would let you place format-specific tags on an object and avoid needing to take over the entire type section. import macros
macro sporg(unused: untyped): untyped =
discard
type
thingdo = object
foo {.sporg: true.}: int # something like this should work, as it does in C# (and Go, kind of)
macro cocainum(x: typedesc): untyped =
let t = gettypeimpl(gettype(x)[1])
echo lisprepr t
cocainum(thingdo) |
@Skrylar I tried to re-read your comment a few times but I could not parse it :-( |
@andreaferretti he meant that now we can apply macro to type in this way:
and this feature will allow to add per-type pragmas right to the type definitions |
We have these now in the form of custom pragmas, which I have (locally) tested and you can use them for ORMs/automatic serialization code. The API to use custom pragmas is a slight bit painful, but I'm not sure this ticket needs to be open anymore? |
This is now implemented, but without arguments like |
the new design is being discussed here: nim-lang/RFCs#220, TLDR the syntax will likely change from (lhs,typ,rhs) params to a single AST param |
fix nim-lang#15920, close nim-lang#18212, close nim-lang#14781, close nim-lang#6696, close nim-lang/RFCs#220 Variable macro pragmas have been changed to only take a unary section node. They can now also be applied in sections with multiple variables, as well as `const` sections. They also accept arguments. Templates now support macro pragmas, mirroring other routine types. Type and variable macro pragmas have been made experimental. Symbols without parentheses instatiating nullary macros or templates has also been documented in the experimental manual. A check for a redefinition error based on the left hand side of variable definitions when using variable macro pragmas was disabled. This nerfs `byaddr` specifically, however this has been documented as a consequence of the experimental features `byaddr` uses. Given how simple these changes are I'm worried if I'm missing something.
* New/better macro pragmas, make some experimental fix #15920, close #18212, close #14781, close #6696, close nim-lang/RFCs#220 Variable macro pragmas have been changed to only take a unary section node. They can now also be applied in sections with multiple variables, as well as `const` sections. They also accept arguments. Templates now support macro pragmas, mirroring other routine types. Type and variable macro pragmas have been made experimental. Symbols without parentheses instatiating nullary macros or templates has also been documented in the experimental manual. A check for a redefinition error based on the left hand side of variable definitions when using variable macro pragmas was disabled. This nerfs `byaddr` specifically, however this has been documented as a consequence of the experimental features `byaddr` uses. Given how simple these changes are I'm worried if I'm missing something. * accomodate compiler boot * allow weird pragmas * add test for #10994 * remove some control flow, try remove some logic
* New/better macro pragmas, make some experimental fix nim-lang#15920, close nim-lang#18212, close nim-lang#14781, close nim-lang#6696, close nim-lang/RFCs#220 Variable macro pragmas have been changed to only take a unary section node. They can now also be applied in sections with multiple variables, as well as `const` sections. They also accept arguments. Templates now support macro pragmas, mirroring other routine types. Type and variable macro pragmas have been made experimental. Symbols without parentheses instatiating nullary macros or templates has also been documented in the experimental manual. A check for a redefinition error based on the left hand side of variable definitions when using variable macro pragmas was disabled. This nerfs `byaddr` specifically, however this has been documented as a consequence of the experimental features `byaddr` uses. Given how simple these changes are I'm worried if I'm missing something. * accomodate compiler boot * allow weird pragmas * add test for nim-lang#10994 * remove some control flow, try remove some logic
Forum thread link.
Example:
Being to do this with a user-defined macro
The text was updated successfully, but these errors were encountered: