LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Classic View

Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

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

Print Reply
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
Date: Thu, 6 Jan 2011 11:30:55 -0800
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
MIME-Version: 1.0
Message-ID: <[log in to unmask]>
In-Reply-To: <[log in to unmask]>
Content-Type: multipart/alternative; boundary="0-1337557118-1294342255=:3455"
From: Paul Thompson <[log in to unmask]>
Parts/Attachments: text/plain (2088 bytes) , text/html (2926 bytes)
There are of course many issues, backward compatability not least among them.  

I use SAS a lot.  They have a macro system which is very very similar to the 
command system of LaTeX.  What they did was set up a structure in which 
positional arguments for macros (commands) would be found as well as named 
arguments.  So, if you had a macro call, you could have both.  The positional 
arguments would be first (arguments without = signs) and then you could have 
named keyword-style arguments.  That way, they gradually moved the entire 
process from the positional to the keyword-oriented, while maintaining backward 

 Paul Thompson

From: Frank Mittelbach <[log in to unmask]>
To: [log in to unmask]
Sent: Thu, January 6, 2011 12:11:59 PM
Subject: Re: variable opt arg delimiters [was: Defining a ...]

Paul Thompson writes:
> The optional argument thing could be better handled by using named arguments.  

> So, for \parbox, which has optional and mandatory arguments, we currently have 

> \parbox[pos][height][inner-pos]{width}{text}
> This is mindlessly confusing in many cases.  Why not have 
> \parbox{pos=t,height=something,innerpos=t,width=something}{text}
> The use of named arguments is vastly superior to positional arguments, 
> especially when optional arguments can be specified.  

ah, the old argument between verbosity an ability to remember. Don't get me
wrong, I side with you on that one Paul, but there are times where I prefer

In any case this is one of the reasons why we worked hard on separating the
different layers so that a clean replacement of top-level syntax is always
being possible and easy. In that respect xparse is nothing other than
providing one such interface (resembling the LaTeX2e one, but generalized) as
an example, but it was never meant at "the interface" for a future LaTeX

But it is, in my opinion, a good start while everything is happening on top of
the 2e context anyway. and for a while at least this is where the expl
language and anything built from it will live.