Am 30.04.2013 19:20, schrieb Michiel Helvensteijn:
> On Tue, Apr 30, 2013 at 4:06 PM, Joseph Wright
> <[log in to unmask]> 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
|
