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

[Joris van der Hoeven]

> > 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.
> 
> Well, it is also necessary to use 'define-public' to mark publicly
> accessible definitions.

I was rather thinking about :export, because we will have several
TeXmacs-specific defines (tm-define, etc.), but you are right that
we use this too somehow.

> Also it seems that 'use-syntax' might also be required to have correct
> support for macro definitions. There have been some discussion about
> that on guile-user lately (I did not really understand what it was
> about, though).

Possibly, but that is less urgent than general purpose
error reports (we still can't get file names, line numbers, etc.).

> > 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 am unsure that will work. Esp, I fear that symbols introduced by
> macro expansion must be public.
> 
> Well, I do not think I really understand how macros affect the
> compilation process, so I am maybe plain wrong.

We will rely heavily on macro expansions anyway, so if a compiler can't
handle this, then we will not be able to use that compiler...

> > 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.
> 
> I suppose we could have bit of discussion on that mailing list...

Yes, there has been a partial answer (see their public archives),
but it still does not work for me :^(((

> >  However, I still could not figure out how this works. The Guile
> > documentation is *really bad*.
> 
> Less so than it used to be. At least 1.6 do have a somewhat complete
> documentation (compared to the non-existent documentation in 1.3.4 and
> the grossly incomplete documentation in 1.4).

That is true, but it are precisely the subtle points which are
badly documented. For a general reference manual on scheme,
I don't need their documentation...

> > > > 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?
> 
> http://doc.trolltech.com/2.3/qaction.html
> 
> The idea is to associate all GUI-related data for a given command in
> one object. That includes icon, menu label, tooltip, shortcut etc.
> 
> What is currently a bit unclear to me is how should different keymaps
> styles be handled. Defining shortcuts in actions emphasizes
> centralization of related information, defining shortcuts
> separately emphasizes common keychord patterns in one keymap. Both are
> good things...

Yes, this seems to be more or less the same thing,
although our mechanism is more extensible, applicable to all kinds of
functions and it will be compatible with the DRD paradigm.

Also, I do not think that we should associate keyboard shortcuts and
menu entries to actions, because this information is better grouped
together in dedicated keyboard and menu files for specific modes.
Nevertheless, help text, checkmark-info, icons?, etc. which are
independent from specific modes should be attached to actions.

> > > >   tm-macro              define a macro
> > > 
> > > Do you mean a Scheme macro? Why is there a need for an extension?
> > 
> > Assigning properties to the macro.
> 
> I understand that, but (except maybe for documentation) I do really
> see how that is relevant.

Precisely: for documentation. Also, certain macros may behave
like functions, although they are not really functions
(think about the way we plan to deal with environments).

> If I understand well,
> 
>   (lambda () foo)
> 
> evaluates to the binding of foo in the compilation context of the
> lambda. So that does not preclude customization of foo by changing the
> binding.

Exactly.

> That is different from
> 
>   (let ((bar foo)) (lambda () bar))
> 
> which evaluates to the value of foo at compilation time (because it
> uses its own protected binding).

Maybe, I never tried that...
In any case, I will use the lambda-closures you mentioned above.