Discussion List Archives

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

Re: [ddlm-group] CIF-2 changes

I would argue that a properly designed scripting language will provide
ways to protect datanames found in dREL code, so there is no need to
worry about inhibiting use of scripting languages.  I personally
always use the 'setattr' form of the python '.' attribute dereference
when converting dREL code to Python, thereby avoiding any issues with
embedded punctuation.  Furthermore, as I argued in my other message
today, dREL should also provide a way to quote datanames.

On Tue, Nov 10, 2009 at 11:55 PM, Nick Spadaccini <[email protected]> wrote:
> Correct, if 1 is selected then 0 is moot.
>
> I prefer {} and [] reserved AND no [] or punctuation in data names. I know
> that is not being offered as an option, but I would still like to have the
> question I posed previously answered.
>
> Are we going make it impossible to cast data names into target code
> identifiers by allowing embedded punctuation? I must say this would
> completely cripple the existing dREL parser and require a significant
> re-design and rethink. I suspect it will inhibit many people using scripting
> languages to take dREL code and cast it in to running code.
>
>
> On 10/11/09 8:29 PM, "Herbert J. Bernstein" <[email protected]>
> wrote:
>
>> I am neutral on option 0 as long as we make a clear rule for both software
>> writers and users to follow. �Note that option 0 becomes moot as a
>> practical matter if we restrict ourselves to just {}, but becomes a very
>> real issue once [] becomes a delimiter.
>>
>> So so far the vote is:
>>
>> � �James and Herbert: �1 - 3 - 2 - 4
>> � �James: �No on 0
>> � �Herbert: Neutral on 0
>>
>>
>> =====================================================
>> � Herbert J. Bernstein, Professor of Computer Science
>> � � Dowling College, Kramer Science Center, KSC 121
>> � � � � �Idle Hour Blvd, Oakdale, NY, 11769
>>
>> � � � � � � � � � +1-631-244-3035
>> � � � � � � � � � [email protected]
>> =====================================================
>>
>> On Tue, 10 Nov 2009, James Hester wrote:
>>
>>> On Tue, Nov 10, 2009 at 2:30 AM, Herbert J. Bernstein
>>> <[email protected]> wrote:
>>>> Dear Colleagues,
>>>>
>>>> � I am coping with the rapid ebb and flow of what delimiters will be
>>>> used for CIF2 by providing controls for both CIFtbx_4 and CBFlib_9
>>>> to turn on or off sensitivity to (), [] and {} delimiters separately,
>>>> so I can deal with whatever the final decision is by changing the
>>>> defaults, ...
>>>
>>> So I guess you have a proof of concept for whatever we decide on.
>>>
>>>> � BUT we really do have to settle this. �Ignoring the comma, quote and
>>>> colon issues, Since 2007 we have now gone through use of a of (), [], and
>>>> {} as reserved delimiters, use of just () and {}, and use of just {}. �It
>>>> is time to simply make a firm and final decision.
>>>
>>> To be fair, it is only since August this year that there has been any flux.
>>>
>>>> � We have dictionaries to write and code to implement. �I have already
>>>> delayed delivery of software to deal with this, and I really don't like
>>>> delaying delivery of software.
>>>>
>>>> � The use of the [] in CIF 1 dictionary category name is well-established.
>>>> I prefer to minimize the impact on handling existing dictionaries in a
>>>> CIF2 context and to stick strictly to {} as the only brackets in the
>>>> set of reserved delimiters and to allow both () and [] in non-delimited
>>>> strings and data names. �So let us have another straw vote:
>>>>
>>>> � Option 1: �{} will be reserved, but [] and () will not be reserved; or
>>>> � Option 2: �{} and [] will be reserved, but () will not be reserved; or
>>>> � Option 3: �{} and () will be reserved, but [] will not be reserved; or
>>>> � Option 4: �{}, () and [] will all be reserved
>>>>
>>>> I suggest preferences voting noting if any are fatal to anyone.
>>>>
>>>> My preferences are in decreasing order: �1 then 3 and 2 then 4, but, as
>>>> long as we settle this for once and for all, I can live with any of them.
>>>
>>> Unfortunately your options exclude allowing brackets both inside
>>> datanames/non-delimited strings and as list/table delimiters. �In
>>> light of Nick's email I suggest an additional formulation:
>>>
>>> 0. Make it possible to detect missing whitespace after datanames and
>>> non-delimited text strings if the following datavalue is a list or
>>> table? (Yes/No)
>>>
>>> If "Yes": �which of the above options do you prefer?
>>> If "No": which of the above options would you prefer if the majority
>>> prefer "Yes" as an answer to question 0?
>>>
>>> I vote "No" (don't make it possible to detect whitespace) and
>>> preferences same as Herbert (due to already existing square brackets
>>> in datanames).
>>>
>>>
>>> --
>>> T +61 (02) 9717 9907
>>> F +61 (02) 9717 3145
>>> M +61 (04) 0249 4148
>>> _______________________________________________
>>> ddlm-group mailing list
>>> [email protected]
>>> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>>>
>> _______________________________________________
>> ddlm-group mailing list
>> [email protected]
>> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>
> cheers
>
> Nick
>
> --------------------------------
> Associate Professor N. Spadaccini, PhD
> School of Computer Science & Software Engineering
>
> The University of Western Australia � �t: +61 (0)8 6488 3452
> 35 Stirling Highway � � � � � � � � � �f: +61 (0)8 6488 1089
> CRAWLEY, Perth, �WA �6009 AUSTRALIA � w3: www.csse.uwa.edu.au/~nick
> MBDP �M002
>
> CRICOS Provider Code: 00126G
>
> e: [email protected]
>
>
>
>
> _______________________________________________
> ddlm-group mailing list
> [email protected]
> 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
[email protected]
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