Some questions about Chez.

[Massimiliano Gubinelli]

Hi all,

 I'm trying to understand Chez, in particular to use it to run the Scheme code in GNU TeXmacs (www.texmacs.org) which has two specific features (originally implemented on top of Guile): a module system and globally overloadable procedures. My current plan is to implement TeXmacs module system with Chez modules, essentially because I want the interactive top-level to be accessible from within the modules but I want to retain control of the exported symbols. However I cannot find a  way to "introspect" a module for the list of the exported bindings. E.g. is it possible to access this information from within the module (and make it available outside the module via some mechanism)? Since libraries can be queried for the exported symbols and there is the apropos function I imagine that there should be some infrastructure for such introspection. Somebody can give me some pointers/suggestions?

Another question I have is: is there some pedagogical example on how to use the expander to implement a different language on top of Chez? As far as I understand this is what Racket does, but I was hoping I should not dive into they large codebase to understand the principles... or should I?

Many thanks

Best

Max

[Jens Axel Søgaard]

Hi,

I am curious, the current module system used by TeXmacs, is that the same as
the current  module system used in Guile?

For context (for the Chez Schemers):
https://texmacs.github.io/notes/docs/scheming.html

PS:
I have fond memories of TeXmacs - I used to write my masters thesis years ago.

/Jens Axel

--
You received this message because you are subscribed to the Google Groups "chez-scheme" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chez-scheme...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/chez-scheme/d5c59522-e51d-49be-a8b4-6b723a1cb068n%40googlegroups.com.

--

--
Jens Axel Søgaard

[Massimiliano Gubinelli]

Hi,

On 10. Jan 2021, at 18:11, Jens Axel Søgaard <jens...@soegaard.net> wrote:

Hi,

I am curious, the current module system used by TeXmacs, is that the same as 
the current  module system used in Guile?

Our modules start with (texmacs-module .. ) but of course this is a macro build on top of Guile (module ...). But we do not do anything fancy. Essentially modules export some bindings with define-public or define-public-macro and the modules are bring in (maybe lazily not to affect interactivity) into an interactive top-level which is where the call from C++ to Scheme happen and where are also evaluated all the Scheme code needed to typeset the documents (documents can contain TeXmacs macros which renders content via calls to Scheme). Scheme is used to perform various kind of conversions (TeXmacs from/to LaTeX or HTML), or to programmatically describe the GUI (menus, keybindings, documentaiton...). I've had some experience to adapt our module system on top of S7 (which is quite dynamic, so this was not a problem) and I have some half-backed code on top of Chibi (using environments and some introspection tool to manage the export lists). I've also a port of TeXMacs to Guile 3 (compiled) which require a good dose of eval-when because we use a lot of procedures within macros, so we have to instruct the compiler to bring them in at the right moment.

For the moment I've managed to embed Chez and start the program but of course all the Scheme code require still the appropriate compatibility layer, so for the moment I'm concentrated in finding a solution for the modules. Chez modules seems ok for that. Libraries are not so good for me because I would like to bring in visibility the interactive top-level and as far as I understand this is not allowed in libraries.

If introspection is not possible, then an alternative would be to preexpand the scheme files to detect the export declarations and collect the symbols. However I still do not understand well enough the expansion step to do it.

[When I solved the module problem I need to attack the problem of our second facility: globally defined overloaded functions: i.e. any module can redefine certain global bindings to add some more behaviours (e.g. conditionally on the present status of the editor, certain procedures can behave differently).]

Max

For context (for the Chez Schemers):
https://texmacs.github.io/notes/docs/scheming.html

PS:
I have fond memories of TeXmacs - I used to write my masters thesis years ago.

PS: I'm glad you appreciate it. I also use it everyday for my work (teaching/research). :) Also the blog you link above is completely written in TeXmacs and then converted to HTML. 

[Jens Axel Søgaard]

Hi, 

Thanks for explanation.

Our modules start with (texmacs-module .. ) but of course this is a macro build on top of Guile (module ...). But we do not do anything fancy. Essentially modules export some bindings with define-public or define-public-macro and the modules are bring in (maybe lazily not to affect interactivity) into an interactive top-level which is where the call from C++ to Scheme happen and where are also evaluated all the Scheme code needed to typeset the documents (documents can contain TeXmacs macros which renders content via calls to Scheme).

Since you mention "interactive top-level" it sounds like you can represent TeXMacs modules with Chez Scheme environments?
Environments have the operation   environment-symbols.

