LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

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

Print Reply
Subject:
From:
Frank Mittelbach <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Wed, 1 Jul 1998 23:41:22 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (58 lines)
beside "my please stop mail" i do want to explain why i think that a
module/submodule concept as suggested by Hans is doomed to failure if
applied all levels of programming within TeX.

essentially i said this already in my mail a few days ago but perhaps
it was not clear enough to people not having written large scale
low-level TeX.

Richard suggested at some point a syntax like \foo/bar_baz:nn and said
"with catcode 11 for / _ :" now that is beside syntactic sugar exactly
what we have now (where the statement is: the module name is the first
word up to an _)

it may be that this is better to read (although i doubt)[1] it but it is
not functionally offering anything new. and importantly it doesn't
offer what Hans has in mind (even though in some side remarks it
sounds as if he thinks one can combine the two)[2]

one of the main arguments for submodules (or class structures in OO
languages) is the ability to overload functions/procedures

and here is where it stops being usable. if the concept allows for
this than at runtime! the binding has to be changed and that means:

any expansion text of any macros can't contain something like
\foo/bar_baz:nn as above (ie a token) but it must contain things that
live on the module/submodule level ie is looked up by some internally
programmed module handling interface. and that will bring you to my
exponential growth in slowness.

i'm not going to repeat the other arguments about loosing the basic
expansion mechanism etc, which are at the heart of the low-level
functionality of TeX.

so while i think that the ideas itself are relevant to TeX, i'm
strongly convinced that they are relevant only to a high-level
language for producing the user interface, ie the document level.  and
that level should not at all deal with expand_after stuff or other
low-level TeX rubbish and consequentially there is no reason that these
languages should look the same or nearly the same if their concepts
are completely different.


frank


[1] and i don't think people should make too fast statements on this
without actually having worked with the language as is

[2] as i said several times: *prove* me wrong by giving me something
that i can run through initex which works, ie compiles at least simple
documents without needing a minute per page --- don't try to prove me
wrong by using applying gut-feeling from experiences in languages like
C++, Smalltalk, Java, Modula, you name it. We have heard these
arguments by now and we agree about their usefulness but we claim
(from our experience) that they can't and shouldn't be applied to that
level in TeX.

ATOM RSS1 RSS2