Discussion List Archives

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ddlm-group] String concatenation operator in CIF2. .

Dear Colleagues,

   I may not have completely understood this discussion.  To me much
of the reasoning to be objecting to introducing the
concatenation operator because it changes the meaning of some
possible CIF files, not files that anybody has ever seen, but
possible ones.  Simon's proposal of using the underscore really
does not conflict with any existing CIF because it cannot be
a data value (it begins with an underscore) but also cannot be
a tag name, because we have implicitly treated the underscore in
a tag name as a delimiter rather than part of the name and have
not accepted empty names.

   The only real remaining objection to the underscore seems to be
that it does not look as nice as some of the more classical
concatenation operators: +, //, etc.  While I would prefer one
of the classical operators, there really is nothing wrong with the
underscore and it really does make it much easier to deal with
the transition to CIF2 both for regular expressions and for
folded lines.

   I ask for a formal vote by COMCIFS on the use of the white-space
isolated underscore as a concatenation operator.  To me it seems to
be a very useful addition to CIF2 and at worst a harmless addition.

   Regards,
     Herbert


At 11:21 AM -0500 10/14/10, Bollinger, John C wrote:
>On Thursday, October 14, 2010 7:48 AM, James Hester wrote:
>
>>There are three separate issues: (1) do we want a string concatenation
>>operator? (2) If so, what is the grammar for this operator (3) what
>>character(s) will be used for this operator?
>
>[...]
>
>>Regarding the particular characters to use to represent concatenation:
>>'+' is a poor choice given its possible uses as a datavalue in its own
>>right, and I find that  '_' is a little unintuitive and unnecessarily
>>overloads underscore. Note that there is no reason to limit ourselves
>>to a single character as we expect this operator to be used very
>>sparingly: we can use a digraph or trigraph if we so desire,
>>especially if it makes the meaning clearer to a naive user.
>
>If a concatenation operator is adopted, then I agree with Simon that 
>it should be something that is not legal as a whitespace-delimited 
>data value.  (Ideally, not in CIF1, either.)  I would prefer that it 
>not be legal even as the leading character(s) of a 
>whitespace-delimited data value.  Without departing from the allowed 
>ASCII characters, the lone underscore is the only viable string I 
>see that meets all those criteria.
>
>I don't so much mind '//' as a concatenation operator, except that 
>it must then be made a reserved word, and maybe even a reserved 
>prefix.  At least such a reservation is less likely to be a problem 
>than reservation of '+' would be, but I don't see that choice as 
>much more intuitive to the average user than '_'.
>
>
>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


-- 
=====================================================
  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
=====================================================
_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Science Council (admitted 1947). Member of CODATA, the ISC Committee on Data. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

International Science Council Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.

Useful links