I am no expert in Chez Scheme, but I wouldn't be surprised if there already exists alternative module systems for Chez.
 

[When I solved the module problem I need to attack the problem of our second facility: globally defined overloaded functions: i.e. any module can redefine certain global bindings to add some more behaviours (e.g. conditionally on the present status of the editor, certain procedures can behave differently).]

The price of globally defined overloaded functions is that the compiler might now produce as efficient code 
as it would have with a more static approach.
 

For context (for the Chez Schemers):
https://texmacs.github.io/notes/docs/scheming.html

PS:
I have fond memories of TeXmacs - I used to write my masters thesis years ago.

PS: I'm glad you appreciate it. I also use it everyday for my work (teaching/research). :)

 

Also the blog you link above is completely written in TeXmacs and then converted to HTML. 

I should have guessed that!

/Jens Axel 

[Massimiliano Gubinelli]

Dear Jens,

On 10. Jan 2021, at 19:12, Jens Axel Søgaard <jens...@soegaard.net> wrote:

Hi, 

Thanks for explanation.

Our modules start with (texmacs-module .. ) but of course this is a macro build on top of Guile (module ...). But we do not do anything fancy. Essentially modules export some bindings with define-public or define-public-macro and the modules are bring in (maybe lazily not to affect interactivity) into an interactive top-level which is where the call from C++ to Scheme happen and where are also evaluated all the Scheme code needed to typeset the documents (documents can contain TeXmacs macros which renders content via calls to Scheme).

Since you mention "interactive top-level" it sounds like you can represent TeXMacs modules with Chez Scheme environments?
Environments have the operation   environment-symbols.

Yes, indeed this is how I proceeded with Chibi. But somehow this approach has a couple of drawbacks in my use-case: first, you cannot modify any of the top-level bindings since you would evaluate the module into an environment created with (copy-environmente *texmacs-toplevel*) or something like this. This problem can be circumvented by using an indirection (i.e. via boxes). The second problem is that we use the an (export ...) form to export the symbols and this is a reserved keyword in Chez Scheme and a syntax violation to use it, so in this case I would have to pre-expand the module in order to replace it with something else. I would have preferred to use the export/import mechanism already implemented for modules/libraries and not rewrite it, but surely is doable.

I am no expert in Chez Scheme, but I wouldn't be surprised if there already exists alternative module systems for Chez.
 

I would hope so, this could give me some hints. As I mentionel I would really avoid to dive into Racket's alternative module implementation if not necessary... (but if somebody points out to me some readable account that would be great).

[When I solved the module problem I need to attack the problem of our second facility: globally defined overloaded functions: i.e. any module can redefine certain global bindings to add some more behaviours (e.g. conditionally on the present status of the editor, certain procedures can behave differently).]

The price of globally defined overloaded functions is that the compiler might now produce as efficient code 
as it would have with a more static approach.

That's not a bit concern for us. I think in  a relatively large interactive application like TeXmacs is more important to devise mechanism to keep the information local and not disperse the implementation of some features over the whole codebase. Our mechanism allow to implement different features in different modules and affect very different area of the program. For example if you want to implement a math mode, then you need hooks into the keyboard handler and into the macro expander and also into the menu code, the overloading mechanism that we have is quite up to this task. An interpreted scheme like Guile 1.8 or S7 is fast enough for these features. What I hope to gain with Chez is the ability to have faster conversion code and being able to move some of the critical C++ parts into Scheme, but not sacrificing too much in interactivity. Is important the the user or somebody not very familiar with Scheme is able to implement extensions to TeXmacs via new modules / plugins. See for example here

https://texmacs.github.io/notes/docs/previews.html

how preview for references (like \eqref{} or \cite{} in TeX) are implemented as a library. 

Best

Max

[Chris Vine]

On Sun, 10 Jan 2021 19:12:14 +0100

Jens Axel Søgaard <jens...@soegaard.net> wrote:

[snip]

> Since you mention "interactive top-level" it sounds like you can represent
> TeXMacs modules with Chez Scheme environments?
> Environments have the operation environment-symbols.
>
> I am no expert in Chez Scheme, but I wouldn't be surprised if there already
> exists alternative module systems for Chez.

The direct equivalent to guile modules is chez scheme's R6RS libraries
(similar to but different from R7RS libraries). I have no idea whether
they will be of any use for the case in issue.

