LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Proportional Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
From:
David Carlisle <[log in to unmask]>
Date:
Tue, 21 Oct 1997 16:43:45 +0100
In-Reply-To:
<v03110707b07144139223@[130.237.37.82]> (message from Hans Aberg on Mon, 20 Oct 1997 19:30:59 +0200)
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments:
text/plain (36 lines)
Hans writes.
  I think the LaTeX parameter style \newcommand[6]... is pointless. Should
  it not be scrapped in LaTeX3, only be allowed in compatibility mode?

You need to differentiate between commands aimed at document use, and
general latex programmers interface.

In documents, not allowing arbitrary argument syntax is one of the
great strengths of LaTeX. It is one of the things that allows latex
documents to be parsed by non-tex engines such as latex2html,
techexplorer, Scientific Word etc. Figuring out the argument to
\vspace is a whole lot easier than figuring out the argument to
\vskip.

Of course at a programming level one needs to use arbitrary TeX
delimited arguments, eg for parsing comma separated lists, or key
value pairs or whatever. However one could imagine a sufficiently rich
`programmers interface' which gave access to such constructs without
needing to do the most basic TeX macro expansion tricks that you
unfortunately need to do to code things for the present system.


To answer the original question

>   Should not \@ifdefinable be changed so that it does not check
>   \@ifundefined?

No. Changing the semantics of a command used in a large proportion
of latex packages is not a very safe thing to do.

Your analysis of the possibilities for defining/testing commands
sounds reasonable, but any implementation of such a thing should
use new names and keep clear of the old (existing) interface.

David

ATOM RSS1 RSS2