Re: [pollen] How to access current output type from `pollen.rkt'?

2016-10-20 Thread lfacchi2 
As usual, thank you very much. Your quick, precise and complete answers are 
part of what makes using Pollen a joy.

I think adding assignments to current-poly-target in all source files would 
pollute them. This is redundant information already stated in the file 
name. That is why I regarded it as a *bad answer*—even though it is a 
correct one—in my original post.

In light of your explainations, what I would *really* like is for (in order 
of preference):

   1. The existence of a current-output-type function, available to 
   *pollen.rkt*. It would return the same things that current-poly-target 
returns, 
   but would always be in correspondence with the output type in question, 
   regardless of the source file being (for example) .html.pm or *.poly.pm*.
   2. When using a source file with an extension other than *.poly.pm*, the 
   current-poly-target parameter is set to the default, which isn’t very 
   helpful. So, in that case, current-poly-target could change to do what I 
   described in the point above. Granted, current-poly-target is not as 
   aptly named to that purpose as current-output-type, but it might fit 
   better with the existing system and documentation.
   3. The existence of a metas variable, available to *pollen.rkt*. With 
   it, I could create current-output-type, as you showed in your answer.
   
If you disagree with all these proposals, I guess I’m going to try the idea 
of using macros to transparently get a hold of metas in *pollen.rkt*, as 
you described.

-- 
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] How to access current output type from `pollen.rkt'?

2016-10-20 Thread Matthew Butterick 

On Oct 20, 2016, at 8:33 AM, lfacc...@jhu.edu wrote:
> Use (current-poly-target). Notice that the files have extensions such as 
> .html.pm and .atom.pm, and not .poly.pm. This is no accident, since each file 
> only generates one output type. Thus, (current-poly-target) always answers 
> with the default output type, 'html.

`current-poly-target` is a Racket parameter, which is a special data type that 
allows imperative action from afar. Rather than rely on Pollen inferring the 
poly target from the filename, you can set it directly:

;; pollen.rkt
#lang racket/base
(provide (all-defined-out))

(require pollen/setup)
(define (foo . xs)
  (case (current-poly-target)
[(atom) 'do-atom-foo]
[else 'do-html-foo]))


;; index.anything.pm
#lang pollen

;; we won't use the variable `target`, 
;; but if we set the parameter without assigning it,
;; it evaluates to `void`, which we'd have to filter out 
◊(define target (current-poly-target 'atom))

◊foo{bar}


> '(root do-atom-foo "\n")


> Use (->output-path (select-from-metas 'here-path metas)).  The metas are not 
> available to pollen.rkt. It could not be, since metas come from the source 
> modules (for example, index.html.pm), but the source modules need the 
> definitions in pollen.rkt. It would be a circular dependency.


Ah, that is actually not true. The `doc` relies on "pollen.rkt", but the 
`metas` do not, because they live in an independent submodule. See [1]. This is 
deliberate, so you can fetch the metas quickly, without the overhead of running 
"pollen.rkt". The side effect is that there is no circular dependency.

But you still need to pass the metas to the `foo` function somehow. Of course, 
you can do this explicitly ...

◊foo2[metas]{bar}

... but it's sleeker to use a macro. Here's one way to do it:

;; pollen.rkt
#lang racket/base
(provide (all-defined-out))

(require (for-syntax racket/base) pollen/file sugar/file pollen/core)

;; if this macro doesn't make sense I will elaborate
(define-syntax (foo2 stx)
  (syntax-case stx ()
[(_ ARG ...)
 (with-syntax ([METAS (datum->syntax stx 'metas)])
   #'(do-foo2 (select-from-metas 'here-path METAS) ARG ...))]))

(define (do-foo2 here-path . xs)
  (define ext (string->symbol (get-ext (->output-path here-path
  (case ext
[(atom) 'do-atom-foo2]
[else 'do-html-foo2]))

;; index.atom.pm
#lang pollen

◊foo2{bar}


> '(root do-atom-foo2 "\n")



> Use different functions foo/html and foo/atom. This doesn’t work because some 
> of the function calls are implicit. For example, in my real code, I want this 
> level of control on root, which is a magical function called by Pollen on the 
> module level

You could make `root` into a macro, following the pattern shown above, and 
branch to `foo/html` and `foo/atom`.



[1] 
http://docs.racket-lang.org/pollen/pollen-command-syntax.html?q=metas#%28part._.Retrieving_metas%29

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