[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] Vote on moving elide discussion to COMCIFS. .. .
- To: Group finalising DDLm and associated dictionaries <firstname.lastname@example.org>
- Subject: Re: [ddlm-group] Vote on moving elide discussion to COMCIFS. .. .
- From: James Hester <email@example.com>
- Date: Tue, 22 Feb 2011 12:11:43 +1100
- In-Reply-To: <firstname.lastname@example.org>
- References: <AANLkTimzt6Jvc3YidO=vDcWYd9QC1r2oNTAmXyqkzFHd@mail.gmail.com><email@example.com><firstname.lastname@example.org><email@example.com>
Herbert: I've indicated below where I think you will find discussion of the points you raise. On Tue, Feb 22, 2011 at 9:11 AM, Herbert J. Bernstein <firstname.lastname@example.org> wrote: > Dear John B., > > Thank you, that was very helpful. To summarize those messages, > a majority on COMCIFS made a proposal to make the treble-quoted > strings agree with those of Python. The reasons given were: > > "such informal > descriptions are never as reliable as an actual implementation, > in particular one that's been around for many years and is used > by millions of people." (Ralf) The potential reliability or otherwise of Ralf's proposal compared to others on the table was addressed by myself at http://www.iucr.org/__data/iucr/lists/ddlm-group/msg00922.html In that and subsequent messages I pointed out that Proposal F is a whole lot simpler and therefore easier to understand and implement than the Python proposal, hence favouring the Python version on the basis of superior reliability and clearer specification is not reasonable. Note my justification of 15 minutes programming time for Proposal F at http://www.iucr.org/__data/iucr/lists/ddlm-group/msg00929.html > "meaningful adoption of DDLm/CIF2 will require embracing > and leveraging existing technologies as much as possible." (John W.) I too find John W's position difficult to decipher - on the one hand he favours minimal changes to CIF syntax, on the other leveraging existing technologies. I would be cautious in counting on his support for or against the Python proposal. Note the following message from John B which touches on the meaningfulness or otherwise of "leveraging" existing technologies: http://www.iucr.org/__data/iucr/lists/ddlm-group/msg00906.html I also wrote on this issue, but can't find the message right now. In a nutshell, "leveraging" seems to be shorthand for "improving compatibility and reducing specification and implementation time by reusing somebody else's work". In this particular case (Proposal F), the specification has been done and the implementation will take 15 minutes (a simple search and replace, no change to syntax as such). I estimate that implementing the Python alternative would take at least 5 times that long, in the favourable case that you have included the Python interpreter or parser in your code and consider that Ralf's original text is sufficiently precise. If you can't plug your code into the Python interpreter or parser, you are forced to reimplement the Python semantics from scratch, including finding some way to access the Unicode name database on all distribution platforms, so I would estimate *at least* a day's work for every CIF parser that is written, not to mention the complexity is such that some mistakes may be made. How long do you think it would take you to implement the Python proposal in Fortran, Herbert, assuming that you already have implemented triple-quoted strings? > "I find it [counter-intuitive] and unproductive to adopt something > that looks very much like the python treble quoted > string but which follows confusingly different rules." (HJB) This hasn't been addressed in the discussion as far as I recall, and Ralf has said the same thing as you to me privately. How much value you assign to this point really depends on how likely you think it is that confusion will arise in the real world of CIF programmers and users. I personally think that the most important attribute of triple-quoted strings is that they go on until the next triple quote. What elides are defined is something I would tend to check in the relevant standard to find out. In addition, the fact that CIF is a data file and Python is a programming language means that the contexts are sufficiently different to minimise confusion. Did you know that "Unix" is also a tupperware-like product? We can add a big bold sentence to the Proposal F text to state "Unlike Python, no other elide sequences are defined" if that would allay your concerns on this point. > The responses you cite did not seem to address those issues. Was > there a discussion on those issues that I missed? One technical issue with Proposal P that has not been resolved is how a CIF application is supposed to interpret the sequence <backslash><double quote> when encountered in a string returned from the parser. Is this sequence: (a) a terminator elide sequence that was left in a raw string, so corresponds to <double quote>? (b) something with meaning for the application so should be <backslash><double quote>? Please therefore advise how a CIF application will disambiguate the following string content from a Proposal P parser: <start> I have no idea what the last characters of this string are\"<finish> <start> Does this string have two\""" or three internal quotes?<finish> James > Regards, > Herbert > > > > > At 3:32 PM -0600 2/21/11, Bollinger, John C wrote: >>Dear Herbert, >> >>On Monday, February 21, 2011 2:35 PM, you wrote: >>> Other than my own messages, could you point me to where there >>>was a discussion of the actual proposal Ralf made, rather than >>>of variations and interpretations, but of the actual wording >>>change Ralf proposed for the CIF2 document? I cannot seem >>>to find that. That wording seemed/seems pretty sensible to >>>me. >> >>For reference, the message to the COMCIFS list in which Ralf >>proposed his wording change is archived here: >>http://www.iucr.org/__data/iucr/lists/comcifs-l/msg00500.html >> >>Some messages on the DDLm list, other than your own, in which Ralf's >>proposal is directly discussed include these: >> >>http://www.iucr.org/__data/iucr/lists/ddlm-group/msg00899.html >>http://www.iucr.org/__data/iucr/lists/ddlm-group/msg00901.html >>http://www.iucr.org/__data/iucr/lists/ddlm-group/msg00904.html >>http://www.iucr.org/__data/iucr/lists/ddlm-group/msg00906.html >>http://www.iucr.org/__data/iucr/lists/ddlm-group/msg00921.html >> >>Some of those also discuss alternatives, but all of them discuss >>Ralf's proposal, a.k.a. proposal P. I probably missed some, and of >>course your own comments in favor of proposal P are not represented. >> >>Moreover, it distorts the (meta-)discussion to ignore commentary >>about alternative proposals. The existence and characteristics of >>alternatives to Ralf's proposal are relevant to any decision about >>it. That the discussion shifted to focusing on alternatives is >>natural given that most participants in the discussion disfavored >>proposal P. >> >>I hope this helps. >> >> >>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 >>email@example.com >>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 > firstname.lastname@example.org > ===================================================== > _______________________________________________ > ddlm-group mailing list > email@example.com > 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 firstname.lastname@example.org http://scripts.iucr.org/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- Re: [ddlm-group] Vote on moving elide discussion to COMCIFS. .. . (Herbert J. Bernstein)
- [ddlm-group] Vote on moving elide discussion to COMCIFS (James Hester)
- Prev by Date: Re: [ddlm-group] Vote on moving elide discussion to COMCIFS. .. .. .
- Next by Date: Re: [ddlm-group] Vote on moving elide discussion to COMCIFS. .. .
- Prev by thread: Re: [ddlm-group] Vote on moving elide discussion to COMCIFS
- Next by thread: Re: [ddlm-group] Vote on moving elide discussion to COMCIFS. .. .