Those tradeoffs make sense. I had tried to discern from the docs whether define-meta had some such conscious limitations or whether I’d missed some syntactic trick. This clears things up!
On Saturday, December 30, 2017 at 5:35:41 PM UTC-6, Matthew Butterick wrote: > > > On Dec 30, 2017, at 1:23 PM, Joel Dueck <[email protected] <javascript:>> > wrote: > > I would have expected define-meta to take the result of the expression > rather than quoting it. Is there a way to define a meta in terms of an > expression result? > > I don’t have a use for this right now, just curious. > > > > No, `define-meta` can only take a literal value (not an evaluated > expression) for three reasons: > > 1) For speed, `define-meta` plucks out all the values without evaluating > anything. > > 2) Evaluating things on the right-hand side of `define-meta` would lead to > sticky questions about what evaluation environment is should be used > (`racket/base`? `pollen/pre`? Can you bring in more imports?) > > 3) Literal values can be cached to disk (for even more speed). > > > That said, you aren't limited to symbols, numbers, and strings — you can > put anything on the right side of `define-meta` that Racket understands as > a literal value: > > ◊(define-meta hash-val #hash((a . 1) (c . 3) (b . 2))) > ◊(define-meta regex-val #px"^\\d+$") > > > Still, if you absolutely positively need to export an expression that's > evaluated at runtime, you can always just use `define` rather than > `define-meta`. In this case, `title` will be automatically exported as > "Hello There": > > #lang pollen > > ◊(define title (string-titlecase "hello there")) > -- 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.
