LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Classic View

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

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

Print Reply
"Mittelbach, Frank" <[log in to unmask]>
Wed, 3 Sep 2014 09:54:28 +0200
text/plain (44 lines)
On 21.08.2014 23:42, Joseph Wright wrote:
> On 20/08/2014 01:23, Allred, Sean wrote:
>> I've drawn up a syntax proposal
>> <> (as
>> an Org file) on GitHub:
> One thing I think to consider is the lesson of LaTeX(2e) in that a small
> number of positional-based mandatory arguments work well as a user.
> That's something I'd certainly expect to see in any new code too.

I agree but this is a document interface question and quite independent 
of the designer layer. There is no reason, whatsoever, that the 
transition from gui layer to designer layer couldn't turn positional 
arguments (and or a mixture of 2e type optionals) into anything on the 
designer layer, be it mandatory positional arguments or key/val pairs

> The issue with mixing up mandatory and optional arguments in an
> object/template set up is that this then looks less clear (how many
> arguments must a TeX-like document-level interface require?).

be careful with that: even the mandatory template args (that are now 
positional ones) do not translate to mandatory args on the user 
interface, there they might as well be optional and defaults are 
generated when passing them to the template so there isn't really much 
in terms or relationship of "mandatory" between the two layers.

> Almost
> certainly the number of truly *required* arguments will remain small,
> and while the case that a design should not be limited by TeX is quite
> true, and the same time a design interface that fundamentally fails to
> translate to a TeX-based user layer is a problem too.

The number of required args will indeed be small which is why I think 
the designer layer could implement them as mandatory positional args 
despite the inherited limitation of 9. However, given that this would be 
a one-time parsing effort between two layers I lean towards key/val here 
too as it will make the designer layer easier to read.

Neither way I see that this fundamentally fails to translate a TeX-based 
user layer.