To eval or not to eval

[lihebi]

In Geiser document, there's a section To eval or not to eval. The main idea is to facilitate incremental development. by allowing users to evaluate code inside the context where it is defined (instead of top-level). This effectively re-defines the bindings in-place. This approach of course has some cons, but I think this is useful to provide the option.

I also noticed the recent update to the document here about "the hopeless top-level", so probably you already have some idea about whether this is desirable. The re-definition involving macros is of course trickier, re-definition of functions should be relatively smooth.

I think the way Geiser implemented this is completely on racket/scheme side, by keeping aware of namespace and context for evaluation. In Jupyter, different notebooks and file editors can be associated with the same kernel session. Thus I think this may be implementable. I'm looking into this, but I'm not sure when I can figure it out.

What do you think about this?

[rmculpepper]

What are you suggesting, in terms of concrete Jupyter interactions?

[lihebi]

Suppose that I opened foo.rkt in JupyterLab's editor with the following:

;; foo.rkt
(provide foo)
(define (bar) 1)
(define (foo) (bar))

And I opened a jupyter notebook with

;; in notebook cell
(require "foo.rkt")
(foo)

I run (foo) in a cell and get 1, unsurprisingly.

Later, I found that I would love to update the behavior of bar to return 2 instead. I made that change from 1 to 2, and right click in the editor, choose "create console for this file" and select the previous notebook racket session. The I select the new definition of bar and hit ctrl-enter to evaluate it.

Now, if some magic happens, I would love to run the (foo) in the notebook again and see 2.

[rmculpepper]

Thanks for clarifying. That might be possible. Here are some of the ingredients necessary for that to work:

• the "foo.rkt" module must have been compiled with compile-enforce-module-contants set to false. So that module couldn't be pre-compiled with raco make, and IRacket would have to change to set the parameter to false.
• the JupyterLab editor would have to communicate to the kernel that the evaluation that redefines bar is in the context of the "foo.rkt" module. I don't remember seeing a way to do that in the Jupyter protocol description that I've read, but maybe I missed it.

Something similar is possible using Racket's default terminal interface (called xrepl) and the enter! command, which uses dynamic-rerequire in its implementation. You might find it interesting to play with those features.

[lihebi]

Thanks for pointing out the directions, I'll experiment with this.