[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] A modest addition to the DDLm spec. .. .
- To: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] A modest addition to the DDLm spec. .. .
- From: "Herbert J. Bernstein" <yaya@bernstein-plus-sons.com>
- Date: Thu, 30 Sep 2010 17:04:46 -0400 (EDT)
- In-Reply-To: <8F77913624F7524AACD2A92EAF3BFA5416659DEDF9@SJMEMXMBS11.stjude.sjcrh.local>
- References: <4C471374.6000100@mcmaster.ca><alpine.BSF.2.00.1007211307460.37813@epsilon.pair.com><AANLkTinyxmyKFOt=A6Cpdq=8LVsSR4+Js9xDOG+JEF--@mail.gmail.com><AANLkTimTab=b9u6nsUjd6UitRni-OgMTJNZYt1EMjrhE@mail.gmail.com><a06240804c8ca43f92cc2@[192.168.2.104]><8F77913624F7524AACD2A92EAF3BFA5416659DEDF3@SJMEMXMBS11.stjude.sjcrh.local><alpine.BSF.2.00.1009301317510.76563@epsilon.pair.com><8F77913624F7524AACD2A92EAF3BFA5416659DEDF9@SJMEMXMBS11.stjude.sjcrh.local>
Try working with some of the longer regexes for a while and you may come to appreciate having something like the plus or the line-folding backslash to allow you to present what really in one very long single-line character string with lots of funny stuff in it over a series of line and broken with some whitespace that is not part of the string. To take one which does not involve quote marks: "[0-9]?[0-9]?[0-9][0-9]-[0-9]?[0-9]-[0-9]?[0-9]((T[0-2][0-9](:[0-5][0-9](:[0-5][0-9](.[0-9]+)?)?)?)?\([+-][0-5][0-9]:[0-5][0-9]))?" is much harder to read and understand than "[0-9]?[0-9]?[0-9][0-9]-[0-9]?[0-9]-[0-9]?[0-9]"+ "((T[0-2][0-9](:[0-5][0-9](:[0-5][0-9](.[0-9]+)?)?)?)?"+ "([+-][0-5][0-9]:[0-5][0-9]))?" which I normally do with the CIF1 line folding protocol, and the treble quote add nothing of value, and to return to quotes """[][ \n\t()_,.;:"&<>/\{}'`~!@#$%?+=*A-Za-z0-9|^-]*""" is not as clear to me as "[][ \n\t()_,.;:" + '"&<>/\{}' + "'`~!@#$%?+=*"+ "A-Za-z0-9|^-]*" which helps to organize the data for me and calls out the troublesome case. However, the question is not one of your taste or mine or Nic's, nor even whether the feature is useful to everybody, but whether it is useful to some reasonable number of people and whether having it causes some kind of problem for other people. I assume we all agree that CIF is intended to be a useful tool to get work involved with crystallography done. The string concatenation operator is one of the most generally useful operators, and there is no sound reason not to support it top to bottom, from the top level CIF data down to the dREL language itself. It is in dREL right now (see 7.1.2), so we are going to have to handle it down there. (Indeed, dREL has 2 string concatenations, one with blank for string literals and one with "+" for string objects). Why is it such a big issue to also handle the "+" at the top level? ===================================================== Herbert J. Bernstein, Professor of Computer Science Dowling College, Kramer Science Center, KSC 121 Idle Hour Blvd, Oakdale, NY, 11769 +1-631-244-3035 yaya@dowling.edu ===================================================== On Thu, 30 Sep 2010, Bollinger, John C wrote: > > On Thursday, September 30, 2010 12:23 PM, Herbert J. Bernstein wrote: > >> It reduces the incompatability with CIF1 introduced by the change >> in string quoting syntax, allowing the resulting CIF2 CIFS to >> be much closer to their CIF1 originals, > > I don't buy that one. Which is closer to 'O'Donnell said, "Pshaw"'? > > '''O'Donnell said, "Pshaw"''' > > or > > "O'Donnell said, " + '"Pshaw"' > > For me, it's the former, and that becomes much more the case the more concatenations are involved. Consider, for example, how the concatenation approach would look for this slight variation: 'O'Donnell said, "P'shaw"'. > >> fills that gap >> created by not dealing with elides for lone folding in >> a simpler way, > > Are you saying that it provides a superior line-folding approach than the one already used with CIF1? I'll have to think about that. Does your argument apply in general, or only for particular cases such as regex? > > Is a line-folding mechanism that is incompatible with CIF1 even relevant? I have always thought that the most important reason for having a line-folding protocol at all was for compatibility with CIF readers that implement the old 80-character line limit. An alternative that is incompatible with CIF1 is useless for that purpose. > > Any way around, I'm hesitant to promote line folding from a semantic consideration to a syntactic one. > >> and conforms to well-established pratice in >> multiple programming languages. > > That is not germane as far as I am concerned. CIF is not a programming language, and its audience (as opposed to the audience of the specification) contains many non-programmers. > >> C manages to deal with this >> using the blank as the concatenation operator at the C preprocessor >> level, so we should be able to handle it at the lexical level. > > Certainly we *can* handle it. And doing so will make our code a little bit more complex, and a little bit more difficult to maintain. > > Also, this proposal would either make CIF diverge (further?) from STAR, or would require STAR to adopt the same change. If we want the latter then we cannot settle the question here. > > I continue to reserve judgment, but right now it looks like more down side than up side to me. Furthermore, it still seems that this could be addressed as well or better at the DDL and/or dictionary level, but perhaps that would have impacts that I do not presently appreciate. > > > Regards, > > John > -- > John C. Bollinger, Ph.D. > Department of Structural Biology > St. Jude Children's Research Hospital > > > > > Email Disclaimer: www.stjude.org/emaildisclaimer > > _______________________________________________ > 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
Reply to: [list | sender only]
- Follow-Ups:
- Re: [ddlm-group] A modest addition to the DDLm spec. .. .. . (Bollinger, John C)
- Re: [ddlm-group] A modest addition to the DDLm spec. .. . (Nick Spadaccini)
- References:
- [ddlm-group] import and loops in ddlm (David Brown)
- Re: [ddlm-group] import and loops in ddlm (Herbert J. Bernstein)
- Re: [ddlm-group] import and loops in ddlm (James Hester)
- Re: [ddlm-group] import and loops in ddlm (James Hester)
- [ddlm-group] A modest addition to the DDLm spec (Herbert J. Bernstein)
- Re: [ddlm-group] A modest addition to the DDLm spec. . (Bollinger, John C)
- Re: [ddlm-group] A modest addition to the DDLm spec. . (Herbert J. Bernstein)
- Re: [ddlm-group] A modest addition to the DDLm spec. .. . (Bollinger, John C)
- Prev by Date: Re: [ddlm-group] A modest addition to the DDLm spec. .. .
- Next by Date: Re: [ddlm-group] A modest addition to the DDLm spec. .. .
- Prev by thread: Re: [ddlm-group] A modest addition to the DDLm spec. .. .
- Next by thread: Re: [ddlm-group] A modest addition to the DDLm spec. .. .
- Index(es):