Are you trying to take a macro argument and ensure that it is an expression? If so, then you can expand into `#%expression`
https://docs.racket-lang.org/reference/__expression.html On the other hand, if you are trying to take a macro argument and ensure that it is NOT an expression... then that means that you know what it is allowed to be, so I don't think there's any better way than to just enumerate what it CAN be. I think I would use a syntax class that specifies the allowable patterns and then use that. For example, in my little teachlog language, I have the `term` syntax class for this purpose https://github.com/jeapostrophe/teachlog/blob/master/main.rkt#L119 Looking at your code, I think what I would do is: 1) Define a phase-1 structure that represents one of these fields and an associated phase-0 function that records its values 2) Define `define-syntax` bindings for each particular field as an instance of these fields 3) Write `update` as a short `syntax-parse` that expects a list where the head is a static instance of the phase-1 structure and expands into an application of the associate phase-0 function on the arguments This would allow you to better abstract things so you don't have tie the `update` function to the particular fields. Jay -- Jay McCarthy Associate Professor @ CS @ UMass Lowell http://jeapostrophe.github.io Vincit qui se vincit. On Wed, Dec 30, 2020 at 10:20 PM Sage Gerard <s...@sagegerard.com> wrote: > I'm trying to learn how to restrict where expressions appear. Those > expressions might be procedure applications, *or* macros before expansion. > > [1] shows a library I use to help me implement a collection pass for a > module language. To save you some reading, it uses syntax-parse with a > lengthy #:datum-literals. That's the only way I know how to restrict what > expressions appear in module context. > > One element of the #:datum-literals happens to share an identifier with a > bound procedure, so I expand the calls as-is in a module-level expression > [2][3]. I want that procedure to be applied ONLY in the module context, but > nothing in the language enforces that. > > I don't know what I don't know. Could I please get a link to a part of the > documentation that teaches me what I need to understand? I'm tied between > querying syntax properties for a fully expanded module, and writing a > second set of macros that somehow know where they should be. Not sure which > is best. > > [1]: https://github.com/zyrolasting/xiden/blob/master/pkgdef/expand.rkt > [2]: > https://github.com/zyrolasting/xiden/blob/master/pkgdef/expand.rkt#L111 > [3]: > https://github.com/zyrolasting/xiden/blob/master/pkgdef/expand.rkt#L156 > > *~slg* > > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/bVbaZ_0mwFcWTIaeuwqMUr7TVY6Rhr5dusG9LkbT0gqW7gWIYAb8IOEUYnKQPIVR2ZrDGm9QMGnW-2YvYqw81oUJVCSCuwhuX_Wx2OGVG-w%3D%40sagegerard.com > <https://groups.google.com/d/msgid/racket-users/bVbaZ_0mwFcWTIaeuwqMUr7TVY6Rhr5dusG9LkbT0gqW7gWIYAb8IOEUYnKQPIVR2ZrDGm9QMGnW-2YvYqw81oUJVCSCuwhuX_Wx2OGVG-w%3D%40sagegerard.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAJYbDa%3DLQhCO8a4F2nnR_DZOMHOGJzLCqOGw6231fT40gF5VxA%40mail.gmail.com.
