Discussion List Archives

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

Re: [ddlm-group] Eliding in triple-quoted strings: Proposals C andD. .. .. .

Dear Herbert

I fail to see how the adoption of python string quoting rules is going to
make life easier for anyone other than a python programmer?
Even then, the mechanism is restricted to treble-quoted strings, which are only
one part of CIF. Maybe I've missed something, but just because CIF might share
common syntax with a programming language in one respect, does not necessarily mean
that the tools of that medium are available to CIF?

If you're looking to base CIF extensions on established mechanisms, why not adopt
the minimal \(newline) and \\ escape sequences, which in essence are the same as
the established CIF line-folding protocol (just dropping the initial \ following the opening
delimiter and formalising the protocol as an inherent part of the spec). Afterall, I beleive you
have already been using it, or at least interpreted it, as a means to escape 'semicolon delimiters' within
semicolon-delimited values (I seem to recall discussions that identified an issue with the published 'trip tests'
relating to line folding).

Forgive me if I have missed something regarding the usefulness of python in CIF; please enlighten me
as to its benefits if I were to write a CIF reader using anything but python. As far as I can see, the only
advantages lie in the fact that the logic is established and thus unquestionable; but that does not mean it is
necessarily entirely appropriate for CIF (which afterall isn't a programming language).



From: Herbert J. Bernstein <yaya@bernstein-plus-sons.com>
To: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
Sent: Friday, 7 January, 2011 23:07:40
Subject: Re: [ddlm-group] Eliding in triple-quoted strings: Proposals C and D. .. .. .

Dear Colleagues,

  Ralf's proposal is what it is.  Before we go haring off in other
directions, we should respond constructively to what he has proposed.
I support it.  Ralf and John W. support it.  John B. and James H.
oppose it.  I think they are mistaken because ...

  It is well and good to adopt a "Real Programmers Don't Each
Quiche" let's-start-from-scratch-and-roll-our-own approach when
you have the resources to accomplish our goals that way.  It
is a lot of fun, and has the potential to truly advance the
field, but it is also, in the current funding climate, unrealistic.

  In the U.S., there is a serious prospect to science funding being
cut back so severely that the hit rates on grants next year may
be as low as 1 in 10.  I suspect an honest review of funding prospects
in other countries will uncover similarly dire warnings.

  This does not mean we are all going out of buisness, but we do have
to be careful to conserve resources and focus our do-it-from-scratch
efforts on those areas that have the highest priority, and I fear,
for most of our community, CIF2, while important, is not likely to
be seen as worth that approach, and certainly filing the edges of
a brand-new treble quote spec is likely to be very far down
on anybody's priority list.

Ralf has made a proposal that will save all of us a lot of effort
and allow us to devote more resources to higher priority problems.

Not only is he right on this one point, but I urge us to look for
other areas where we can get to CIF2 by building on work that is
already done.

This is not a good time for wheel-reinvention.

I would appreciate knowing from those who wish to reinvent this
particular wheel, why they wish to do that and from where they
expect to get the resources to do it?


  Herbert J. Bernstein, Professor of Computer Science
    Dowling College, Kramer Science Center, KSC 121
        Idle Hour Blvd, Oakdale, NY, 11769


On Fri, 7 Jan 2011, Bollinger, John C wrote:

> On Friday, January 07, 2011 3:14 PM, Herbert J. Bernstein wrote:
>> We seem not to be communicating effectively.
>> What I am asking for is an _existing_, supported treble quote specification
>> from an _existing_ language with _existing_ documentation and
>> _existing_ software as an alternative to the Python specification,
>> documentation and software to which we all have access, that is being
>> proposed as an alternative
>> to what Ralf has proposed.
> Thank you for that clarification.  You are right, I didn't understand
> what you were asking for.
> I hope this will likewise clarify my position: I reject the premise that
> the system we choose must meet those criteria, and I oppose adopting the
> full Python syntax and semantics.
>> The Python specification is available at
>> http://docs.python.org/reference/index.html
>> with the lexical analysis at
>> http://docs.python.org/reference/lexical_analysis.html
> Thanks, though that is exactly what I was looking at already.  It leaves
> several details unclear, some of which I discussed in previous messages.
> Hence, I consider it slightly short of a *full* specification.  It does,
> however, provide my grounds for opposing adoption of that scheme for
> CIF.
>> The complete source code and binaries are available at:
> Unless you propose to append a particular set of Python sources to the
> CIF specification as a reference, I have no interest in perusing the
> source code to seek answers to such questions of detail as I have.
> Furthermore, I would oppose adding such an appendix on the grounds that
> it would be exceedingly difficult to use to resolve questions such as
> mine.
> I am likewise unwilling to rely on the behavior the python binary that
> happens to be installed on my computer to answer them.  If the correct
> behavior is not documented independent of the program then there is no
> particular reason to trust that it won't change in future versions, or
> that any particular implementation is correct or bug-free.
> 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 mailing list

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.