[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: CIF parser / dialects
- Subject: Re: CIF parser / dialects
- From: James Hester <jrh@xxxxxxxxxxxx>
- Date: Wed, 3 Jul 2002 05:06:42 +0100 (BST)
On Wed, 2002-07-03 at 03:00, Richard G. Ball wrote: > If there is a concern over CIF dialects the easiest way to allay that concern and > inhibit present and future dialects is to provide an IUCr sponsored parser. It should> be in C and easily interfaced with the usual development languages (C (and its > relatives), Perl, Python, Tcl, FORTRAN). Such a parser would conform to the IUCr specs. > for reading/writing CIFs and thereby form a solid base for higher >level tools. The situation we have now, with so many disparate parsers, > is not very satisfactory (I have a partial one in Perl, James Hester >has his in Python, there's Syd's & Herb's in FORTRAN and I am sure many > others as well) and really should be addressed. > > If I have missed the creation of such a full-fledged, IUCr-approved, C-based parser > I would appreciate a pointer to the code and I apologize for the >misunderstanding. > > Richard > -- I think this proliferation is both inevitable and to be encouraged. Inevitable, because every author has different needs and circumstances governing their choice of language: after all, in the beginning we had CIFtbx in Fortran and an official parser in Fortran 77(QUASAR/vcif) but that didn't stop us thinking about how useful it would be to have a native C/C++ version. As an example of the differing considerations at different sites, I've gone with pure Python, as opposed to the much faster Python with C/C++ back end option, for low-maintenance portability combined with ease of installation - I distribute PyCifRW as part of a larger program which is installed by non-programming-literate people for the most part. Maintaining a similar level of portability with a C/C++ back end would mean (i) having to maintain n:n>=3 executable versions for easy distribution (impractical here) or (ii) expecting compilation to be part of installation which is both expensive in time and often money for the end user. To be encouraged, because sooner or later there will be a parser for everyone in the language they choose, thus lowering the barrier to the spread of CIF software, and because, once some sort of official blessing is obtained from the IUCr, there will be multiple reference implementations. Which brings me to my final point (made a long time ago already on this list or COMCIFS): given that inevitably others will want to write native Perl/Lisp/Assembler parsers, a set of tricky tests which can be used for automatic verification of a parser would be a key step forward. The current ciftest0-11 files are a useful start. I have a little ciftest12 file which additionally catches some of the more obscure errors I've made (the double terminating quotes, semicolon not in column 1, trailing/leading carriage returns in semicolon strings) which I'll contribute. If COMCIFS could officially sanction a set of tests with specifications on which must fail and which must pass, that would, I think, be equivalent to an official IUCr reference implementation. Other ideas for tricky tests: terminating semicolon followed by non-blank (should fail); terminating semicolon followed by <eof> (pass). James. -- _______________________________________________________________________ James Hester, ANBF KEK e-mail: jrh@anbf2.kek.jp Oho 1-1 Phone: +81 298 64 7959 Tsukuba, Ibaraki 305 Fax: +81 298 64 7967 Japan ________________________________________________________________________
Reply to: [list | sender only]
- Prev by Date: Re: CIF parser / dialects (was Re: Another suggestion for the BNF)
- Next by Date: Re: CIF parser / dialects (was Re: Another suggestion for the BNF)
- Prev by thread: Re: A formal specification for CIF version 1.1 (Draft)
- Next by thread: Re: CIF parser / dialects
- Index(es):