On Oct 20, 2016, at 11:50 AM, [email protected] wrote: > The existence of a current-output-type function, available to pollen.rkt. It > would return the same things that current-poly-target returns, but would > always be in correspondence with the output type in question, regardless of > the source file being (for example) .html.pm or .poly.pm. > When using a source file with an extension other than .poly.pm, the > current-poly-target parameter is set to the default, which isn’t very > helpful. So, in that case, current-poly-target could change to do what I > described in the point above. Granted, current-poly-target is not as aptly > named to that purpose as current-output-type, but it might fit better with > the existing system and documentation.
`current-poly-target` is meant to fill in a detail that cannot be inferred from the source file name. How is your proposed `current-output-type` parameter different from an expression like this? (in pseudocode): (if source-file-has-poly-ext (current-poly-target) (get-source-file-ext)) > The existence of a metas variable, available to pollen.rkt. With it, I could > create current-output-type, as you showed in your answer. I don't see how this would be better than just passing `metas` to functions in "pollen.rkt" when needed. In general, I'm wary of adding magic communication to the supported interface when standard Racket idiom will suffice. (Though I would not talk anyone out of structuring a project that way.) The advantage of a macro in a case like this is that it's a little bit hacky, but the hackiness is contained. -- You received this message because you are subscribed to the Google Groups "Pollen" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
