LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
From: Hans Aberg <[log in to unmask]>
Date: Mon, 3 Mar 1997 12:13:55 +0100
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments: text/plain (33 lines)
Frank Mittelbach <[log in to unmask]> writes:

>...there is only
>one solution that would avoid that kind of deadlock which is to
>abandom TeX's parsing mechanism completely and writing your own parser
>within TeX (eg by making braces being ordinary characters etc). that
>is possible although incredibly slow even on fast machines and to do
>more than just a prove of concept type implementation you get
>dangerously close to proving that TeX is Turing complete.

  This is actually one way I contemplated, but I felt the effort not worth it:

  One idea might be making a new version of the command
    \def\name<parameter text>{definition text}
that picks up the parameter text, and is simulating the parsing TeX
normally does, but with suitabnle modifications, passing to some exception
text if something goes wrong, or whatever. This is not very easy to do in
TeX.

  One might use such a command, even though slow, in situations where the
TeX normal programming does not suffice. Second, if one would want to
extend TeX itself, making those extensions first implementable in TeX
itself would be a good idea, as it would not force people picking up a new
TeX implementation right away. So, even though this is not the group for
discussing TeX extensions (it is the group
    NTS-L Distribution list <[log in to unmask]>
), this might fuse the efforts of the LaTeX3 project, and such extensions
efforts.

  But you won't implement this very easily.

  Hans Aberg

ATOM RSS1 RSS2