Re: [Texmacs-dev] Some thoughts about the redesign of the Guile interface

[Joris van der Hoeven]

> The second thing is that a namespace-based module system is going to
> be used. AFAIK there is no Scheme standard for that. Not too old GUILE
> releases do have a useful module system (I do not know if it is even
> present in 1.3.4), but it only became really mature with guile-1.6.

I have been doing some experiments with 'define-module' and 'use-modules'
in guile 1.3.4 and this seems to work. I do not think that we will
need something more elaborate.

> > 2) Implicit environment information.
> >    In order to avoid subtle bugs and make everything thread-safe,
> >    it will be good to let all TeXmacs commands which use implicit
> >    environment information (like the current window or cursor position)
> >    depend explicitly on an environment. As David has pointed out before,
> >    this can be done using a clever use of macros.
> >    However, this also requires many changes in the C++ code.
> 
> I am still waiting for comments on my proposals. Actually I re-read it
> some time ago and I think there is quite some room for comments. For
> exemple I am not so sure that static scoping for environment switches
> would be a good default behaviour...

I think that I will go for the following scheme:

        (tm-command (fun args)
          body)

will define a private function 'fun$' (or 'fun-whatever')
which takes an additional (first) environment argument called 'ctx'
and a public macro 'fun' which calls the function 'fun$' with 'ctx'
as an additional (first) argument.

It will only be possible to change the environment using
'with'-like statements

        (with-cursor new-pos
          body)
        (with-buffer new-buf
          body)
        etc.

which will in fact be rewritten in a statement like (let ((ctx ...)) ...).
It is good to keep the interface simple and abstract as I propose here;
if we ever want to change implementation details, then that will be easy.

I think that there is no real need for special functions which
take cursor positions, buffers, etc. as arguments.
If really needed, then such functions can be written using
the 'with'-primitives, but I think that this is quite rare,
except for a few document modification routines.

> > Debugging facilities
> > --------------------
> > 
> > It becomes quite urgent to have better debugging facilities
> > for Guile/Scheme programs. The problem is that I did not
> > manage to find in the docs how to retrieve the file name and
> > line number where an error occurred. Someone has an idea?
> 
> I recently posted a very lenghty message to guile-users explaining my
> problems with 'trace' and 'backtrace'... Probably I will need to strip
> it down to get some answer.
> 
> I plan to experiment debugging with guile-1.6 (which among other
> things has much better documentation) in some near future.

I have been spending a whole morning in order to find out how to
retrieve the file name + line number in this 'better documentation' and
I also posted a message on the guile-users list. However, I still
could not figure out how this works. The Guile documentation
is *really bad*.

> > More generally, it would be good if we could automatically
> > retrieve the file name(s) and line number(s) of a piece of code.
> > This would allow us to create hyperlinks to the definitions
> > of functions in the online documentation.
> 
> I think that part does not belong in the language, but rather in a
> literate programming tool working on Scheme files, as I suggested in
> a previous message.
> 
> A good starting point is:
> 
>    http://www196.pair.com/lisovsky/scheme/lit/
> 
> Such a tool could also be abused to produce executable scheme so the
> documentation can be used reflexively.

I understand, but I do not agree. Since we will have a transparent
system to associate properties to procedures and macros,
documentation will be a natural part of that.

> > Here are some of the keywords I am thinking of:
> > 
> >   tm-define         define a function or symbol
> >   tm-command                define a function with an implicit environment
> 
> I do have some ideas on that issue. For example I think we should
> reuse the "action" abstraction used in Qt. Also, maybe these two
> forms can be combined in one, but I need more information on the
> module system to make a clear idea.

What do you mean by action abstraction?

> >   tm-macro          define a macro
> 
> Do you mean a Scheme macro? Why is there a need for an extension?

Assigning properties to the macro.

> >   tm-menu           define a menu
> >   tm-keymap         define or extend a keymap
> 
> I see that is related to the need of producing command closures at
> definition time. Again I think more information on the module system
> is needed.

We do not really need more information about the module system.
The only important thing is to generate a closure at definition time.
A well-designed module system should support this and my experiments
with the standard module system of Guile tend to prove that I am right.

> Also maybe we could use a simple ASCII file format to define menus and
> keymaps. I know that sound stupid, but Lisp is really scary to users.
> A syntax with less parenthesis (more Python-like?) could really help
> changing TeXmacs customization from an theoretical possibility to a
> practical tool for most users.

Rejected.

> Practically that could be made an extra feature. Built-in
> functionnality would use Scheme files, and users could use the easy
> syntax for customization... but then there would not be many examples
> of how to use the syntax...

Yes, as soon as the reorganization will be finished,
we should write good documentation.

> Of course, GUI-based customization would be much better, but currently
> that is still in a very distant feature (read future).

I am not sure about this 'of course', but let's read 'future'.