Re: [Texmacs-dev] (Important for scheme hackers) TeXmacs tags become more stable

[Philippe Audebaud]

On Wed, Nov 12, 2003 at 01:33:40PM +0100, Joris van der Hoeven wrote:
> I more or less completed a major reorganization whose object is to

Thanks a lot Joris for all these explanations.

Following the CVS entries already helped me *a lot* already. Nevertheless:

>   1) Replace all EXPAND/VAR_EXPAND/HIDE_EXPAND/APPLY tags by
>      built-in primitives or COMPOUND tags. The second ones are
>      only used if the name of the COMPOUND tag is not a string.

still the  *meaning* of the COMPOUND tag  remains unclear to me.  Do you mean
this  tag wraps  around  anything  with is  not  a string  :  macro call  for
instance, etc ?? For sure not, otherwise it would be redundant maker...

And if, for example, I have to generate is from a program, what are the rules
to respect ?..

Wanting to go further yesterday,  I checked throughout the automatic material
generated in the cache/__blabla__ files,  but did not succeed in catching the
precise idea.

For instance, in the following example?

 (compound 
   "theorem*"
   (concat
     (translate "Notation" "english" (language))
     " "
     (compound "thetheorem"))
   (arg "body"))


>   2) A consequence of 1) is that the scheme representation now
>      perfectly matches the intern representation.

That's really  nice.  A  problem I  met some months  ago.  Together  with the
question of  how it  is possible to  know which  tags are so  called internal
tags, from the  scheme side, *statically* : by which I  mean without asking a
running TeXmacs about this property ?  In other words, is there a place where
is set of primitives of exported to the knowledge of scheme scripts? 

There remains  the question of how  do I compute  the path of a  subtree from
outside the TeXmacs world? Is the algorithm trivial now?

>   3) Drd properties can be associated to tags and exploited by
>      the editor.

I  checked the  related files,  and found  that a  lot of  various  pieces of
information is  actually bound to tags  via DRD. We'll see  that point latter
anyway.

As a matter of example, one could point out the underline/overline macros
which are associated properties with 'drd_props' in
'packages/standard/std-markup.ts'. 

> So  if you  wrote some  non-trivial  scheme code  for TeXmacs,  then it  is
> possible that you  have to update some parts of it,  especially if you used
> the APPLY tag.

There is a benefit for that, so that's ok!

> Fortunately, things should remain stable from now on though.
> 
> Let me explain 3) a bit. TeXmacs DRD's (Data Relation Definitions)
> are meant to become an enrichment of usual DTD's with additional
> logical structure. Whereas a usual DTD would mainly formalize which
> documents are correct (i.e. arities of tags and maybe constraints
> of which tags should be or cannot be used inside other tags),
> the DRD also contains information like "the user is allowed to
> place the cursor inside the n-th child of this tag" or "this tag
> is a block structure".

where hide_expand and the likes were examples in the ancient times ;) 

In  that sentence, I  see the  first property  has something  to do  with the
interactive edition within  TeXmacs ; while the second  is a static property,
providing some piece  of typing information somehow. I got  it, Joris ? These
two properties are really different from my point of view.

> Because of the macro facility of TeXmacs, it should also be noticed
> that DTD's and DRD's have to be extremely flexible, since they
> basically change each time when the user adds a new macro.
> So TeXmacs has to provide a mechanism which both
> 
>   1) Allows you to specify a very precise DTD/DRD which cannot
>      be altered by the user (example: certain forms in industry).
>   2) Allows the DRD to be updated in a user friendly way when
>      you define new macros or style files.
> 
> The solution I found for this problem is the following:
> TeXmacs style files will both specify style and DRD properties.
> (Consequence: there will be no clear distinction between style files
> and DRD files in TeXmacs. A style file may only contain formatting
> instructions, or DRD instructions, or both.)
> 
> Moreover, TeXmacs provides a high-quality and on-the-fly heuristic
> algorithm in order to automatically determine missing DRD properties
> merely from the definition of a macro. For example, if you write
> a macro like
> 
>       (assign "hi" (macro "name" (concat "Hi " (arg "name"))))
> 
> then TeXmacs will automatically recognize that "hi" has arity 1
> and that its only child is accessible. Nevertheless, if the user
> explicitly sets the DRD properties of a tag in a style file,
> then this will disable the heuristic determination of this property.

Nice heuristics. I saw some generated results in the system cache files.

> Little advantage is taken out of the DRD information right now,
> but in future versions, we plan to further enrich it and
> implement more reliable cursor movement, block structures,
> structured editing facilities, etc.

Which are certainly  required, at least for me... But  at this point, TeXmacs
is  already provided  with a  huge amount  of possiblities.   Maybe  times to
disseminate  these informations  and provide  examples  for the  sake of  the
developpers (at least)?
 
> Have fun, Joris

I do.
-- 
Philippe Audebaud