User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328
            Thunderbird/17.0.5
MIME-Version: 1.0
References: <517E353C.5050701@morningstar2.co.uk>           
            <CAFXs3kQUtzoSoPY-9mSkxQmpJZqaVCuhC5FviFxi-J1Bp+kyWw@mail.gmail.com> <517F75E8.7090900@morningstar2.co.uk> 
            <517F9214.9030103@residenset.net>           
            <517FCFEB.7030007@morningstar2.co.uk>
            <CACKZBPUQvMcLYRA=kAKUy=NLXU+OnC9NjUbhrNxBhgxmdSEX3A@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <5184B578.7080400@latex-project.org>
Date:         Sat, 4 May 2013 09:15:04 +0200
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Frank Mittelbach <frank.mittelbach@LATEX-PROJECT.ORG>
Subject: Re: Behaviour of \SplitArgument with missing input
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <CACKZBPUQvMcLYRA=kAKUy=NLXU+OnC9NjUbhrNxBhgxmdSEX3A@mail.gmail.com>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

Am 30.04.2013 19:20, schrieb Michiel Helvensteijn:
> On Tue, Apr 30, 2013 at 4:06 PM, Joseph Wright
> <joseph.wright@morningstar2.co.uk> wrote:
>
>> On where '-NoValue-' 'lives', ...etc...
>
> Your problem is that xparse has been trying to cater to two different
> target groups. It's meant to create document-level commands. But it's
> not clear what kind of environment it's meant to create them from.


you hit the nail on its head (or whatever the phrase might be :-)

on one hand xparse has taken a life on its own (because of being very 
useful in 2e context) and on the other hand the middle glue didn't got 
finished so far and thus the two went of (partly at least) in different 
directions.

Conceptually what sits in the middle is what I call typesetting 
elements. Those have a type/signature which is a bunch of inputs with 
some defined semantics (and such semantics could and should include that 
such objects be optional). So that layer should provide a way to say: I 
expect some optional input, provide me with data or tell me that nothing 
is coming.

The task of the interface layer (of which xparse would be one flavor) 
would then be to translate the user interface (e.g., brackets, stars, 
what have you) into the syntax of the class design layer.

A big point to note here (for me at least) is that therefore it should 
certainly not be

    \xparse_if_no_value:nTF

because it is not an xparse concept needed on the lower level, it is a 
core concept "from" the lower level.

If somebody writes an xhtml.sty interface that provides html like syntax 
for the same typesetting elements those translation would need to result 
in the same calls to the class design layer eventually.

What I originally thought was that this class design layer is being 
essentially described by the concepts of xtemplate (only that I do 
believe that we didn't quite got that right, first time around, so these 
days I consider xtemplate only a prototype that needs redoing).

So in a nutshell, the somewhat naive version of the interface was 
supposed to look like

  \DeclareDocumentcommand \foo {<arg spec> }
     { \UseTemplate... <normalized args> }

Instead what we have now is


  \DeclareDocumentcommand \foo {<arg spec> }
     {
        bunch of low-level expl3 code
        and/or 2e code
        and possible some xparse parsing control code such as 
\IfNoValueTF and the like
     }

so ...


> On the one hand, the LaTeX3 methodology recommends the use of xparse
> for document level commands (rather than the LaTeX2 \newcommand or the
> TeX \def). On the other hand, xparse doesn't offer a LaTeX3 syntax! It
> was obviously designed to be used independently from expl3. I do
> understand. The xparse functionality is useful to both LaTeX3
> programmers and other LaTeXers.

it wasn't designed to be independent of  LaTeX3 syntax, but it was 
designed to be independent of expl3 syntax (and in my opinion still should)

> As I see it, the 'correct' way to go about this is to follow your own
> methodology (I'm a fan of self-reference):
>
> *  Create a LaTeX3 library which provides xparse functionality; let's
> call it l3xparse. I'd expect to see functions like
> \xparse_new_document_command:Nnn, \xparse_split_argument:nn,
> \xparse_if_no_value:n(TF). Actually, a lot of potential \xparse_...
> functions probably already exist under a different name, like
> \bool_if:n(TF) for \IfBoolean(TF).
>
> *  Expose l3xparse with a thin layer of document-level commands. The
> result will be what you now call xparse. The cool thing is, you can
> actually use l3xparse to create that thin layer around itself.

I agree that there should be an l3UIfoundation library that provides 
functions for splitting  etc etc as they would be useful not just for 
implementing xparse but also for parsing other syntax schemes but it 
doesn't resolve the issue that there has to be that middle layer 
(eventually) and that middle layer should not be expl3 code

If this middle layer is not provided then in my opinion that would get 
us back to mix and match of class design of 2e where a lot of the 
"design" got buried into coding rather than cleanly decoupled.

That l3UIfundation would then also be the place that holds

   \uif_if_no_value:nTF

that could be used to implement the current xparse \IfNoValueTF (which I 
never like to be there really :-) or directly used in expl3 code in the 
command body as long as there is not middle layer worth talking about.

And eventually it would be used inside the code that makes up the middle 
layer.

My view of the world (in pictures):

Logical view architecture: 
https://dl.dropboxusercontent.com/u/55981144/l3architecturepictures/Logical%20View.png

Document class architecture: 
https://dl.dropboxusercontent.com/u/55981144/l3architecturepictures/document%20class%20architecture%20%28layers%29.png

list element example: 
https://dl.dropboxusercontent.com/u/55981144/l3architecturepictures/list%20example%202.png

regards
frank