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:
"J.Fine" <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Fri, 14 Aug 2009 07:16:29 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (77 lines)
Will Robertson wrote:
> On 13/08/2009, at 6:10 AM, J.Fine wrote:
>
>> Instead of writing, say,
>>    \def\centerline #1{\hbox to\hsize{#1}}
>> I'd like to be able to write something like
>>    \def\centerline #text{\hbox to\hsize{#text}}
>>
>> This is an example of named parameters in macro definitions.
>
> For the record, I agree that this would be a nice way to write arguments
> in TeX.

Thank you.  It's not the only nice thing we can do.  Here are some more:

  * Allow digits in control sequence names
  * Allow period in control sequence names
  * Allow '~' to produce a space /in all circumstances/

> But has writing #1, ##1, ####1 instead really ever stood in the
> way of writing TeX macros?

The LaTeX3 project has put much effort into naming conventions for control
sequences.  I think having the ability to name parameters will bring
at least the same benefit.

> I feel that from the document-level point of
> view, it's much more important to *input* the arguments as named
> parameters;

I agree.  But we're in a position now to improve programming practice,
while improving document practice (the LaTeX3 syntax) seems to be
a long way off.

> it doesn't seem that important to me how we refer to
> arguments within a macro.

I don't agree, and as I said above, there are other benefits.  Almost
every programming language uses '.' in names to indicate member
access (and in particular namespace).

Which is easier to type and to read?
   \wibble.wobble_trip
   \wibble_wobble_trip

   \pagesize.a4
   \pagesize_a_four

We could even go further and implement something much more
like a real module system for macro programming.   Something
that would raise load- or compile-time import errors, rather than
the current run-time error.

> \centerline{width=\hsize,text=...}
>
> This is where keyval-style processing has the upper hand to rigid macro
> arguments, and I think (despite the power of xparse) that we'll see much
> more gain from a standard and powerful keyval model than from a powerful
> way to define macros with complex argument types.

I'm all in favour of standardised key-value parsing and processing of attribute
lists.  SGML and XML have had it for years.

And like XML, I'd like to see the parsing available in all major languages, such
as C, Java, JavaScript, Lua, Perl, Python, and Ruby.  Let's not define a syntax
that only TeX and its descendants can understand.

[snip]

--
Jonathan




The Open University is incorporated by Royal Charter (RC 000391), an exempt charity in England & Wales and a charity registered in Scotland (SC 038302).

ATOM RSS1 RSS2