Received: from webgate.proteosys.de (mail.proteosys-ag.com [62.225.9.49]) by lucy.proteosys (8.11.0/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id f5BDDOf12310 for ; Mon, 11 Jun 2001 15:13:24 +0200 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f5BDDOp26532 . for ; Mon, 11 Jun 2001 15:13:24 +0200 MIME-Version: 1.0 Received: from mail.Uni-Mainz.DE (mailserver1.zdv.Uni-Mainz.DE [134.93.8.30]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f5BDDNU05185 for ; Mon, 11 Jun 2001 15:13:23 +0200 (MET DST) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F278.4B517200" Received: from mailgate1.zdv.Uni-Mainz.DE (mailgate1.zdv.Uni-Mainz.DE [134.93.8.56]) by mail.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id PAA07062 for ; Mon, 11 Jun 2001 15:13:22 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mail.listserv.gmd.de (mail.listserv.gmd.de [192.88.97.5]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f5BDDMU05181 for ; Mon, 11 Jun 2001 15:13:22 +0200 (MET DST) Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <10.FA14AC91@mail.listserv.gmd.de>; Mon, 11 Jun 2001 15:09:30 +0200 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 497680 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Mon, 11 Jun 2001 15:11:49 +0200 Received: from ix.urz.uni-heidelberg.de (mail.urz.uni-heidelberg.de [129.206.119.234]) by relay.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id PAA15918 for ; Mon, 11 Jun 2001 15:09:40 +0200 (MET DST) Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by ix.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id PAA83456 for ; Mon, 11 Jun 2001 15:09:40 +0200 Received: from algonet.se (franklin.tninet.se [195.100.94.106]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f5BD9a113790 for ; Mon, 11 Jun 2001 15:09:37 +0200 (MET DST) Received: from [195.100.226.135] (du135-226.ppp.su-anst.tninet.se [195.100.226.135]) by franklin.tninet.se (BLUETAIL Mail Robustifier 2.2.2) with ESMTP id 87578.264969.992franklin-s1 for ; Mon, 11 Jun 2001 15:09:29 +0200 In-Reply-To: Return-Path: X-Sender: haberg@pop.matematik.su.se x-mime-autoconverted: from quoted-printable to 8bit by relay.urz.uni-heidelberg.de id PAA15919 Content-class: urn:content-classes:message Subject: Re: \InputTranslation Date: Mon, 11 Jun 2001 14:09:26 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Hans Aberg" Sender: "Mailing list for the LaTeX3 project" To: "Multiple recipients of list LATEX-L" Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4124 This is a multi-part message in MIME format. ------_=_NextPart_001_01C0F278.4B517200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 00:10 +0200 2001/06/11, Lars Hellstr=F6m wrote: >In this case, I suspect >the labels should be thought of as being nestable with separate markers = for >beginning and end, so that each token list that is formed gets = delimited by >matching begin and end labels that record the current context of the = token >list they were extracted from. ... > then it doesn't matter if it is inserted into a French context table = of >contents. Upon being written to an external file, the labels should be >converted to suitable markup. This is what also I am saying: If one makes sure to nest those = localization contexts consequently, the logical part of it should be fairly straightforward. >An interesting question is whether these labels should be explicit = tokens >or be hidden from the user (i.e., argument grabbing and things like >\futurelet look past them). Making them explicit tokens would probably >break tons of code. This is the hard part, how the localization contexts should be defined = in the input, so as to be convenient for the user. >As for what the labels should be to the user, I think a scheme of = making >them integers is pretty useless (how they are implemented is of course >another matter). Localization numbers would be as accessible to the user as input = encoding numbers, that is, normally the user would not use them at all. = Standardized localization numbers also requires that the localization specs can be = made so specific that one normally would not bother to override (parts of) = them. > A better idea would be to make them some kind of property >lists, i.e., containers for diverse forms of information that are = indexed >by some kind of names. The normal way is to make a lookup table, that is, a type of = environment. One then looks up a name recursively up through the tables towards the = top for the first occurrence, just as in any computer language defining contexts. However, as a matter for implementation, one would not want to carry = that much information around. Further, nothing really says that different localizations will have the same setup up of variables. So there must be = a way to first identify which localization to use, and from that proceed = to lookup variables. > Creating new label values from old by copying the >values and then changing some would be useful when defining dialects. The picture that I have in my mind is that all (standard) localization specs should be loaded (at need) in parallel; it is then easy to define = a customized localization spec by picking variables from already defined ones. Alternatively, one defines entirely new localized variables. Note that there is a difference in behavior: If I define my own = localized dictionary, it will not change when any other localization dictionary is updated. But if I define my localized dictionary on top of an already defined dictionary, then the dictionary I use will be updated when the already defined dictionary is updated. These are different types of behavior, and I think one must accomodate = for both. >The main problem I see with context labels is that of when they should = be >attached, This is the difficult one. > I can think of at least three different models: > >1. Labels must be present in the input (e.g. encoded using control >characters). ... >2. Do as today, i.e., context switches are initiated when commands are >executed. Perhaps a hybrid: Localization labels are not of Unicode, but it may be possible to define such formats using a suitable extension of the Omega translator, and LaTeX may decide to use such formats for writing and reading .aux files and the like. One the other hand, one wants to have convenient context switches within the LaTeX language itself. Whether one uses long formats such as ... or shorter, character based formats, is probably just a question of optimization. Hans Aberg ------_=_NextPart_001_01C0F278.4B517200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: \InputTranslation

At 00:10 +0200 2001/06/11, Lars Hellstr=F6m = wrote:
>In this case, I suspect
>the labels should be thought of as being nestable = with separate markers for
>beginning and end, so that each token list that = is formed gets delimited by
>matching begin and end labels that record the = current context of the token
>list they were extracted from.
...
> then it doesn't matter if it is inserted into a = French context table of
>contents. Upon being written to an external file, = the labels should be
>converted to suitable markup.

This is what also I am saying: If one makes sure to = nest those localization
contexts consequently, the logical part of it should = be fairly
straightforward.

>An interesting question is whether these labels = should be explicit tokens
>or be hidden from the user (i.e., argument = grabbing and things like
>\futurelet look past them). Making them explicit = tokens would probably
>break tons of code.

This is the hard part, how the localization contexts = should be defined in
the input, so as to be convenient for the = user.

>As for what the labels should be to the user, I = think a scheme of making
>them integers is pretty useless (how they are = implemented is of course
>another matter).

Localization numbers would be as accessible to the = user as input encoding
numbers, that is, normally the user would not use = them at all. Standardized
localization numbers also requires that the = localization specs can be made
so specific that one normally would not bother to = override (parts of) them.

> A better idea would be to make them some kind of = property
>lists, i.e., containers for diverse forms of = information that are indexed
>by some kind of names.

The normal way is to make a lookup table, that is, a = type of environment.
One then looks up a name recursively up through the = tables towards the top
for the first occurrence, just as in any computer = language defining
contexts.

However, as a matter for implementation, one would not = want to carry that
much information around. Further, nothing really says = that different
localizations will have the same setup up of = variables. So there must be a
way to first identify which localization to use, and = from that proceed to
lookup variables.

> Creating new label values from old by copying = the
>values and then changing some would be useful = when defining dialects.

The picture that I have in my mind is that all = (standard) localization
specs should be loaded (at need) in parallel; it is = then easy to define a
customized localization spec by picking variables = from already defined
ones. Alternatively, one defines entirely new = localized variables.

Note that there is a difference in behavior: If I = define my own localized
dictionary, it will not change when any other = localization dictionary is
updated. But if I define my localized dictionary on = top of an already
defined dictionary, then the dictionary I use will be = updated when the
already defined dictionary is updated.

These are different types of behavior, and I think one = must accomodate for
both.

>The main problem I see with context labels is that = of when they should be
>attached,

This is the difficult one.

> I can think of at least three different = models:
>
>1. Labels must be present in the input (e.g. = encoded using control
>characters).
...
>2. Do as today, i.e., context switches are = initiated when commands are
>executed.

Perhaps a hybrid: Localization labels are not of = Unicode, but it may be
possible to define such formats using a suitable = extension of the Omega
translator, and LaTeX may decide to use such formats = for writing and
reading .aux files and the like.

One the other hand, one wants to have convenient = context switches within
the LaTeX language itself.

Whether one uses long formats such as <begin = french> ... <end french> or
shorter, character based formats, is probably just a = question of
optimization.

  Hans Aberg

------_=_NextPart_001_01C0F278.4B517200--