12:09:27SAL9000Not sure if this makes sense, but what comes to my mind is iterative helpers/syntax-sugar
12:09:46SAL9000Start by mocking up a simple example (your a.lisp, b.lisp thing, but slightly more complex maybe)
12:09:55SAL9000Then, "manually" figure out what operations that needs.
12:10:12SAL9000That should help you identify common patterns -- thus, the first layer of helpers/syntax-sugar
12:10:18SAL9000repeat for multiple layers if applicable
12:10:54SAL9000then for simple projects, the user can use the highest-level helpers, upgrading to the more complex/lower-level ones as necessary in the future
19:24:16Colleen<shinmera> Right now I'm dealing with this problem: when you create a component it iterates over its supported operations, and creates effects that it can create in a database.
19:24:26Colleen<shinmera> This is fine, and it needs to do this for planning to work at all.
19:24:39Colleen<shinmera> But: now consider something like compile-file, which produces a fasl artefact as output.
19:25:07Colleen<shinmera> in order to create this artefact, it needs to create a pseudo path
19:25:22Colleen<shinmera> in order to do that though it needs to know the compiler that's going to be used
19:25:36Colleen<shinmera> and it can't know that until the plan is actually being computed
21:00:55SAL9000Shinmera: represent the path as #<fasl-of #P"foo.lisp"> for the purposes of planning, then convert it to "real" fasl path once you know what compiler is used?