My hot take is parameters and threads are equivalent-ish to
environment variables and processes -- with similar behavior, pros,
and cons.
The `parameterize` form ~= the env save/set/restore of fork without
the overhead of actually launching a process?
~~~
I've been doing a lot of work on racket-mode lately. Anything to do
with loading and expanding and evaluating code has a lot of options
that would be pretty painful to supply as function parameters
everywhere -- current-namespace, current-eval, current-custodian,
current-module-name-resolver, compile-enforce-module-constants,
compile-context-preservation-enabled, {instrumenting profiling
test-coverage}-enabled, current-prompt-read ... and on and on.
Plus it is extremely helpful to know that threads can use different
values and not stomp on each other -- say a thread running
read-eval-print-loop vs. a thread accepting TCP commands vs. the
main/original thread.
However that's just one point in codespace and I agree there are vast
spaces where function parameters are cleaner, simpler, and faster.
--
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.
