LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Classic View

Use Monospaced Font
Show Text 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: Sat, 30 Aug 2014 18:52:39 -0400
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]> (Will Robertson's message of "Sun, 24 Aug 2014 11:23:25 +0930")
Content-Type: text/plain
From: Sean Allred <[log in to unmask]>
Parts/Attachments: text/plain (112 lines)
> On the other hand I do see Joseph's point that when you have just one
> or two actually mandatory arguments that writing the following is a
> bit ugly:
>
>     \UseInstance{crossref}{latex2e}{ label = #1 }
That's a fair point, but I would raise that this case is duplicated in
other style languages.  In CSS, we favor consistent syntax over ease of
use:

    pre .tex-comment {
      color: #BBB;
    }

vs. the TeX-style

    pre .tex-comment #BBB

simply because the extension of this pattern yields confusing
specifications:

    pre .tex-comment {
      color: #BBB;
      font-weight: bold;
      some: made-up;
      properties: for-the;
      purpose-of: example;
    }

would necessarily become

    pre .tex-comment #BBB bold made-up for-the example;

When you think about it, it's not that extreme of an example.  Like
templates, style sheets are written once and used many times over.
Clear definitions in the language are preferred over better pars in code
golf.  While it's awkward in the single-property case, the consistency
is worth it.  In the end, it's less for a new user to learn.

I'll take a stab at my own argument and say that, in the case of CSS,
*everything* is optional, so it's a poor choice for an example.  I hope
that this doesn't detract from what I'm trying to say, though :)

> So according to the situation you could have either
>
>     \UseInstance{...}{...}{arg one}{arg two}{arg three}
>
> or
>
>     \UseInstance{...}{...}{ arg-one=... , arg-two=..., arg-three=... }
>
> or even a combination of the two:
>
>     \UseInstance{...}{...}{arg one}{ arg-two=..., arg-three=... }
Were you able to take a peek at the proposal document I sent out?

    https://gist.github.com/vermiculus/d8ac080f3f8c7ec2bed6#file-idea-org

Given the limitations of purely positional arguments, I feel that I make
a pretty good case for keyval-based arguments.  Presuming the arguments
against positional arguments are persuasive, the language impurity
introduced by the hybrid option doesn't sit well with me.  If I were a
new user to the system, I would be confused that I could name some
arguments but I wasn't able to name the positional ones.  It just
feels... wrong :).

To clip a bit from the above-mentioned proposal, something like this
seems most inline with the existing paradigm:

    \DeclareObjectType { name }
      {
        first  : tokenlist ,
        middle : tokenlist ,
        last   : tokenlist ,
        first  : .required ,
        last   : .required ,
      }

or the more concise

    \DeclareObjectType { name }
      {
        first  : tokenlist! , %    bang => required
        middle : tokenlist  , % no bang => optional
        last   : tokenlist! ,
      }

A case that I just thought of is the case of dependent arguments ---
those arguments that are optional, but require an additional piece of
(normally optional) data to be used, such as `epithet` and
`epither-credit`, for example.  Perhaps something like

    \DeclareObjectType { chapter }
      {
        title : tokenlist!                     ,
        epigraph : tokenlist                   ,
        epigraph-credit : tokenlist!(epigraph) ,
      }

or

    \DeclareObjectType { chapter }
      {
        title : tokenlist                    ,
        title : .required                    ,
        epigraph : tokenlist                 ,
        epigraph-credit : tokenlist          ,
        epigraph-credit : .requires epigraph ,
      }

All the best,
Sean

ATOM RSS1 RSS2