freenode/#clasp - IRC Chatlog
Search
10:44:25
makomo
beach: seems like i can't go with the macroexpansion solution after all, because i might have multiple :process blocks, each of which use <-. since the order of macroexpansion isn't defined, i wouldn't know which <- is being expanded and which process to associate it with
10:45:26
beach
You can create an environment to work with: (asdf:load-system :sicl-minimal-extrinsic-environment) and then:...
12:51:33
pfdietz
makomo: your macro functions are accessing some sort of global state, so order of macroexpansion is important?
12:52:33
makomo
pfdietz: yeah, pretty much. the "<-" macro would associate the given signal with the *current* process (that's the global state)
12:53:23
makomo
that might not mean anything to you, but in short -- my macro can take multiple processes (which are bodies of code that contain the <- macro)
12:54:54
makomo
it's supposed to arrange for these process bodies to be compiled (by creating functions out of them via LAMBDA) and therefore the <- macro to be expanded within them
12:55:31
pfdietz
In general, you don't want macros to access (or modify) global state. If you want to pass information down into a macro from surrounding lexical scope, it's best to use that weird &environment parameter, with surrounding forms populating it with fake macrolets whose purpose is not to be expanded into code, but to be queried by other macro functions.
12:58:47
Bike
if a <- is part of one process and that's obvious from source code you can probably have each <- be aware of its process that way, tho.
13:03:30
pfdietz
Passing information back up is harder. Probably the best way would be for the macro for <- to fully (or mostly) expand forms under it, then grovel over those expansions for information. Fully expanding all macros requires a code walker though.
13:04:11
makomo
Bike: multiple processes might use <- (if i correctly understood what your assumption was)
13:06:14
makomo
Bike: oh, nope. every <- appears *within* a process and is associated exactly with that process only
13:11:15
makomo
Bike: this is in regard to the "passing information down" technique, right? so, as suggested, i could wrap every process' body within a macrolet that defines <- but with a process-specific part within the definition?
13:11:51
Bike
or you could wrap it in (symbol-macrolet ((this-process whatever)) ...) and have a global <- macro that does (macroexpand 'this-process env).
13:17:17
pfdietz
The particular use case I had for that was a DSL layered in top of Common Lisp that included some varieties of declarations. A fake macrolet was used to implement what amounts to a symbol table.