As discussed in https://github.com/hasu/emacs-ob-racket/pull/10, this PR rewrites ob-racket-runtime-typed.rkt to "simply re-export" the relevant symbols from ob-racket-runtime-private.rkt.
Typed Racket cannot import macros from untyped code (and vice versa), meaning that ob-racket-runtime-typed.rkt still has to explicitly reproduce the definitions of ob-racket-begin-print-elisp and ob-racket-begin-print-table. However, the underlying functions datum->elisp and datum->table are directly imported from ob-racket-runtime-private.rkt with the appropriate type signatures.
https://github.com/hasu/emacs-ob-racket/pull/10 mentions that the original version of ob-racket-runtime-typed.rkt had more restrictive type signatures than the untyped code had. This issue is no longer present in the new simplified code for ob-racket-runtime-typed.rkt, which indeed only assigns 2 very general type signatures.
Finally, I do not think that we incur a major performance penalty by introducing additional contract checks on the boundary between ob-racket-runtime-typed and ob-racket-runtime-private, because this boundary should be traversed at most once per evaluation of the code block, and the additional cost is probably very small compared to other costs associated with evaluating a code block.
As discussed in https://github.com/hasu/emacs-ob-racket/pull/10, this PR rewrites
ob-racket-runtime-typed.rkt
to "simply re-export" the relevant symbols fromob-racket-runtime-private.rkt
.Typed Racket cannot import macros from untyped code (and vice versa), meaning that
ob-racket-runtime-typed.rkt
still has to explicitly reproduce the definitions ofob-racket-begin-print-elisp
andob-racket-begin-print-table
. However, the underlying functionsdatum->elisp
anddatum->table
are directly imported fromob-racket-runtime-private.rkt
with the appropriate type signatures.https://github.com/hasu/emacs-ob-racket/pull/10 mentions that the original version of
ob-racket-runtime-typed.rkt
had more restrictive type signatures than the untyped code had. This issue is no longer present in the new simplified code forob-racket-runtime-typed.rkt
, which indeed only assigns 2 very general type signatures.Finally, I do not think that we incur a major performance penalty by introducing additional contract checks on the boundary between
ob-racket-runtime-typed
andob-racket-runtime-private
, because this boundary should be traversed at most once per evaluation of the code block, and the additional cost is probably very small compared to other costs associated with evaluating a code block.