[racket-dev] [plt] Push #23663: master branch updated

On 10/05/2011 02:36 PM, Neil Toronto wrote:
> On 10/05/2011 01:44 PM, Ryan Culpepper wrote:
>> On 10/05/2011 01:13 PM, ntoronto at racket-lang.org wrote:
>>> ntoronto has updated `master' from e1a82481d1 to 32d789d4f8.
>>> http://git.racket-lang.org/plt/e1a82481d1..32d789d4f8
>>> [...]
>>> ; fit-int : (number* -> number) (list-of (symbol number)) (list-of
>>> (vector number [number] number number)) -> fit-result
>>> (define (fit-int function guesses data)
>>> + ;; Require dynamically so the rest of 'plot' still works without
>>> libfit:
>>> + (define fit-internal (dynamic-require 'plot/deprecated/fit-low-level
>>> 'fit-internal))
>>> (let* ((independent-vars (- (procedure-arity function) (length
>>> guesses)))
>>> (f-of-x-y (cond
>>> [(= 1 independent-vars)
>>
>> Be careful with dynamic-require; it uses (current-namespace), which is
>> not necessarily the same namespace that the enclosing module was loaded
>> in. Specifically, you might get a different module registry, which can
>> lead to multiple module instantiations, which can lead to problems with
>> generative structs, etc.
>>
>> Also, with plain dynamic-require, if you build an executable ("raco
>> exe") it probably won't include the dynamically-required module.
>>
>> I recommend using lazy-require (from unstable/lazy-require) instead. It
>> handles both the namespace issue and the "raco exe" issue automatically.
>
> That is teh awesomes, so I've changed it. I had a couple other uses of
> dynamic-require, so I changed them to top-level lazy-requires as well.
>
> Any plans to support other kinds of objects than functions?

I could add support for binding a thunk on the client side that gets the 
value of a variable on the server side. For example:

(module a racket
   (define x 1)
   (provide x))

(lazy-require
  ['a
   (get-x #:get x)])

(get-x) ; => 1

I could make it even more transparent using an identifier macro; for 
example, x could expand into (get-x). It would change the behavior for 
functions from the current force-on-apply behavior to 
force-on-reference. I haven't decided whether I like that, yet.

I could implement both and let people vote with their keyboards :)

It will not work for macros. There are both superficial and deep reasons 
why not, and I hope to finish writing them up soon. ("Variable-like" 
macros are okay, like struct constructors and contracted exports.)

Ryan