[Massimiliano Gubinelli]

Hi,

The problem with libraries is that they are "sealed off" so I cannot inject bindings from the outside environment unless I package them as libraries, which I do not know do to programmatically (as chez does for the standard libraries).

Currently I'm trying to use environments to load my modules separately, this mostly works: I prepare the environment with all the "standard" bindings (including foreign functions exported by the C++ code) and the load texmacs module and collect public symbols.

I've still some problems with the fact that copy-environment do a "static" copy of the original environment, so any new binding created there is not reflected right-away in the module I'm loading, but I can come up with something which propagates the binding manually. Also I'm exploring the possibility of using syntax identifiers to pick up the global bindings locally.

Can somebody point me out to some example of using a different expander for the code than sc-expand, I would like to have in my code reserved keywords like 'export' which is not allowed by the standard expander. At the moment i go around simply renaming export as tm-export in the source files but I would like a less intrusive way to construct a custom language on top of chez scheme.

Max


> --
> You received this message because you are subscribed to the Google Groups "chez-scheme" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to chez-scheme...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/chez-scheme/20210110193702.ced9c30d9296d7c0150361ee%40gmail.com.

[Jens Axel Søgaard]

Den søn. 10. jan. 2021 kl. 17.43 skrev Massimiliano Gubinelli <m.gub...@gmail.com>:

Hi all,

 I'm trying to understand Chez, in particular to use it to run the Scheme code in GNU TeXmacs (www.texmacs.org) which has two specific features (originally implemented on top of Guile): a module system and globally overloadable procedures. My current plan is to implement TeXmacs module system with Chez modules, essentially because I want the interactive top-level to be accessible from within the modules but I want to retain control of the exported symbols. However I cannot find a  way to "introspect" a module for the list of the exported bindings. E.g. is it possible to access this information from within the module (and make it available outside the module via some mechanism)? Since libraries can be queried for the exported symbols and there is the apropos function I imagine that there should be some infrastructure for such introspection. Somebody can give me some pointers/suggestions?

I had to read up on how modules are implemented. Take a look at "Extending the scope of syntactic abstraction"

https://www.semanticscholar.org/paper/Extending-the-scope-of-syntactic-abstraction-Waddell-Dybvig/c05887b0ef6362b56e88e9eaa0386e5540d99012

If I understand correctly, the module construct is handled by the expander - and there is no runtime
representation of a module (so there is no way, at runtime to get a list of exported bindings for a module).

I do think that you can use the existing module to implement your tm-module abstraction though.
There are some examples in the paper of implementing other abstractions on top of the existing modules.

As far as I can tell, you can use Chez top level values to implement the global variables you need.

However, I see TeXmacs use old-style define-macro for macro definitions.
That may be a problem in a system with different both runtime and expand phases.


With respect to top level values used from libraries, I tried a few experiments, 
and I think it is possible to get there.

;;; ENVIRONMENT

