[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Texmacs-dev] [TeXmacs] TeXmacs and Guile-2.0

From: Massimiliano Gubinelli
Subject: Re: [Texmacs-dev] [TeXmacs] TeXmacs and Guile-2.0
Date: Thu, 5 Sep 2013 16:35:15 +0200

Hi Triet,
 thanks a lot for all your work and support to port TeXmacs to Guile-2.0! We were in need of some Guile hacker to help us. I maintan a git mirror of the svn repository at gitorious so the guile-2.0 port can be forked easily from there. It would be nice to have your attempt as a git fork somewhere publicly accessible. 


On 5 sept. 2013, at 15:00, Triet Lai wrote:


I've made an attempt to port TeXmacs to guile-2 for some time (please see a patch included
in attachment). It's progressed slowly as I've got a fairly little time to work on
that. Here are some issues of building and running TeXmacs with guile-2 that I've

* Small C API change in guile-2:
  Such as introduction of `scm_t_subr' type in the 5th parameter of scm_c_define_gsubr() . I've added a new detection code in
  autoconf script to fix the signature issue.

* Changes in guile:
** Top level definition:

Guile-2 doesn't allow definitions are defined in _expression_ context. In other words,
definitions must be either:

- At the top level of a program, or
- At the beginning of the body of `lambda' and its derived forms such as: `let', `let*',
  `letrec' and `letrec*'

The simplest fix is: moving these definitions out of conditional expressions and using
`set!' in the expressions to bind the symbols to the desired `lambda's. For example:

(if foo?
  (define (bar arg) (noop))))

can be rewritten as:

(define bar #f)
(if foo?
  (set! bar (lamda (arg) (noop)))))

** Loading guile module behaves differently in guile-1 and guile-2:

Let say in the top-level of program we import a module:

(use-modules (my-module))

and in my-module.scm we have a hypothetical code:

(define-module (my-module))

The difference between guile-1 and guile-2 is the question of what modules that guile uses to
lookup the definition of `do-some-work'.

- guile-1: the current module up to the point of (define-module (my-module)) is the
  current module of top-level program, i.e.: (guile-user), so if `do-some-work' is defined
  in the top-level program, its definition can be found.

- guile-2: it creates a fresh module (i.e. unnamed module) before loading the file so
  current module is a fresh module up to the point of (define-module ...)
As a result, the (texmacs-module ...) macro no longer works in guile-2 since this macro is
defined in the top-level of program; only (guile) module is available at that point.

The heart of current TeXmacs module logic are in 3 macros and they are also the most
troublesome to run with guile-2:

- inherit-modules: it re-exports public definitions defined in various modules so that
  these definitions are easier to access "globally".
- texmacs-module: besides creating a new module, the macro also lets the current module
  access "global" definitions, which have been re-exported by prior inherit-modules
  (N.B. whilst it's convenient, I'd prefer to have an explicit control on importing
- tm-define: it provides mechanism to override a macro's definition depending on its
  context (i.e. contextual polymorphism).

In guile-1, the process of loading all TeXmacs modules at boot time is illustrated in the attached
figure tm-1.png (or you can use freemind to open the tm-1.mm file). The icon (1)
indicates current module in these places are mostly (guile-user) module.

To replace the usage of `texmacs-module' with `define-module' macro comes with guile, I've
re-organised the process a little bit (see attached figure tm-2.png or tm-2.mm):

- I've wrapped all glues into a separate module called (texmacs-glue). In the future, we
  might want to sub-divide the glues into several modules (e.g. dynamic libraries) and
  only load those needed depending on platform or configuration.
- I've created a new (texmacs-core) module where we will put important "global" macros and
  variables such as `inherit-modules', etc. It also re-exports all public glues defined in
- All modules (including the top-level) will need to use (texmacs-core) module explicitly.

In general, replacing (texmacs-module) with (define-module) is quite straightforward. But
the major problem that I'm having at the moment is to compile the expansion of `tm-define'
macro. Here is steps to quickly see the problem after applying the attached patch:

- Edit init-texmacs.scm & find this line:
  (include "kernel/boot/boot.scm")
- Add a following line after the above line and also comment out the rest of the file:
  (use-modules (tm-test))
- Here is the minimum content of tm-test.scm:
  (define-module (tm-test)
    :use-module (texmacs-core))
  (use-modules (kernel boot abbrevs)
               (kernel boot ahash-table)
               (kernel boot debug)
               (kernel texmacs tm-define))
  (tm-define (foo)
    (display* "bar"))
You'd see this error message:

;;; ERROR: build-constant-store: unrecognized object #<procedure nval head>

I've haven't got a chance to look deeper into that. I guess, looking at the output of macroexpand
for (tm-define ...) might give some hint why the compiler chokes there.


On Wed, Sep 4, 2013 at 11:42 PM, François Poulain <address@hidden> wrote:

Some weeks ago, I met some Scheme hackers, and a former Guile
maintainer. I talk with him about porting TeXmacs to Guile-2.0. He is
interesting in helping us to do the work (actually he already helped
me on some problems).

So I started a branch to port TeXmacs to Guile-2.0. It doesn't work at
all, but I hope it will. :)

However, I seen some arrangement in TeXmacs code in order to work with
Guile-2.0. So, can you tell me if you encountered peculiar problems, or
any useful advise ?


François Poulain <address@hidden>

PS: is address@hidden down?

Texmacs-dev mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]