[pollen] A "second-run" for a txexpr?

[trentonw]

Hello,

I've been using Pollen for about 9 months now and have been enjoying it. I 
primarily use it to generate LaTeX so that I can write consistently in 
pollen and abstract away the different LaTeX templates each conference has. 
I've been doing this using the multi-target method described in Tutorial 4 
(because, being able to generate an HTML version is nice too). This has 
worked pretty well, and I've turned out a few papers, an essay, and a 
project proposal doing this.

Recently, I was looking through the TFL pollen.rkt to see if there were any 
cool ideas I could borrow. And I saw the detect-list-items function and 
corresponding bullet-list tag. 

◊bullet-list{
Foo


Bar


Baz
}


I liked this better than explicitly adding all the tags myself (for 
example):
◊ul{
◊li{foo}
◊li{bar}
◊li{baz}}

In this case, these ul and li tags more or less pass-through for HTML (li 
does a decode paragraph too) and get translated to the LaTeX equivalent.

Both bullet-list as-is and my stew of tags get me the same HTML result, but 
I was hoping that I could "evaluate" the result that comes out of the 
bullet-list and have it generate the LaTeX, sparing me from creating a new 
"detect-list-items" for LaTeX. Something like (forgive novice Racket code):

(define (my-bullet-list . args)
  (define results `(bullet-list ,@args))
  (define results2 (eval results ns))
  (eval results2 ns))

I tried this in the REPL, but got an error "#%app: missing procedure 
expression;" So, I suspect I'm "doing it wrong" in more ways than one.

So, I'm wondering if there is some mechanism for evaluating a txexpr in 
Pollen? If this is not how it's done, I'm certainly willing to to know the 
right way to do this (maybe a hook in decode?). Eval feels a bit risky, but 
since it's only my own feet I'm stepping on, I don't mind too much (for 
now).

The right way may be that I just "port" my old code over to the 
detect-list-items, but I just figured I would ask here as I've run into 
this need(?) another time when I was playing with attributes and suddenly 
wanted to put a tag in one of them (solved another way).

Best regards,

-- 
Trenton

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

Re: [pollen] A "second-run" for a txexpr?

[Leandro Facchinetti]

My impression is that you do not want `(bullet-list ,@args), because it creates 
a txexpr right away. Instead, you should try (apply bullet-list args). Note the 
lack of the quasiquote (backquote, `) and unquote-splicing (,@). This does not 
immediately create a txexpr, but calls ‘bullet-list’ as a function, which in 
turn will generate a txexpr.
-- 
Leandro Facchinetti 
https://www.leafac.com

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

Re: [pollen] A "second-run" for a txexpr?

[trentonw]

On Tuesday, September 5, 2017 at 2:32:34 PM UTC+2, Leandro Facchinetti 
wrote:
>
> My impression is that you do not want `(bullet-list ,@args), because it 
> creates a txexpr right away. Instead, you should try (apply bullet-list 
> args). Note the lack of the quasiquote (backquote, `) and unquote-splicing 
> (,@). This does not immediately create a txexpr, but calls ‘bullet-list’ as 
> a function, which in turn will generate a txexpr. 
>

Yes, my calling a bit wrong there. I was just grabbing the last attempt. 
Yes, apply is the better way. I still get the same error message though if 
I try to eval the results.

The bullet-list function already creates a txexpr, but I'd like to call 
that txexpr as a function. I'll try to explain again and try to remove the 
HTML duality. Let's say that bullet-list generates the txexpr:

'(unordered-list
  ()
  (list-item (paragraph "Foo"))
  (list-item (paragraph "Bar"))
  (list-item (paragraph "Baz")))

And I have pollen tags for 'unorderd-list, 'list-item, and 'paragraph that 
do different things for HTML and LaTeX. 

Is there a way that I can make the txexpr call those tag functions (i.e., 
unordered-list, list-item, and paragraph)?

Or is the idea that once you've reached a txexpr you are at the end of the 
line and no more processing should happen?

Best regards,

-- 
Trenton

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

Re: [pollen] A "second-run" for a txexpr?

[Leandro Facchinetti]

I think
> On 2017-09-05, at 09:01, trent...@ifi.uio.no wrote:
> 
> 
> 
> On Tuesday, September 5, 2017 at 2:32:34 PM UTC+2, Leandro Facchinetti wrote:
> My impression is that you do not want `(bullet-list ,@args), because it 
> creates a txexpr right away. Instead, you should try (apply bullet-list 
> args). Note the lack of the quasiquote (backquote, `) and unquote-splicing 
> (,@). This does not immediately create a txexpr, but calls ‘bullet-list’ as a 
> function, which in turn will generate a txexpr. 
> 
> Yes, my calling a bit wrong there. I was just grabbing the last attempt. Yes, 
> apply is the better way. I still get the same error message though if I try 
> to eval the results.
> 
> The bullet-list function already creates a txexpr, but I'd like to call that 
> txexpr as a function. I'll try to explain again and try to remove the HTML 
> duality. Let's say that bullet-list generates the txexpr:
> 
> '(unordered-list
>   ()
>   (list-item (paragraph "Foo"))
>   (list-item (paragraph "Bar"))
>   (list-item (paragraph "Baz")))
> 
> And I have pollen tags for 'unorderd-list, 'list-item, and 'paragraph that do 
> different things for HTML and LaTeX. 
> 
> Is there a way that I can make the txexpr call those tag functions (i.e., 
> unordered-list, list-item, and paragraph)?
> 
> Or is the idea that once you've reached a txexpr you are at the end of the 
> line and no more processing should happen?
> 
> Best regards,
> 
> -- 
> Trenton
> 
> -- 
> 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 
> .


-- 
Leandro Facchinetti 
https://www.leafac.com

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

Re: [pollen] A "second-run" for a txexpr?

[Leandro Facchinetti]

(Please, disregard the last email, it was sent by accident.)

I think I understand what you’re proposing, now.

I believe you’re getting the “#%app: missing procedure expression” error 
because of the ‘()’, which is the first argument in the ‘unordered-list’ call.

You can try to work around this issue and still use ‘eval’. For example, you 
can try to redefine the ‘#%app’ form in a way that ignores ‘()’. If this 
doesn’t make sense, take a look at Beautiful Racket [1]. But it feels like 
fighting the system.

Maybe a better approach would be to redefine ‘bullet-list’ such that it calls 
‘unordered-list’, ‘list-item’, ‘paragraph’ and so forth as functions. Or, if 
‘bullet-list’ is beyond your control, try to post-process the generated txexpr 
using some form of ‘decode’, for example.

More broadly, I wouldn’t say a txexpr is the end of the line. Quite the 
opposite, the advantage of working with txexpr—as opposed to, for example, 
strings—is precisely that they’re more convenient to handle programmatically. 
The issue is just that ‘eval’ doesn’t seem to be the best way to go about doing 
it.


[1]: http://beautifulracket.com
-- 
Leandro Facchinetti 
https://www.leafac.com

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

Re: [pollen] A "second-run" for a txexpr?

[trentonw]

On Tuesday, September 5, 2017 at 3:31:00 PM UTC+2, Leandro Facchinetti 
wrote:
>
> (Please, disregard the last email, it was sent by accident.) 
>
> I think I understand what you’re proposing, now. 
>
> I believe you’re getting the “#%app: missing procedure expression” error 
> because of the ‘()’, which is the first argument in the ‘unordered-list’ 
> call. 
>
> You can try to work around this issue and still use ‘eval’. For example, 
> you can try to redefine the ‘#%app’ form in a way that ignores ‘()’. If 
> this doesn’t make sense, take a look at Beautiful Racket [1]. But it feels 
> like fighting the system. 
>

Indeed it does feel like fighting the system, which I why I thought I'd 
write.

Thanks for the pointer though. I've found nice explainers in Beautiful 
Racket. Just haven't had time to sit down and read it.
 

>
> Maybe a better approach would be to redefine ‘bullet-list’ such that it 
> calls ‘unordered-list’, ‘list-item’, ‘paragraph’ and so forth as functions. 
> Or, if ‘bullet-list’ is beyond your control, try to post-process the 
> generated txexpr using some form of ‘decode’, for example. 
>

Bullet-list is in my control, I was just using the example from the pollen 
Typography for Lawyers for inspiration since it felt like writing tags for 
every list felt too heavy, and I figured others had run into this issue 
before. So, I can re-write it to call the correct functions.

I was also interesting in the post-processing in decode, but I'm still not 
sure where I would attach to in decode. I guess it'd be the txexpr-elements 
hook, but that only seems to deal with the elements. I'll have to check the 
docs.
 

> More broadly, I wouldn’t say a txexpr is the end of the line. Quite the 
> opposite, the advantage of working with txexpr—as opposed to, for example, 
> strings—is precisely that they’re more convenient to handle 
> programmatically. The issue is just that ‘eval’ doesn’t seem to be the best 
> way to go about doing it. 
>

Right, what I thought too. That's also why I was wondering if pollen had 
it's own "pollen-eval" or some such things (or just literally stuff it into 
the input). It feels like sometimes you really just want to run the output 
again. I can see the can of worms it would open, so understand if it's not 
allowed.

Thanks for the help!

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

Re: [pollen] A "second-run" for a txexpr?

[Matthew Butterick]

> On Sep 5, 2017, at 4:26 PM, trent...@ifi.uio.no wrote:
> 
> Bullet-list is in my control, I was just using the example from the pollen 
> Typography for Lawyers for inspiration since it felt like writing tags for 
> every list felt too heavy, and I figured others had run into this issue 
> before. So, I can re-write it to call the correct functions.

Leandro's advice is sound — call more functions, don't reduce to X-expressions 
as quickly. 

It doesn't sound like you need `eval`. I'm not an enemy of `eval`, but like 
macros, there's often a simpler way to get the same result.

FWIW Pollen isn't different from Racket in that regard — Racket keeps 
evaluating expressions until it gets a value, and then stops.

The weakness of my `detect-list-items` example in the `pollen-tfl` project is 
that I only need to generate lists for HTML, so I'm reducing the result 
immediately to an X-expression (by applying `(default-tag-function 'li)`).

In your case, you'd want to take the `list-of-li-paragraphs` and pass it to 
another function, let's call it `make-li`, that has different behavior 
depending on whether you're targeting HTML, or LaTeX, etc.

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

Re: [pollen] A "second-run" for a txexpr?

[trentonw]

It seems that I only replied to Matthew and not the list. So, for the sake 
of completeness, I'm reposting here.

On Tuesday, September 5, 2017 at 7:00:29 PM UTC+2, Matthew Butterick wrote:
>
>
> On Sep 5, 2017, at 4:26 PM, tren...@ifi.uio.no  wrote:
>
> Bullet-list is in my control, I was just using the example from the pollen 
> Typography for Lawyers for inspiration since it felt like writing tags for 
> every list felt too heavy, and I figured others had run into this issue 
> before. So, I can re-write it to call the correct functions.
>
>
> Leandro's advice is sound — call more functions, don't reduce to 
> X-expressions as quickly. 
>

Yes, that’s actually what I realized after reading the message. I realized 
that code was “optimized” to go straight to the final HTML (as it should). 
I need to “slow down” a little. 


> It doesn't sound like you need `eval`. I'm not an enemy of `eval`, but 
> like macros, there's often a simpler way to get the same result.
>

Indeed! eval didn’t have the right feeling. 

>
> FWIW Pollen isn't different from Racket in that regard — Racket keeps 
> evaluating expressions until it gets a value, and then stops.
>
> The weakness of my `detect-list-items` example in the `pollen-tfl` project 
> is that I only need to generate lists for HTML, so I'm reducing the result 
> immediately to an X-expression (by applying `(default-tag-function 'li)`).
>
> In your case, you'd want to take the `list-of-li-paragraphs` and pass it 
> to another function, let's call it `make-li`, that has different behavior 
> depending on whether you're targeting HTML, or LaTeX, etc.
>

Yes, that’s exactly what I did. The function is pretty similar to what you 
had. Here’s my modified functions in case anyone wonders:

(define (make-list-function tag-func [attrs empty])
 (λ args (apply tag-func attrs (detect-list-items args 

(define bullet-list (make-list-function ul))

(define (detect-list-items elems)
 (define elems-merged (merge-newlines elems))
 (define (list-item-break? elem)
   (define list-item-separator-pattern (regexp "\n\n\n+"))
   (and (string? elem) (regexp-match list-item-separator-pattern elem)))
 (define list-of-li-elems (filter-split elems-merged list-item-break?))
 (map (λ(lip) (apply li lip)) list-of-li-elems))



My make-list-function takes a function instead of a symbol (here my ul 
function) and I call my li function instead of decode-paragraphs. It works 
exactly as I expected for HTML and LaTeX. Though it feels worthwhile making 
aliases for these functions to unordered-list and list-item now that I 
don’t call them directly.

Thanks for the extra help, Leandro and Matthew. Sometimes explaining things 
to others help unclog your thought process.

Best regards,

— 
Trenton
 

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