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 >>]

 Sender: Mailing list for the LaTeX3 project <[log in to unmask]> Date: Sat, 4 May 2013 09:15:04 +0200 Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]> Message-ID: <[log in to unmask]> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit In-Reply-To: <[log in to unmask]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed From: Frank Mittelbach <[log in to unmask]> Parts/Attachments: text/plain (125 lines) 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 { }      { \UseTemplate... } Instead what we have now is   \DeclareDocumentcommand \foo { }      {         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