Re: [pollen] Splitting multiple-output tag functions with a Racket macro

[Matthew Butterick]

PS Jens Axel recommended looking at Racket units. I know nothing about those. 
Jens Axel is usually right, however.

-- 
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] Splitting multiple-output tag functions with a Racket macro

[Matthew Butterick]

On Nov 14, 2016, at 10:40 AM, Joel Dueck  wrote:

> What if Pollen automatically branched to tag functions prefixed with pdf: 
> when current-poly-target is 'pdf ? That is, if 'pdf is the current target, 
> Pollen would check for pdf:strong and, if it didn't find one, default to 
> plain-ol strong

When you talk about functions transparently overriding other functions in some 
kind of inheritance hierarchy, are you talking about ... classes?

http://docs.racket-lang.org/guide/classes.html

-- 
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] Splitting multiple-output tag functions with a Racket macro

[Joel Dueck]

>
> I like these ideas, and it suggests to me that Pollen could have some 
> better tools built in for managing poly projects. 
>
 
I agree, any additional facilities for splitting out the logic of tag 
functions by output format would be welcome as long as they aren't too 
complicated.

After trying it this macro, my one thought was that using the 
> `poly-branch-tag` macro requires naming the underlying tag functions in a 
> certain way, which is potentially fragile (and requires escalating 
> housekeeping). 
>

I thought about this a bit while writing it. It is kind of brittle, but it 
has one (extremely fringe) benefit. Suppose you have two target formats 
that require their tag functions to produce very similar output. For 
example, suppose you have a .txt format and a .wav format, where the tag 
functions for both are producing similar-looking plain text (which 
template.wav presumably converts using text-to-speech as the final step). 
In this case, it will be obvious from the name of the function you are 
editing what format you are working with. This works slightly better with 
how I think while skimming and writing code (i.e. lazy subconscious 
assumption that function names are unique within a project).

Here's an alternate — not necessarily better or preferable — approach where 
> the macro takes as input the targets and the source files containing the 
> tags: 
> https://gist.github.com/mbutterick/caf88360fc0090305937ca54539054bc
>

I found this instructive and it got me thinking. What if Pollen 
automatically branched to tag functions prefixed with pdf: when 
current-poly-target is 'pdf ? That is, if 'pdf is the current target, 
Pollen would check for pdf:strong and, if it didn't find one, default to 
plain-ol strong. You could then (require (prefix-in pdf: "my-pdf-tags.rkt")) 
and everything in "my-pdf-tags.rkt" would be used for PDF. You wouldn't 
have to worry about filenames *or* function names.  (Alternatively you 
could manually name all your PDF tag functions pdf:tagname and put them 
wherever you want.) This gives me most(*) of what I originally tried to 
accomplish, & doesn't break existing projects or the examples in the docs.

(* - The other thing I like about my macro is the ability to add a required 
attribute, or to assign default values some attributes, prior to branching 
to the tag function for this or that format.)

-- 
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] Splitting multiple-output tag functions with a Racket macro

[Matthew Butterick]

On Nov 11, 2016, at 11:48 AM, Joel Dueck  wrote:

> I created a macro to help myself out as I consider adding a third and fourth 
> output format to a Pollen project.
> 
> I wrote about it at my Pollen-as-blog project here: 
> https://thenotepad.org/posts/splitting-pollen-tags-with-racket-macros.html
> Comments/criticism welcome.


I like these ideas, and it suggests to me that Pollen could have some better 
tools built in for managing poly projects.

After trying it this macro, my one thought was that using the `poly-branch-tag` 
macro requires naming the underlying tag functions in a certain way, which is 
potentially fragile (and requires escalating housekeeping).

Here's an alternate — not necessarily better or preferable — approach where the 
macro takes as input the targets and the source files containing the tags:

https://gist.github.com/mbutterick/caf88360fc0090305937ca54539054bc

Invoked like so:

(define-poly-tag-from-file root
  [html "pollen-local/tags-html.rkt"]
  [pdf "pollen-local/tags-pdf.rkt"])

In this case, the tag functions are all defined using the same names. So the 
macro fetches the `root` function out of "pollen-local/tags-html.rkt" and uses 
it for the 'html branch of the poly tag; then fetches `root` out of 
"pollen-local/tags-html.rkt" and uses it for the 'pdf branch, etc.


We could imagine a second macro that stacks on top of this one to generate 
other poly tags en masse:

(define-syntax-rule (my-poly-tags ID ...)
  (begin
(define-poly-tag-from-file ID
  [html "pollen-local/tags-html.rkt"]
  [pdf "pollen-local/tags-pdf.rkt"]) ...))

(my-poly-tags p i emph b strong code)


For that matter we could also imagine a macro that generates the call to 
`define-poly-tag-from-file` using the list of current poly targets, and a 
certain naming convention for the source files.





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