List Processing #91

I have a list that I have made by consing strings from various places in a pollen document, called "agenda-dl." If I insert the tag

◊(for-each (lambda (x) (format "~a\n" x)) agenda-dl)

I can see the results formatted correctly in the REPL, but it does not appear in the html document. This does not appear to be an output port issue, because

◊(format "~a" agenda-dl)

puts me the unquoted strings in parens in the html without newlines, as expected. Is it not possible for a tag to walk through a list of strings in Pollen?

I have a list that I have made by consing strings from various places in a pollen document, called "agenda-dl." If I insert the tag ◊(for-each (lambda (x) (format "~a\n" x)) agenda-dl) I can see the results formatted correctly in the REPL, but it does not appear in the html document. This does not appear to be an output port issue, because ◊(format "~a" agenda-dl) puts me the unquoted strings in parens in the html without newlines, as expected. Is it not possible for a tag to walk through a list of strings in Pollen?

The return value of for-each is always void. Maybe you want map?

The return value of `for-each` is always `void`. Maybe you want `map`?

(map (lambda (x) (format "~a\n" x)) agenda-dl) returns a list of strings in the REPL with \n's added and throws a error in the pollen server. ("Expected: txexpr-elements? Given: {a big s-expression that looks like my whole document}.") (map (lambda (x) (printf "~a\n" x)) agenda-dl) prints out the strings as desired in the REPL and then returns a quoted list of voids in the REPL. It produces a similar error in the pollen server. Looks like this is closer in that something is being inserted into the document that is making txexpr unhappy...

(map (lambda (x) (format "~a\n" x)) agenda-dl) returns a list of strings in the REPL with \n's added and throws a error in the pollen server. ("Expected: txexpr-elements? Given: {a big s-expression that looks like my whole document}.") (map (lambda (x) (printf "~a\n" x)) agenda-dl) prints out the strings as desired in the REPL and then returns a quoted list of voids in the REPL. It produces a similar error in the pollen server. Looks like this is closer in that *something* is being inserted into the document that is making txexpr unhappy...

Can you paste a short example pollen source that triggers the problem and the resulting s-expression?

(map (lambda (x) (format "~a\n" x)) agenda-dl) returns a list of strings

You can’t return a list of X-expressions (for instance, strings) in a position that Pollen expects a single X-expression. You need to manufacture a new tagged X-expression with the list of X-expressions as elements. To do that, you can wrap the list, either with an HTML tag (like div), or, if you really want the list to be merged with the surrounding material, with the special splicing tag @.

(map (lambda (x) (printf "~a\n" x)) agenda-dl) prints out the strings as desired in the REPL and then returns a quoted list of voids

Right, because the return value of printf is always void. If you want to debug expressions, I suggest using the debug language, which lets you print expressions without using printf statements and disrupting the return value chain.

> (map (lambda (x) (format "~a\n" x)) agenda-dl) returns a list of strings You can’t return a list of X-expressions (for instance, strings) in a position that Pollen expects a single X-expression. You need to manufacture a new tagged X-expression with the list of X-expressions as elements. To do that, you can wrap the list, either with an HTML tag (like `div`), or, if you really want the list to be merged with the surrounding material, with the special [splicing tag `@`](https://docs.racket-lang.org/pollen/Core.html?q=splicing#%28part._.Splicing%29). > (map (lambda (x) (printf "~a\n" x)) agenda-dl) prints out the strings as desired in the REPL and then returns a quoted list of voids Right, because the return value of `printf` is always `void`. If you want to debug expressions, I suggest using the [`debug` language](https://docs.racket-lang.org/debug/index.html), which lets you print expressions without using `printf` statements and disrupting the return value chain.

Works, sort of. Each string is formatted as " "~a: [~a] ~a \n\n"

◊(txexpr 'div '() agenda-dl)
and
◊(txexpr 'div '() (decode-elements agenda-dl #:txexpr-elements-proc decode-paragraphs))

both give me the text without line or paragraph breaks. I'm guessing that the "\n\n" needs to be a separate element?

Works, sort of. Each string is formatted as " "~a: [~a] ~a \n\n" ◊(txexpr 'div '() agenda-dl) and ◊(txexpr 'div '() (decode-elements agenda-dl #:txexpr-elements-proc decode-paragraphs)) both give me the text without line or paragraph breaks. I'm guessing that the "\n\n" needs to be a separate element?

Yes. This is noted in the docs: “What counts as a paragraph? Any elements that are either a) explicitly set apart with a paragraph separator, or b) adjacent to a block-txexpr? (in which case the paragraph-ness is implied).“

FWIW, instead of embedding newlines in your strings and using decode-paragraphs, you could just map a tag function:

(require pollen/tag)
(map (default-tag-function 'p) '("string1" "string2" "string3"))

'((p "string1") (p "string2") (p "string3"))

Yes. This is noted [in the docs](https://docs.racket-lang.org/pollen/Decode.html?q=decode-paragraphs#%28def._%28%28lib._pollen%2Fdecode..rkt%29._decode-paragraphs%29%29): “What counts as a paragraph? Any elements that are either a) explicitly set apart with a paragraph separator, or b) adjacent to a block-txexpr? (in which case the paragraph-ness is implied).“ FWIW, instead of embedding newlines in your strings and using `decode-paragraphs`, you could just `map` a tag function: ``` (require pollen/tag) (map (default-tag-function 'p) '("string1" "string2" "string3")) ``` ``` '((p "string1") (p "string2") (p "string3")) ```

FWIW the reason paragraph decoding works this way is so it cooperates nicely with the Pollen-style curly-brace notation, which returns a list of strings, with linebreaks separated from the other text elements. For instance markup written like so:

#lang pollen/mode racket

◊list{
first item

second item

third item
}

Results in this:

'("first item" "\n" "\n" "second item" "\n" "\n" "third item")

Notice that the leading and trailing whitespace is automatically trimmed, as well. Now we can take the output and pass it to decode-paragraphs:

(decode-paragraphs '("first item" "\n" "\n" "second item" "\n" "\n" "third item"))

And get a list of three paragraphs:

'((p "first item") (p "second item") (p "third item"))

FWIW the reason paragraph decoding works this way is so it cooperates nicely with the Pollen-style curly-brace notation, which returns a list of strings, with linebreaks separated from the other text elements. For instance markup written like so: ``` #lang pollen/mode racket ◊list{ first item second item third item } ``` Results in this: ``` '("first item" "\n" "\n" "second item" "\n" "\n" "third item") ``` Notice that the leading and trailing whitespace is automatically trimmed, as well. Now we can take the output and pass it to `decode-paragraphs`: ``` (decode-paragraphs '("first item" "\n" "\n" "second item" "\n" "\n" "third item")) ``` And get a list of three paragraphs: ``` '((p "first item") (p "second item") (p "third item")) ```

Labels Milestones

List Processing #91