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
> 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 pollenpub+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.