Unable to define function using "define-meta" in "pollen.rkt" #135

I'm looking to define a function that simplifies a common post metadata function like this:

◊(define-meta post-title "My Post")

into something like this:

◊post-title{My Post}

So, in the corresponding pollen.rkt, I tried the following:

;; "pollen.rkt"
(define (post-title . args)
  (define-meta title "Test Title"))

and got the error message title: unbound identifier in module in: title.

The documentation I found most related to this starts at around 12.3.1.4. Inserting metas of the command syntax page.

Is there something else I need to do in pollen.rkt or elsewhere in order to abstract define-meta in this way?

I'm looking to define a function that simplifies a common post metadata function like this: ~~~racket ◊(define-meta post-title "My Post") ~~~ into something like this: ~~~racket ◊post-title{My Post} ~~~ So, in the corresponding `pollen.rkt`, I tried the following: ~~~racket ;; "pollen.rkt" (define (post-title . args) (define-meta title "Test Title")) ~~~ and got the error message `title: unbound identifier in module in: title`. The documentation I found most related to this starts at around [12.3.1.4. Inserting metas](https://docs.racket-lang.org/pollen/pollen-command-syntax.html#%28part._.Inserting_metas%29) of the [command syntax](https://docs.racket-lang.org/pollen/pollen-command-syntax.html) page. Is there something else I need to do in `pollen.rkt` or elsewhere in order to abstract `define-meta` in this way?

I don’t think this is possible. The metas are lifted out of the source file at compile time, so they can be available to other macros and functions. But that necessarily means that they can’t be generated by those macros or functions.

What do you think about adding a define-settable variable so that in addition to setup:define-meta-name, you search for additional user-defined tags inside split-metas, except unlike 'define-meta, you leave these tags in-place rather than removing them from the source body.

So then a tag like ◊post-title{My Post} would be put into the metas hash with key 'post-title and value "My Post" but still be around for evaluation in doclang-raw for double duty. What do you think?

What do you think about adding a define-settable variable so that in addition to setup:define-meta-name, you search for additional user-defined tags inside split-metas, except unlike 'define-meta, you leave these tags in-place rather than removing them from the source body. So then a tag like ◊post-title{My Post} would be put into the metas hash with key 'post-title and value "My Post" but still be around for evaluation in doclang-raw for double duty. What do you think?

That would be possible. But. It would arguably violate the principle that the metas table should be generated as fast as possible, to promote ease of indexing. For that reason, split-metas is not currently dependent on any project setup values.

Moreover, once this dependency is added, it will make compilation of every Pollen file a little slower for everyone, forever, even though this seems like something of a niche request.

You’re welcome to make an argument to persuade me otherwise. But when I was discussing the metas table some months ago, the feedback was consistently “make it faster”, so I’m reluctant to go back on that lightly.

That would be possible. But. It would arguably violate the principle that the `metas` table should be generated as fast as possible, to promote ease of indexing. For that reason, `split-metas` is not currently dependent on any project `setup` values. Moreover, once this dependency is added, it will make compilation of every Pollen file a little slower for everyone, forever, even though this seems like something of a niche request. You’re welcome to make an argument to persuade me otherwise. But when I was discussing the `metas` table some months ago, the feedback was consistently “make it faster”, so I’m reluctant to go back on that lightly.

For that reason, split-metas is not currently dependent on any project setup values.

Except define-meta-name, of course.

You’re welcome to make an argument to persuade me otherwise. But when I was discussing the metas table some months ago, the feedback was consistently “make it faster”, so I’m reluctant to go back on that lightly.

I have no desire to make such argument; you're the benevolent dictator of this repo. But in light of the speed argument, can you help me understand your current implementation of split-metas? In particular I'm confused about the purpose of gensym.

A few days ago I implemented my own version of split-metas (see attached). During my anecdotal testing it was ~2x faster than the current pollen implementation, but since I don't fully understand what you're doing, it's very possible (likely even?) I'm missing something important.

split-metas.txt

> For that reason, split-metas is not currently dependent on any project setup values. Except define-meta-name, of course. > You’re welcome to make an argument to persuade me otherwise. But when I was discussing the metas table some months ago, the feedback was consistently “make it faster”, so I’m reluctant to go back on that lightly. I have no desire to make such argument; you're the benevolent dictator of this repo. But in light of the speed argument, can you help me understand your current implementation of split-metas? In particular I'm confused about the purpose of gensym. A few days ago I implemented my own version of split-metas (see attached). During my anecdotal testing it was ~2x faster than the current pollen implementation, but since I don't fully understand what you're doing, it's very possible (likely even?) I'm missing something important. [split-metas.txt](https://github.com/mbutterick/pollen/files/692307/split-metas.txt)

Except define-meta-name, of course.

Fair point. Yes, I suppose main-base.rkt could just call split-metas with another argument, which is the list of tags that are meta-settable (empty by default).

it was ~2x faster than the current pollen implementation

Great! Make a PR!

I'm missing something important.

If it passes the package tests — change the source file and then run raco setup pollen and then raco test -p pollen — then chances are good that you’re not missing anything.

> Except define-meta-name, of course. Fair point. Yes, I suppose `main-base.rkt` could just call `split-metas` with another argument, which is the list of tags that are meta-settable (`empty` by default). > it was ~2x faster than the current pollen implementation Great! Make a PR! > I'm missing something important. If it passes the package tests — change the source file and then run `raco setup pollen` and then `raco test -p pollen` — then chances are good that you’re not missing anything.

Labels Milestones

Unable to define function using "define-meta" in "pollen.rkt" #135