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 <[email protected]> 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 [email protected]. > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAJYbDa%3DLQhCO8a4F2nnR_DZOMHOGJzLCqOGw6231fT40gF5VxA%40mail.gmail.com.
