Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by h1439878.stratoserver.net (8.14.4/8.14.4/Debian-2ubuntu2.1) with ESMTP id t631Vihp023291 for ; Fri, 3 Jul 2015 03:31:46 +0200 Received: from relay.uni-heidelberg.de ([129.206.100.212]) by mx-ha.gmx.net (mxgmx107) with ESMTPS (Nemesis) id 0M83OH-1YoN1W1F6f-00vjhB for ; Fri, 03 Jul 2015 03:31:39 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id t631TvLX000787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jul 2015 03:29:57 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [127.0.0.1]) by listserv.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id t62M15Lm001902; Fri, 3 Jul 2015 03:29:57 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 12313485 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Fri, 3 Jul 2015 03:29:57 +0200 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by listserv.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id t631TuMx014384 for ; Fri, 3 Jul 2015 03:29:56 +0200 Received: from homiemail-a30.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id t631Tn6w000748 for ; Fri, 3 Jul 2015 03:29:53 +0200 Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id D829B21DE59; Thu, 2 Jul 2015 18:29:48 -0700 (PDT) Received: from [192.168.1.130] (104-159-222-85.dhcp.eucl.wi.charter.com [104.159.222.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: tex@seanallred.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 80B2021DE58; Thu, 2 Jul 2015 18:29:48 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_A6F04BB0-C880-443F-91E2-3A98A9EDD30F" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Message-ID: Date: Thu, 2 Jul 2015 20:29:47 -0500 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Sean Allred Subject: expl3 and input parsing To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Envelope-To: X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=V3; X-GMX-Antivirus: 0 (no virus found) X-UI-Filterresults: notjunk:1;V01:K0:04qFo+qYH8k=:VDlwj9ee6mS8pWH1AZ1jjYzbB3 sVZGmuhWY6EWv16+tw4SVRwv6WnShnoPf0POHpuwp+IV6esgDc+Tlj9OtF8GRR9e0i8s2CO9r rlmy4YlcCrCdNz0oSj/rnm32XxNtCELQpeNoiQo2v50PwhqgT4NGCRHuoossaIf05FCorVLuu CA+IfurfFyRIfcWK9JXxny8KYhv9ce6dmhLTnWJ4HVUAH5zgQnZzE1HPLL01H2Ue5yXbIdYhO 2PpHPuggpS7HqrSv7MgkmTuXhbFwQeBR9d94DNDX2mZ7hnECNuN8lyv8q5g6nksPRXmthBXb0 +x0MaceLMXtaY6kQD2Q1Lnuf85Viph+dkMtoH/M2sA11PChZq8yTE6s+bT6q5E8TpMG7240Un RRfMB8jhX2cBkHVH3jn4ayscQVTSbz+3GhghtxHCzk2VyATzJFaMnwniS2cwT0nVuLwDskdWQ UPGxP2M2fEeNlda2yMoY4u4YvAw2zke06OTA3cLLrLFqMgr9P702jBx0JnWEul9ilz052dovP u+0taNtA7w5FiMv9l1DI9VxBIf2blo25WqBDq0OZDPXoeyul4kXO3BCOdLxRoKX/2cGO/RHLq y9zE/SV0zv62EI9D3IS9HeubWaoYxgkuovGkzwgNNsJ3AGGLPT/HdMJpm9TbbaQG+bL92/KkM qrVgEA3Un/peZIdN56FR79PjbyNaHDlhNQkczumq+7jzXaZwVM6XmEje0EfFqkpYPDG7lH602 1XUTZhE7p0dyQVAyZQQ3PC9WOrdDxpUB+WDouqXpXlAe4ehmdIZbLGe2PsCtL7NhWhoG9L3x3 wLF1APWVnfBriPI33TGkLV1mhfC1E0QB9UHS8AqtUO1YyoIEKK4xES5c1qrxsIXEE6Ac90Ms/ mvb3KubzHVLb5mcfHSic+g8w7Ktv6hMtVt4oOSrIbyiZWdt/UHiOA0XO9oAT/Ob62SY8A6TNR n98OXWM2TkSMuWHQgF6Q67op2Rt62t7RIDWG9V6qRbW6ATOPOYzCrlnmnfreeceVlVe4vyGbW a2DnDkSLAlQfHTbuKYlSHvCCOUFU8lu+kTJf4b+fT4c2P6D8DB6F/iIWTzqcuD5MftM4pOXFg oNFOVxcBFemwi1SZgYJXLhDrnnC4RE0bNWxWkhFvKgsjUrUwgAD1hEty5qChzalMOy0pJU4QV kvGXdfjWYMlXsil13uHwlyI3dL2awokdEiNz9SP2DPKWpNwdkzzVajv3i95YzmszG74FjRZ4b O9ic5EGGMtIFEwrFFs9PDMOdYkiCTscMefGyTcOgvOS8CWCNrdzABZ3sDB/Ge2CGHYC7IPMfJ +jmrn80tvL/F/PQWxnf/fAtCzUy/pQHK0nnC4J/ACKaTZHnGGthgUgvigO+iU7lGKs2oqeJ6n 20NlXr0k8gpda8jBtrgvWi7z5Qau1TJY6HH5Mxtmo2j4EhhyyDH9orC3iVHS5S8OMGfT/aus2 Aq/bq6pbht61E3QPuYgMoxyzXVT5YkXHko28SJ1UfGJ/yFq9Gj X-UI-Loop:V01:HN+aF6+LNo8=:lD6ptfWv2HCUduR5V/j0XHMACFVEJhS+fPcGcWvOg5g= X-UI-Out-Filterresults: notjunk:1;V01:K0:F3vQ7f3sIZA=:17Hr2Up/WAKh7cTlbqXkov EFYy5N5LFNMi6BJz8/XhdmGBigCQJYjv69fU4gO+NigPIZtyTDSG51bK9vFnH6j6I/5qhBFmu R5QCpReW+Z7js8t4KYjnb/T8wkxv2Q2GFqRkgdHsBP20HRW1MH1E0ylDakUrl7b9SJMyTKyxx 99LAI7eMrycigzJ5fCreZhOm1HNE9kkltf8JrziyNy9Un7MbipHW7jjPpY2nKE6+3icfjlpZ1 GzZm9CD8f82LtxMxavjFohd2R7nHstywe38I6LNGyB8/HgNRyejdO99Yq55RIDvCaWHoJNFsh pq5lb1TpNTMVn857A3NgeLtI/C2i+EY2QQSPD+3PiAvJf437ct24Rk0FoaqmPE0P9O4u0SVOl 1XFG3m/o+Q6UkodtzcfumqRRuNLcPF9JumtHZ3/tSrcNKnowgHWobbgbefdEg2EpnDCW+JasR J3nCS2Sl77PJhS2URwYutI/qsjGlrkAhSlCfUVEfqAG+u0N9bGKK X-Scanned-By: MIMEDefang 2.71 on 85.214.41.38 Status: R X-Status: X-Keywords: X-UID: 7742 --Apple-Mail=_A6F04BB0-C880-443F-91E2-3A98A9EDD30F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello all, Long story short, I=E2=80=99ve written a general parser for the key: type [=3D default], [=E2=80=A6] format that xtemplate uses. Since this seems to be what at least LaTeX3 = is heading toward, I wrote the parser so that it could be applied to a = multitude of situations (even xtemplate itself, I think). In a sense, it = is generic in that it can handle any input of this type, but is = specialized *to this type* of input. I=E2=80=99ve named the function = \parse_dictionary:nn, which takes the input as #1 and the parsing logic = as #2: \parse_dictionary:nn { key-1: type-1 =3D default-1, key-2: type-2 =3D default-2, } { \tl_show:N \l_parse_dictionary_key_tl \tl_show:N \l_parse_dictionary_type_tl \tl_show:N \l_parse_dictionary_value_tl } Does the kernel have philosophical room for a =E2=80=98parsing=E2=80=99 = module, or should this be relegated to a separate expl3 module (like = termmenu, lt3graph, etc.)? This I ask because, from my perspective, the = kernel tends toward pure programming and low-level typesetting (from a = =E2=80=98physical world=E2=80=99 perspective; i.e. doing what l3coffin = does in the real world isn=E2=80=99t that difficult, but convincing TeX = to do it is nothing short of a world-wonder). Input parsing doesn=E2=80=99= t really fit that scope. On the other hand, separate talks of what = l3color will be (someday) make it seem like such functionality would = prove useful in the kernel. I suspect this is just a misunderstanding on = my part, though =E2=80=94 I don=E2=80=99t think complex input parsing = should be a part of the core expl3 language. Aside, I can=E2=80=99t think of any more member functions for such a = module off the top of my head, but it seems silly to have a one-function = module. Is there a better way to go about organizing this? For those interested, I=E2=80=99ve posted the snippet here: = https://gist.github.com/vermiculus/3a343630c74bc90fc0c4 = All the best, Sean Allred --Apple-Mail=_A6F04BB0-C880-443F-91E2-3A98A9EDD30F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello all,

Long story short, I=E2=80=99ve written a general parser for = the

    = key: type [=3D default], [=E2=80=A6]

format that xtemplate uses. Since this = seems to be what at least LaTeX3 is heading toward, I wrote the parser = so that it could be applied to a multitude of situations (even xtemplate = itself, I think). In a sense, it is generic in that it can handle any = input of this type, but is specialized *to this type* of input. I=E2=80=99= ve named the function \parse_dictionary:nn, which takes the input as #1 = and the parsing logic as #2:

    = \parse_dictionary:nn
      = {
        key-1: type-1 =3D = default-1,
        key-2: = type-2 =3D default-2,
      = }
      {
  =       \tl_show:N \l_parse_dictionary_key_tl
        \tl_show:N = \l_parse_dictionary_type_tl
      =   \tl_show:N \l_parse_dictionary_value_tl
 =     }

Does the kernel have philosophical room for a =E2=80=98parsing=E2= =80=99 module, or should this be relegated to a separate expl3 module = (like termmenu, lt3graph, etc.)? This I ask because, from my = perspective, the kernel tends toward pure programming and low-level = typesetting (from a =E2=80=98physical world=E2=80=99 perspective; i.e. = doing what l3coffin does in the real world isn=E2=80=99t that difficult, = but convincing TeX to do it is nothing short of a world-wonder). Input = parsing doesn=E2=80=99t really fit that scope. On the other hand, = separate talks of what l3color will be (someday) make it seem like such = functionality would prove useful in the kernel. I suspect this is just a = misunderstanding on my part, though =E2=80=94 I don=E2=80=99t think = complex input parsing should be a part of the core expl3 = language.

Aside,= I can=E2=80=99t think of any more member functions for such a module = off the top of my head, but it seems silly to have a one-function = module. Is there a better way to go about organizing this?

For those interested, = I=E2=80=99ve posted the snippet here: https://gist.github.com/vermiculus/3a343630c74bc90fc0c4

All the = best,
Sean Allred

= --Apple-Mail=_A6F04BB0-C880-443F-91E2-3A98A9EDD30F--