You illustrate my point precisely: for the implementor, parameters provide a
low-effort way of adding knobs and buttons without having to thread arguments
through every call. Unfortunately, with parameters you also get surprising
behavior related to threads and re-entry, because this kind of kno
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-
I use parameters a lot when designing a library which provides customizable
behaviors.
Instead of having an (init) procedure in which users can setup stuff for
the library, I provide parameters, which are way more flexible.
For example, I'm designing an emulator in which you can have memory
ad
On 8/2/2018 1:24 PM, 'John Clements' via Racket Users wrote:
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 a
'John Clements' via Racket Users wrote on 08/02/2018 01:24 PM:
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
construc
5 matches
Mail list logo