(define e (copy-environment (scheme-environment)))  ; mutable
(set-top-level-value! 'e e e)                       ; make sure we can refer to e after
(interaction-environment e)                         ; using it.

;;; MUTABLE TOP LEVEL VARIABLES

; Example:
;   This definition will turn cons into a mutable variable
;      (define cons (top-level-value 'cons (scheme-environment)))

; SYNTAX
;   (make-mutable! id)   make id a mutable variable in the top-level environment
(define-syntax (make-mutable! stx)
  (syntax-case stx ()
    [(_ id)
     (syntax (define id (top-level-value 'id (scheme-environment))))]))

(make-mutable! cons) ; works
(set! cons cons)     ; check that cons in fact is mutable


;;; TOP LEVEL VALUES

; Top level values are stored in an environment "outside" the modules.

(define x 42)   ; define x in e


;;; UTILITIES
(define (displayln x) (display x) (newline))


;;; TOP LEVEL SUPPORT

(library (top-level (1))
  (export import-single-top-level import-top-level)
  (import (chezscheme))

  (define-syntax (import-single-top-level stx)
    (syntax-case stx ()
      [(_ id)
       (syntax
(define-syntax id
 (identifier-syntax (id             (top-level-value 'id))
    ((set! id expr) (set-top-level-value! 'id expr)))))]))

  (define-syntax (import-top-level stx)
    (syntax-case stx ()
      [(_ id ...)
       (syntax
(begin
 (import-single-top-level id)
 ...))])))


;;; TEST LIBRARIES

; The library `foo` tests assignment and reference to a top level value
(library (foo (1))
  (export foo)
  (import (chezscheme))
  (define (foo)
    (set-top-level-value! 'x 43)    ; assignment to top-level-value
    (top-level-value 'x)))          ; reference  to top-level-value

; The library `bar` attempts to improve the syntax
(library (bar (1))
  (export bar)
  (import (chezscheme))
  (define-syntax x (identifier-syntax (x             (top-level-value 'x))
     ((set! x expr) (set-top-level-value! 'x expr))))
  (define (bar)
    (set! x 44)   ; assignment to top-level-value
    x))           ; reference  to top-level-value

; The library `baz` uses the library `top-level`
(library (baz (1))
  (export baz)
  (import (chezscheme) (top-level))
  (import-single-top-level x)
  (define (baz)
    (set! x 45)   ; assignment to top-level-value
    x))           ; reference  to top-level-value

; The library `qux` uses the library `top-level`
(library (qux (1))
  (export qux)
  (import (chezscheme) (top-level))
  (import-top-level x)
  (define (qux)
    (set! x 46)   ; assignment to top-level-value
    x))            ; reference  to top-level-value


;;; RUN

(displayln x)     ; 42 expected

(import (foo))
(foo)
(displayln x)     ; 43 expected

(import (bar))
(bar)
(displayln x)     ; 44 expected

(import (baz))
(baz)
(displayln x)     ; 45 expected

(import (qux))
(qux)
(displayln x)     ; 46 expected


(exit)


/Jens Axel

[Jamie Taylor]

On Jan 11, 2021, at 3:37 AM, Massimiliano Gubinelli <m.gub...@gmail.com> wrote:

Can somebody point me out to some example of using a different expander for the code than sc-expand, I would like to have in my code reserved keywords like 'export' which is not allowed by the standard expander. At the moment i go around simply renaming export as tm-export in the source files but I would like a less intrusive way to construct a custom language on top of chez scheme.

If the place where you want "export" as a reserved word is inside some other syntax that you have defined (like texmacs-module) then there's no need to use a different expander.  The syntax transformer can fully traverse whatever body the user supplied and swap out "export" for "tm-export".  If the source isn't inside a macro you control, then it is definitely possible to have Chez read files with a completely different front-end (i.e., different reader) and do arbitrary transformations before producing scheme code to send to the expander, but that doesn't sound like what you want to do.  (And my examples for that are proprietary so I can't talk about them in more than general terms anyway.)  If you do need to do arbitrary transformations on s-expressions to convert them from your input language to scheme to be evaluated then maybe you want something more like the definition of "include" (as described in the manual: https://scheme.com/tspl4/syntax.html#./syntax:s48) but with an added transformation to the input value.

I'm not quite sure what you're trying to accomplish, and while I'd rather be spending much more time in the world of nice soothing parentheses the Real Job™ doesn't leave nearly enough time for that, so I haven't dug in the the TeXmacs sources to see what they look like... so the following observations might be completely useless to you.  But maybe one of them will help or give you an idea.

You can create a library programmatically by evaluating a library form.  (You can even replace existing libraries, but the new definitions only apply to things that import them later... very easy to get yourself confused when you're doing iterative development that way.)

If you really want arbitrary global definitions then the top-level-value stuff that Jens described is the way to do that.

If your "globals" are really a fixed (although possibly quite large) set of identifiers that you want accessible from everywhere, you can define them all in a library and import that library everywhere you want it.  In order to make them mutable values, you'll need to do the boxing yourself.  (I suggest using identifier-syntax if you want to make it more or less transparent to the client code.)  As a side note, mutable values are boxes anyway in the runtime, so you shouldn't be losing much in terms of efficiency.

Hope this helps,

Jamie

[Massimiliano Gubinelli]

Jens, Jamie,

 thanks for the multiple suggestions. I think I've finally unraveled some of the constraints in my codebase and come up with a solution which seems (at least partially for now) to work. 

I use syntax-identifier and define-top-level-{value,syntax} to handle the semantics of our global symbols and a mix of environments and load to set up our module system. 

I will try to explore the mechanism of include if I would need some further "wrapping". The syntax-case stuff  is all very interesting.

For the moment I'm fighting crashes in the glue code with our C++ side. It was written for Guile which do not move around scheme objects... I think I need some rethinking there...

An aside note: I've even discovered a "trick": when using copy-environment then bindings cannot be modified from the copied environment to the original one. However if the binding has been imported from a module then both environments will refer to the same binding and modifications are shared. That is the following works:

(module (a)

 (define a 10))

(define b 20)

(define e (copy-environment (interaction-environment)))

(eval '(set! a 20) e)

(eval '(set! b 40) e)

a ; -> 20

b ; -> 20

 

Maybe it will come useful to somebody.

Best,

Max

[Jamie Taylor]

On Jan 13, 2021, at 4:00 PM, Massimiliano Gubinelli <m.gub...@gmail.com> wrote:

For the moment I'm fighting crashes in the glue code with our C++ side. It was written for Guile which do not move around scheme objects... I think I need some rethinking there...

In case you haven't found it yet, "lock-object" will prevent the Chez garbage collector from moving a specific object.

http://cisco.github.io/ChezScheme/csug9.5/smgmt.html#./smgmt:s36

[Massimiliano Gubinelli]

Yes, I noted thanks. I was trying to have a small C++ class lock and unlock things for me as I enter C++ land but is not even compiling yet ... work in progress.

On another side: I'm slowly learning Scheme and I noticed the following basic fact, take the definition of include in TSPL, it uses a loop of the form

(let f ([x (read p)])
(if (eof-object? x)
(begin (close-port p) '())
(cons (datum->syntax k x) (f (read p))))))))

which is not tail recursive in f as far as I understand. Is this so? And in the case, why it is not a problem? I would expect to run out of stack if the file is really big. I've tried to write a tail recursive version but it seems to me that I need reverse, which I think has the same problem. Another approach I can think of would need mutable pairs. What I'm missing?

Best,

m

[Massimiliano Gubinelli]

Dear Jens,

 thanks a lot for all the example code. Two/three remarks on libraries and modules:

1) I've looked into the expander and it seems to me that libraries in Chez are implemented on top of modules (I might be wrong), so there should be some code which introspect the bindings in order to implement library-exports. However these mechanisms are not made available for modules. 

2) A problem with libraries and modules is that, the docs says that definitions should come before initialization code, which is not the case in the way texmacs modules are written (at the top-level). So for the moment I'm stuck with reading the files with load (which evaluate one expression at the time).

3) I've read all the papers on syntactic abstractions, they are really interesting and beautiful. There is even a paper on a module system designed for interactive programming:

Tung, SH.S., Dybvig, R.K. Reliable interactive programming with modules. Lisp and Symbolic Computation 9, 343–358 (1996). https://doi.org/10.1007/BF01806317

which I do not understand if is/can be implemented in Chez. It would seem to be part of what I would have needed. Somebody know a bit more about the history of this proposal?

Best,

Max

ps: On a side: if some Schemer is interested in writing fun code, TeXmacs has plenty of possibilities :) We currently have 100.000 lines of Scheme (and 3x of C++) performing such diverse tasks as convertion from/to HTML, GUI construction and a full-fledgded editor for vector graphics. It would be nice to have a rewrite of the graphical editor for example, or an extension to it. 

[Ricardo G. Herdt]

Hi Massimiliano,

you're right that that's not tail-recursive and could cause problems
with large files. A straightforward way of transforming it into a
tail-call recursive function is to add an extra argument to 'f', where
you pass the temporary result into recursive calls, and then reverse the
result like you said. 'reverse' can also be implemented with
tail-recursion, for example:

(define (my-reverse lst)
(let loop ((remaining lst)
(result '()))
(if (null? remaining)
result
(loop (cdr remaining)
(cons (car remaining)
result)))))

For more details I suggest reading this chapter in SICP:

http://sarabander.github.io/sicp/html/1_002e2.xhtml#g_t1_002e2_002e1

Cheers,

Ricardo

[Jens Axel Søgaard]

Den tor. 14. jan. 2021 kl. 09.53 skrev Massimiliano Gubinelli <m.gub...@gmail.com>:

On another side: I'm slowly learning Scheme and I noticed the following basic fact, take the definition of include in TSPL, it uses a loop of the form

         (let f ([x (read p)])
            (if (eof-object? x)
                (begin (close-port p) '())
                (cons (datum->syntax k x) (f (read p))))))))

which is not tail recursive in f as far as I understand. Is this so? 

Yes, this is not tail recursive.
 

And in the case, why it is not a problem? 

I would expect to run out of stack if the file is really big. 

I've tried to write a tail recursive version but it seems to me that I need reverse, 

which I think has the same problem.  

Another approach I can think of would need mutable pairs. What I'm missing?

I see two things, why this is harmless. The first might be the most surprising :-)

First thing: It's impossible to get a stack overflow in Chez Scheme [1].
When the stack is full, a stack handler copies the contents of the stack to the heap, and installs a new stack.
Racket has the same mechanism in place. To be honest, I don't get that Python and JavaScript still have a stack limit.

The second thing: The purpose of that specific loop is to turn a file containing source code into

a syntax object. Now the compiler and runtime system is expected to handle large source files,
so unless the file can't fit in memory, it is not a problem that the file is large (and hence
the syntax object).

[1] The release notes from version 3.0 says this was introduced in 1989. 

 

 

[Jens Axel Søgaard]

Den tor. 14. jan. 2021 kl. 10.16 skrev Massimiliano Gubinelli <m.gub...@gmail.com>:

Dear Jens,

 thanks a lot for all the example code. Two/three remarks on libraries and modules:

1) I've looked into the expander and it seems to me that libraries in Chez are implemented on top of modules (I might be wrong), 

so there should be some code which introspect the bindings in order to implement library-exports. 

However these mechanisms are not made available for modules. 

I don't know much about the current Chez Scheme expander (except what I learned from the chapter in Beautiful Code).

     http://www.cs.indiana.edu/~dyb/pubs/bc-syntax-case.pdf

However, I think that `libraries` is the intended mechanism if runtime introspection is needed.

2) A problem with libraries and modules is that, the docs says that definitions should come before initialization code, 

which is not the case in the way texmacs modules are written (at the top-level). 

So for the moment I'm stuck with reading the files with load (which evaluate one expression at the time).

Do you have code that use set! before define?
I don't think that has been allowed for ages (in the RnRS specs).

If you haven't come across, this part of the docs, check section 9.3 and 9.4.

https://cisco.github.io/ChezScheme/csug9.5/use.html#./use:s93
 

3) I've read all the papers on syntactic abstractions, they are really interesting and beautiful. There is even a paper on a module system designed for interactive programming:

Tung, SH.S., Dybvig, R.K. Reliable interactive programming with modules. Lisp and Symbolic Computation 9, 343–358 (1996). https://doi.org/10.1007/BF01806317

which I do not understand if is/can be implemented in Chez. It would seem to be part of what I would have needed. Somebody know a bit more about the history of this proposal?

I think that's a question for Kent.

/Jens Axel

 

[Massimiliano Gubinelli]

Thanks,
my mistake was to naively think that reverse is not tail-recursive, which is false of course, as you show me.

m

> --
> You received this message because you are subscribed to the Google Groups "chez-scheme" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to chez-scheme...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/chez-scheme/90bec280a66499ab366e3f6bbe030a63%40posteo.de.

[Massimiliano Gubinelli]

On 14. Jan 2021, at 16:03, Jens Axel Søgaard <jens...@soegaard.net> wrote:

2) A problem with libraries and modules is that, the docs says that definitions should come before initialization code, 

which is not the case in the way texmacs modules are written (at the top-level). 

So for the moment I'm stuck with reading the files with load (which evaluate one expression at the time).

Do you have code that use set! before define? 
I don't think that has been allowed for ages (in the RnRS specs).

No, this does not happens but I could have definition intermixed with other expresions and as far as I understand this is not allowed (but I haven't yet tried to do it...).

m

[Chris Vine]

On Thu, 14 Jan 2021 09:53:23 +0100
Massimiliano Gubinelli <m.gub...@gmail.com> wrote:
>> On 14. Jan 2021, at 00:15, Jamie Taylor <Jamie....@pobox.com> wrote:
>> In case you haven't found it yet, "lock-object" will prevent the Chez
>> garbage collector from moving a specific object.
>> http://cisco.github.io/ChezScheme/csug9.5/smgmt.html#./smgmt:s36
>>
>
> Yes, I noted thanks. I was trying to have a small C++ class lock and
> unlock things for me as I enter C++ land but is not even compiling
> yet ... work in progress.

Note also that in C or C++ you have access to Sdeactivate_thread() to
allow the garbage collector to do its worst, together with its antonym
Sactivate_thread(), and Slock_object and Sunlock_object. With
those, and scheme's lock-object and unlock-object, you should be able to
bend the garbage collector to your will.