I hate to turn a little question into a big one, but… are parameters the right 
choice, here? It seems to me that optional parameters would be more suitable.

Unfortunately, I’ve been on the other side of this fence, too: parameters are 
vastly more convenient for implementors than adding optional parameters to 
every one of the internal calls. This certainly came up for me in the 
construction of a CSV writing library.

I can imagine a bunch of programming patterns that might assist this; the most 
obvious one would be an object-like metaphor where parameter values are 
represented as an object to which calls are made. Do others have ideas on a 
“best practice” for this situation and others like it?

John



> On Aug 2, 2018, at 00:01, Alex Harsanyi <alexharsa...@gmail.com> wrote:
> 
> Parameters don't keep their values across threads, and since the plot library 
> needs to re-draw the plot when it is rotated or zoomed, it saves parameters 
> for later use in a different thread, where the drawing actually happpens.  
> There is an explicit list of parameters that are saved and restored, they are 
> listed in 
> https://github.com/racket/plot/blob/8dcfd7745e2595b8d517fd8cd7c59510efab84a9/plot-lib/plot/private/common/parameter-groups.rkt
> 
> Could you post some code illustrating what you are trying to do and does not 
> work?
> 
> Alex.
> 
> On Thursday, August 2, 2018 at 10:58:35 AM UTC+8, Carlos Lopez wrote:
> Hello Racket friends,
> 
> I was playing with the plot module (which is very nice, btw) and discovered 
> that the parameter plot-decorations? is ignored when plotting to a new window.
> 
> The file plot3d.rkt (plot\plot-gui-lib\plot\private\gui) is where 
> plot-new-window? makes a distinction of the cases and this is where I got 
> rather confused.
> 
> Inside plot3d.rkt, the function plot3d-snip has an internal helper function 
> make-bm, preceded by curious step that stores the values of the 
> plot-parameters in a variable that the helper function then uses to recall 
> them. This is the gist of it:
> 
> (define (plot3d-snip renderer-tree ...)
>                      ...
> 
>   (parameterize ([plot-title          title]
>                  ...)
>     (define saved-plot-parameters (plot-parameters)) ; <- store parameters
>     ...
>   
>     (define (make-bm anim? ...)
>       (parameterize/group ([plot-parameters  saved-plot-parameters] ; <- 
> recall parameters, why?
>                            ...)
>         ...))
>  ...)
> 
> 
> The function for plotting into a frame did not have such a step but has the 
> same structure with make-snip as the helper function so I added the 
> store/recall step, and with it, plot does respect the value of the parameter.
> 
> (define (plot3d-frame renderer-tree ...)
>          ...             
> 
>   (define saved-plot-parameters (plot-parameters)) ; <- store parameters
>   
>   (define (make-snip width height)
>     (parameterize/group ([plot-parameters saved-plot-parameters]) ;<- recall 
> parameters
>     (plot3d-snip renderer-tree ...))
>   )
> 
> A quick printf also showed that the parameters have a different value between 
> the outside and the inside of the helper functions.
> 
> Now, this behavior is expected, otherwise the solution would not have been 
> present in the same file; my question is why is it behaving this way? how is 
> the helper function seeing the value of the parameter from the initial 
> definition and not the one being set before invoking plot3d?
> 
> To add to my confusion, I made this simple test in which I tried to copy the 
> previous behavior, and it behaves as I expect, but differently to the plot3d 
> case.
> 
> #lang racket
> 
> (module m racket
>   (provide (all-defined-out))
> 
> (define test-param (make-parameter #t))
> 
> (define (f)
>   (define (g)
>     (test-param))
>   (g)))
> 
> (require 'm)
> 
> (f)
> 
> (test-param #f)
> 
> (f)
> -----
> #t
> #f
> 
> Thanks for reaching the end of this long question :)
> 
> Carlos
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to