Received: from mail.proteosys.com ([213.139.130.197]) by nummer-3.proteosys with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Aug 2009 11:23:56 +0200 Received: by mail.proteosys.com (8.14.3/8.14.3) with ESMTP id n7E9NrPE028746 for ; Fri, 14 Aug 2009 11:23:55 +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 n7E9JRt9006329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Aug 2009 11:19:27 +0200 Received: from listserv.uni-heidelberg.de (localhost.localdomain [127.0.0.1]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id n7E83Ab7010508; Fri, 14 Aug 2009 11:19:19 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 15.5) with spool id 297582 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Fri, 14 Aug 2009 11:19:19 +0200 Received: from relay2.uni-heidelberg.de (relay2.uni-heidelberg.de [129.206.210.211]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id n7E9JJQS020399 for ; Fri, 14 Aug 2009 11:19:19 +0200 Received: from mordell.elzevir.fr (mordell.elzevir.fr [92.243.3.74]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id n7E9J78s006187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 14 Aug 2009 11:19:11 +0200 Received: from roth.elzevir.fr (thue.elzevir.fr [88.165.216.11]) by mordell.elzevir.fr (Postfix) with ESMTPS id B269A35EC9 for ; Fri, 14 Aug 2009 11:19:08 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by roth.elzevir.fr (Postfix) with ESMTP id BD5F8BFEB for ; Fri, 14 Aug 2009 11:19:07 +0200 (CEST) User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 References: ,<1C09237E-F871-434B-9527-4C6A3F2CF6A0@gmail.com> X-Enigmail-Version: 0.95.0 OpenPGP: url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x50A89B42 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <4A852C0B.8080608@elzevir.fr> Date: Fri, 14 Aug 2009 11:19:07 +0200 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= Subject: Re: Named parameters in macros To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-ProteoSys-SPAM-Score: -6.599 () BAYES_00,RCVD_IN_DNSWL_MED X-Scanned-By: MIMEDefang 2.65 on 213.139.130.197 Return-Path: owner-latex-l@LISTSERV.UNI-HEIDELBERG.DE X-OriginalArrivalTime: 14 Aug 2009 09:23:56.0763 (UTC) FILETIME=[F2E14AB0:01CA1CC0] Status: R X-Status: X-Keywords: X-UID: 5925 J.Fine a écrit : > Thank you. It's not the only nice thing we can do. Here are some more: > > * Allow digits in control sequence names > * Allow period in control sequence names I think the naming scheme (at the programming level at leat) has been discussed previously and is now considered stable. Let's not re-discuss again and again points were decisions are already made. (And btw, I personnaly think the namign scheme in expl3 is good.) > * Allow '~' to produce a space /in all circumstances/ > What would be the purpose? > The LaTeX3 project has put much effort into naming conventions for control > sequences. I think having the ability to name parameters will bring > at least the same benefit. > I think realism should also be a key word if we ever want to be a stable LaTeX3. And I really would like to see it :-) >> it doesn't seem that important to me how we refer to >> arguments within a macro. > I agree with your (Will) argument and conclusion on this point. > Which is easier to type and to read? > \wibble.wobble_trip > \wibble_wobble_trip > It depends on your personal habits. The second one is perfectly fine for me. (After all, unlike most language, we have to type \ in the front of every "function", so let's not try to mimick other languages too much.) > We could even go further and implement something much more > like a real module system for macro programming. Something > that would raise load- or compile-time import errors, rather than > the current run-time error. > Again, let's be realistic. There is already some error handling done. Moreover, the distinction between load, compile and run time doesn't seem relevant for TeX. Manuel.