texmacs-dev
[Top][All Lists]
Advanced

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

[Texmacs-dev] Re: New way of adding dictionary entries


From: Joris van der Hoeven
Subject: [Texmacs-dev] Re: New way of adding dictionary entries
Date: Fri, 14 Feb 2003 12:12:39 +0100 (MET)

> I see that you now use (define-mapper) to manipulate the various
> dictionaries.  If I want to add entries to the tmtex-table-props-def
> dictionary, is the following the correct way to do it ?
> 
> (define-mapper tmtex-table-props-def
>   (rightchoice ((left.) "c" (right\}) #f))
>   (nixmatrix ((#{left\[}#) "c" (#{right\]}#) #f))
>   ...
> )

Yes, at the moment it is.

> I tried this and it seems to work, i.e., it doesn't destroy the existing
> tmtex-table-props-def entries like 'matrix, 'choice, etc.  The only
> reason I ask is that the semantics of the expression "define-mapper"
> would suggest that I am creating a brand-new mapper called
> tmtex-table-props-def, which could mean that any existing mapper by that
> name is obliterated by this new creation.  I couldn't find anything like
> 
> (append-to-mapper tmtex-table-props-def
>   (rightcho...

I agree that the names are still not optimal. I am trying to
find a minimal number of primitives with appropriate names.
There are several things which need to be dealt with:

        define-rules
        define-group
        define-mapper (variant: define-dispatcher)
        kbd-map
        kbd-wildcards
        define-menu
        menu-append!
        tm-define (variants: tm-macro, tm-routine, tm-interactive, ...)

The problem is that the semantics is quite different in each case.
The first three will be part of the DRD system (logical programming),
so they are really list of properties which are added in a database.
I might replace 'define-rules', 'define-group' and 'define-mapper'
by 'rules', 'group' and 'mapper'. This is OK for 'rules' and 'mapper',
but maybe not for 'group'.

The keyboard shortcuts are relative to user-defined predicates
for modes and they form a data-base. I think that the names are OK.

The menu commands define scheme variables at the moment,
so define-menu seems fine. I am not sure though whether
menus should rather be stored in a data-base too.
This would avoid name clashes of menu names with scheme variables.
It would also be good to extend the semantics so that we may
modify submenus, e.g. (menu-append! (file-menu "Page setup") ...)
We might want to have a menu-set! as well.

The last group of function definition commands tm-define, etc.
enables the user to associate data to functions. These data
will be managed by the DRD mechanism soon. The defined symbols
will be normal scheme variables though.

Another subtle point is how we want these things to interact
with Guile modules (not yet used yet). I am investigating
whether it is a good idea to add implicit rules to the DRD
system at each module declaration. This would permit to
reproduce the module dependencies and scopes in the DRD database.





reply via email to

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