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

[david]

On Thu, Feb 06, 2003 at 10:55:08AM +0100, Joris van der Hoeven wrote:
> 
> Local scoping
> -------------
> 
> As a general rule, the code has to be reorganized in such a way
> to use local scoping whenever possible (always). This occurs at
> two important places:

Oh yes!


> 1) Menu and keyboard actions, dispatchers
>    Currently, most actions are stored as unevaluated expressions,
>    which are evaluated using 'eval' whenever needed.
>    If we want to use the Guile/Scheme module system,
>    it will be important to construct the closures of
>    all actions at the time that they are being defined.
>    Otherwise, certain actions will not be evaluated using
>    the right context.

Yes!

The first thing I see here is that Scheme callbacks (in C++) will have
to use an opaque data type, maybe scheme_command. That will eliminate
a major performance and functionnality bottleneck in the current glue
system.

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.

A compatible way to handle modules is to make extensive use of
closures, but that is problematic for extensibility and debugging, so
adequate special forms need to be designed... references someone?

On a purely stylistic plan, I have been thinking that TeXmacs abused
'eval'. I am happy an alternate solution is being looked for.

 
> 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...


> 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.


> 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.


[...]
> Proposal
> --------
> 
> In the future, we will use the scheme module system in order to
> prevent name clashes and improve the debugging tools. We will define
> a few powerful macros for TeXmacs-specific language extensions and
> provide a corresponding syntax highlighting and automatic indentation
> file for emacs.
> 
> 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.


>   tm-macro            define a macro

Do you mean a Scheme macro? Why is there a need for an extension?

Or do you mean a typesetter macro? In that case I have the feeling we
miss some information. Is that related to your plan of making
typesetter primitives extensible?

>   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.

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.

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...

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


> The will also be several keywords related to the DRD extension and
> pattern matching, but more on this later.

We'll see. :-P

-- 
David Allouche         | GNU TeXmacs -- Writing is a pleasure
Free software engineer |    http://www.texmacs.org
   http://ddaa.net     |    http://alqua.com/tmresources
   address@hidden  |    address@hidden
TeXmacs is NOT a LaTeX front-end and is unrelated to emacs.