[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] Focusing the elide discussion
- To: Group finalising DDLm and associated dictionaries <[email protected]>
- Subject: Re: [ddlm-group] Focusing the elide discussion
- From: James Hester <[email protected]>
- Date: Tue, 18 Jan 2011 23:44:43 +1100
- In-Reply-To: <[email protected]>
- References: <[email protected]><[email protected]>
Thanks Brian for this thorough reply. How fortunate for us that England do not have high-speed trains. Now I'm just waiting for John W to give his thoughts. On Tue, Jan 18, 2011 at 11:05 PM, Brian McMahon <[email protected]> wrote: > Dear James > > Sorry for the delay in replying to this request. A long train > journey yesterday gave me the opportunity to review the > discussions on this point. In order of preference I would > rank the proposals as roughly: > > F' � �- requires least handling of special escapes > E � � - allows the generic handling of Unicode character set and > � � � �long lines as native CIF2 features (but only within "special" > � � � �i.e. triple-quote delimited strings) > > I think these allow embedding of any string in a reasonably clean way. > > C � � - I quite like, provided the post-elide escape could be a sequence > � � � �(e.g. borrowing from TeX, the trigraph "{} is read as a > � � � � double-quote; the literal sequence > � � � �<doublequote><open brace><close brace> would be represented by "{}{} > � � � �and any other sequence would have no special meaning). If those with > � � � �greater experience argue that this imposes too great a load on the > � � � �initial lexical scan, or can demonstrate that this leads too > � � � �quickly to a proliferation of unreadable punctuation marks, > � � � �this would drop quickly down the lilst of preferred approaches). > F � � - because I'm not sure what is gained just by protecting the > � � � �escape character everywhere; but on the other hand it may seem > � � � �an easy procedure to describe to potential implementors > A > B � � - carries an unwelcome overhead in requiring the escape character > � � � �(here, backslash) to be encoded everywhere > > D > > P � � - brings in unnecessary syntactiv overhead when we can achieve a > � � � �closed system by simpler means. > > Best wishes > Brian > > > > On Thu, Jan 13, 2011 at 12:20:09AM +1100, James Hester wrote: >> By my count there are 6 distinct proposals for eliding triple-quoted >> strings on the table, which I have listed below. �In order to get an >> idea of where we all stand and which proposals are most likely to >> succeed, I'd like to invite you all to reply to this email with a list >> of proposals which you would find acceptable. �If you like, you can >> rank them in order of preference. �In the list below I've given short >> descriptions, but you should refer to the original emails for the full >> details. �The opinions of COMCIFS voting members are of course most >> significant at this juncture, but I for one am interested in the >> thoughts of the other members as well. >> >> Proposal P (for Python): Ralf's original proposal to do everything as in Python >> Proposal A: <backslash><delimiter> elides the delimiter, no other >> sequences are significant >> Proposal B: \uxxxx to represent Unicode characters, no other sequences >> are significant >> Proposal C: as yet unspecified character post-elides the delimiter >> where necessary >> Proposal D: as for C, except post-elide character is given immediately >> before opening triple delimiter >> Proposal E: (John B's suggestion) \uxxxx for Unicode character >> together with \<newline> and \\ >> Proposal F: (Simon's proposal) \<newline> and \\ only >> Proposal F': (My slight tweak of Simon's proposal) \<newline> only >> when not preceded by \ >> >> I find proposal P unacceptable, and would rank the others in order of >> preference roughly as follows: >> >> Best: F', F, C >> Bearable: A, B, E >> In a pinch: D >> >> -- >> T +61 (02) 9717 9907 >> F +61 (02) 9717 3145 >> M +61 (04) 0249 4148 >> _______________________________________________ >> ddlm-group mailing list >> [email protected] >> http://scripts.iucr.org/mailman/listinfo/ddlm-group > _______________________________________________ > ddlm-group mailing list > [email protected] > http://scripts.iucr.org/mailman/listinfo/ddlm-group > -- T +61 (02) 9717 9907 F +61 (02) 9717 3145 M +61 (04) 0249 4148 _______________________________________________ ddlm-group mailing list [email protected] http://scripts.iucr.org/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- References:
- [ddlm-group] Focusing the elide discussion (James Hester)
- Re: [ddlm-group] Focusing the elide discussion (Brian McMahon)
- Prev by Date: Re: [ddlm-group] Relationship asmong CIF2, STAR, CIF1 and Python. .
- Next by Date: Re: [ddlm-group] Relationship asmong CIF2, STAR, CIF1 and Python. .
- Prev by thread: Re: [ddlm-group] Focusing the elide discussion
- Next by thread: [ddlm-group] Simon's elide proposal
- Index(es):