Tips to write lists #21

I know the traditional Pollen way of writing lists would be someting like this

◊ul{
◊i{first item}
◊i{second,
    multiline
    item
    ◊ul{
        ◊i{first item}
        ◊i{second,
            multiline
            item}}} 
}

But that is rather hard to read, I think. I managed to get something like this working

◊ul{
- first item
- second,
    multiline
    item
        - first item
        - second,
            multiline
            item
}

But now the code is hard to extend (i.e. by adding a new kind of bullet, or adding ordered sections). I’m wondering if any of you have already met the same problem and how did you slove it. It could be a concrete piece of code, or even some best-practices regarding these “semi-markdown tags” that you learned the hard way.

I know the traditional Pollen way of writing lists would be someting like this ``` ◊ul{ ◊i{first item} ◊i{second, multiline item ◊ul{ ◊i{first item} ◊i{second, multiline item}}} } ``` But that is rather hard to read, I think. I managed to get something like this working ``` ◊ul{ - first item - second, multiline item - first item - second, multiline item } ``` But now the code is hard to extend (i.e. by adding a new kind of bullet, or adding ordered sections). I’m wondering if any of you have already met the same problem and how did you slove it. It could be a concrete piece of code, or even some best-practices regarding these “semi-markdown tags” that you learned the hard way.

You could parse the contents of the ul tag function as markdown. See related example.

You could parse the contents of the `ul` tag function as markdown. See [related example](https://github.com/mbutterick/pollen-users/issues/18#issuecomment-551900405).

Thanks, that’s a nice idea! Now that I’m thinking about it, I could also run my own small list-parser, to be able to extend it with additional bullet point types. However, what I didn’t understand from the issue you’ve linked, nor from the discussion on the old mailing list, is whether it is possible to use pollen tags inside that kind of environment (and additionaly how to do it).

◊parse-list{
- first item
- second,
    ◊bold{multiline}
    item
        - first item
        - second,
            multiline
            item
}

Thanks, that’s a nice idea! Now that I’m thinking about it, I could also run my own small list-parser, to be able to extend it with additional bullet point types. However, what I didn’t understand from the issue you’ve linked, nor from the discussion on the old mailing list, is whether it is possible to use pollen tags inside that kind of environment (and additionaly how to do it). ``` ◊parse-list{ - first item - second, ◊bold{multiline} item - first item - second, multiline item } ```

The tricky issue is how you transmit the result of a tag function, which is an X-expression, through a block of Markdown, which doesn’t know anything about X-expressions. @otherjoel had a clever idea to convert the X-expression to HTML, which will pass through the Markdown parser intact.

Another idea is to make your bold tag function behave differently within a parse-list — it could emit the Markdown-compliant **multiline** rather than '(strong "multiline").

The tricky issue is how you transmit the result of a tag function, which is an X-expression, through a block of Markdown, which doesn’t know anything about X-expressions. @otherjoel [had a clever idea to convert](https://github.com/mbutterick/pollen-users/issues/9#issuecomment-528490613) the X-expression to HTML, which will pass through the Markdown parser intact. Another idea is to make your `bold` tag function behave differently within a `parse-list` — it could emit the Markdown-compliant `**multiline**` rather than `'(strong "multiline")`.

The idea with HTML is a good one, thanks.

For posterity, here is the original example of reapplying tag functions with eval:

"test.html.pm"

#lang pollen

Hello _world_!

"pollen.rkt"

#lang racket
(require (only-in markdown parse-markdown)
         pollen/decode pollen/tag txexpr/stx
         (prefix-in pt: pollen/top))

(provide (all-defined-out))

(define-tag-function (em attrs elems)
  `(my-em ,attrs  "--Never a dull moment!--" ,@elems))

(define (reapply-tags stx)
  (with-syntax ([XEXPR (let loop ([stx stx])
                         (if (stx-txexpr? stx)
                             (with-syntax ([TAG (stx-txexpr-tag stx)]
                                           [ATTRS (stx-txexpr-attrs stx)]
                                           [ELEMS (map loop (stx-txexpr-elements stx))])
                               #'(TAG 'ATTRS . ELEMS))
                             stx))])
    #'(let-syntax ([#%top (make-rename-transformer #'pt:#%top)])
        XEXPR)))
  
(define (root . xs)
  (define marked-down (decode-elements xs #:string-proc parse-markdown))
  (eval (reapply-tags `(body ,@marked-down))))

What happens here:

Here, the source is not a pollen/markdown dialect. Rather, the Markdown parsing happens in the root function (this is just for the sake of the example — IRL you wouldn’t do it this way — you’d just attach parse-markdown to certain tags)
The result of this parse is an X-expression that looks like this:
'(body (p () "Hello " (em () "world") "!"))
Then we reapply-tags by using this X-expression as a parse tree and passing it through eval.
In principle you can do this as many times as you want, thereby extending what would ordinarily be one runtime evaluation into more.
There may be a way to do this at compile time too — say, by running parse-markdown as part of a macro rather than a tag function, but that may incur other difficulties I’m not considering for now.

For posterity, here is the original example of reapplying tag functions with `eval`: `"test.html.pm"` ``` #lang pollen Hello _world_! ``` `"pollen.rkt"` ```racket #lang racket (require (only-in markdown parse-markdown) pollen/decode pollen/tag txexpr/stx (prefix-in pt: pollen/top)) (provide (all-defined-out)) (define-tag-function (em attrs elems) `(my-em ,attrs "--Never a dull moment!--" ,@elems)) (define (reapply-tags stx) (with-syntax ([XEXPR (let loop ([stx stx]) (if (stx-txexpr? stx) (with-syntax ([TAG (stx-txexpr-tag stx)] [ATTRS (stx-txexpr-attrs stx)] [ELEMS (map loop (stx-txexpr-elements stx))]) #'(TAG 'ATTRS . ELEMS)) stx))]) #'(let-syntax ([#%top (make-rename-transformer #'pt:#%top)]) XEXPR))) (define (root . xs) (define marked-down (decode-elements xs #:string-proc parse-markdown)) (eval (reapply-tags `(body ,@marked-down)))) ``` What happens here: 1. Here, the source is **not** a `pollen/markdown` dialect. Rather, the Markdown parsing happens in the `root` function (this is just for the sake of the example — IRL you wouldn’t do it this way — you’d just attach `parse-markdown` to certain tags) 1. The result of this parse is an X-expression that looks like this: `'(body (p () "Hello " (em () "world") "!"))` 1. Then we `reapply-tags` by using this X-expression as a parse tree and passing it through `eval`. 1. In principle you can do this as many times as you want, thereby extending what would ordinarily be one runtime evaluation into more. 1. There may be a way to do this at compile time too — say, by running `parse-markdown` as part of a macro rather than a tag function, but that may incur other difficulties I’m not considering for now.

Labels Milestones

Tips to write lists #21