Matthew has shown you the code, that's what I would do if I were you.

> For plaintext though, we need to keep track of state (are we in a list?
> what type?)
>
No, we don't need mutate any state here. You are given a list, presented as
tagged data[1], that you want to modify. The task is just like prepending
numbers ahead of a list of string '("item1", "item2", "item3"). The only
difference is that they're now tagged with `li`.


> and a list item counter (at least for ordered lists); and this becomes
> particularly thorny with nested lists. So my first thought was a global
> list; as we process the document whenever we encounter a list (an ol or ul,
> or some other type of list), we push some state information onto a sort of
> stack of pairs representing the type of list, and a number representing the
> current note number. Something like:
>
> (set! document-lists (cons ('unordered . 0) document-list))
>
> If you do so, you need to reset the counter for every document! This is
just like doing mutation to a global variable in C/C++/Java/Python. Your
program will be hard to manage in the future. And it's ugly.


>
> First, I globally define some way of keeping state (here just a list
> *type*):
>
> (define list-type 'none)
>
>
> Then, in the function that handles ordered lists:
>
> (define (ol . elements)
>   (case (current-poly-target)
>     [(html) (txexpr 'ol empty elements)]
>     [(txt)
>         (set! list-type 'ordered)
>         (apply string-append `("\n" ,@elements)]))
>
> And, in the function that handles list items:
>
> (define (li . elements)
>   (case (current-poly-target)
>    ...
>    [(txt)
>         (case list-type ;I think this is right; is current-poly-target is
> a function; list-type just a value.
>            [(ordered)  (apply string-append `("#. " ,@elements "\n"))])]))
>
> If it were working, I'd also be counting the list items and inserting that
> number where currently there is just a # sign. But this isn't working...
> and it seems that the *set! *which changes *list-type *isn't working.
> After some playing around, it seems that when list items are processed
> (when the *li *function is called), the code for the *ordered *list in
> the case statement isn't getting run; in *li * *list-type* still has its
> initial value.
>
> So is *set! *not changing it in *ol* because I'm misunderstanding how to
> use set! to keep global state. [I know, as well, that such state is
> anathema to functional style---but things like numbered lists (or
> footnotes) in a document seem to be a reasonable case for using mutation,
> right? There is no obvious functional way of dispensing with this problem
> entirely?]
>
No, you don't need a way, or signifiers, to do functional programming.
Actually you should always try to solve your problem in functional style.
Once  your project becomes big, you'd appreciate your no-mutable-data
attitude.


>
> *Or *am I wrong in assuming that Pollen (like XSLT) processes the
> document linearly, so that I could set state information in the *ol * to
> affect how its "children" (ie. the list items) are processed?
>
> Or {entirely possible!}, have I overlooked something else?
>
Yes, without knowing the internal of Pollen, I would say because the
evaluate model of racket is "strict evaluate": arguments get evaluated
before the function.

(ol (li "123") (li "2345"))

will evaluate li before ol, so li function is called before ol.


>
Thanks for reading this far down!
>

Again, just don't think that you should mutate state because you can. You
can, but you shouldn't.

[1] https://mitpress.mit.edu/sicp/full-text/book/book-Z-H-17.html#%_idx_2360


> --
> 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.
>

-- 
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.

Reply via email to