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

[david]

On Thu, Feb 06, 2003 at 02:42:02PM +0100, Joris van der Hoeven wrote:
> 
> 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.

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

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


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

After a bit of reflexion, I came to agree to that point too.

What annoyed me is that macros cannot be used as procedure parameters,
so an explicit lambda is required. But the explicit lambda is required
anyhow to support static scoping.


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


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


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

Well, we have discussed that IRL. For interested reader, it was decide
that procedure and macro properties would used for simple structured
documentation for use by the GUI (tooltips) and for documenting simple
customization.

Additional technical documentation for advanced customization and
developers would be written in comments.


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

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


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

Yes. Actually I missed the distinction between a 'binding' and a
'symbol value'.

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.

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

Binding semantics are really a great feature of Scheme, but it is also
a difficult one to grok in fullness.

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