[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 <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] Focusing the elide discussion
- From: James Hester <jamesrhester@gmail.com>
- Date: Tue, 18 Jan 2011 23:44:43 +1100
- In-Reply-To: <20110118120509.GB26797@emerald.iucr.org>
- References: <AANLkTinUHwGQOYo6dafhKSb0Pv9gKbNMZhZ27bvb_Ha8@mail.gmail.com><20110118120509.GB26797@emerald.iucr.org>
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 <bm@iucr.org> 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 >> ddlm-group@iucr.org >> http://scripts.iucr.org/mailman/listinfo/ddlm-group > _______________________________________________ > ddlm-group mailing list > ddlm-group@iucr.org > 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 ddlm-group@iucr.org 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):