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

Re: [ddlm-group] Straw poll results

Dear Nick,

   I would suggest we discuss various approahes to deprecating features 
tomorrow over lunch, but it really is a very common practice in standards 
work, e.g. the handling of type-punning in gcc.  It saves both users and 
developers a lot of aggravation and helps them to learn and adapt to new 
practices.

   Regards,
     Herbert

=====================================================
  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
=====================================================

On Wed, 14 Oct 2009, Nick Spadaccini wrote:

>
>
>
> On 13/10/09 11:27 PM, "James Hester" <jamesrhester@gmail.com> wrote:
>
>> Here are the results of the straw poll.  See the end of the email for
>> detailed vote counts, and note the request for a further vote on
>> certain issues.
>>
>> CONCLUSIONS
>> ===========
>>
>> 1. UTF8 will be supported. Not clear on asciified version or
>> binary. Therefore, please comment and vote on the following, given
>> that UTF8 will be included in the new standard:
>>
>> (a) UTF8 should be supported in standard form only (i.e. 'binary'
>> characters with values above 127 will appear in CIF files)
>>
>> (b) An asciified version only should be supported.  An example would
>> be the syntax \uxxxx, where xxxx refers to the Unicode code point of
>> the character in hexadecimal notation.  NB this is not strictly UTF8,
>> but simply a Unicode representation.
>>
>> My vote: 1.a
>>
>> 2. Termination of quoted strings on first occurence of quote delimiter
>> and restriction of character set for non-delimited strings: Approved,
>> but not clear whether to deprecate first or move immediately to
>> requirement.  Upon long consideration of Brian's email and Herbert's
>> reservations, and two cups of tea, and some chocolate, I am happy to
>> change my votes to 1.2 and 2.3 (and perhaps call the new CIF syntax
>> 2.0 rather than 1.2), therefore I declare these proposals approved as
>> a requirement in the new standard.  I'll write a separate email on
>> this.
>>
>> However: Brian and James want to require whitespace between tokens
>> outside compound expressions regardless of it now becoming strictly
>> unnecessary in several cases.  Given that the above proposals have
>> been passed, please vote again on the following options:
>>
>> (a) Whitespace is not required between tokens unless tokens could not
>> otherwise be separated; writers are encouraged to pad between tokens
>> (b) Whitespace must always appear between tokens outside compound expressions
>> (c) Whitespace must always appear between tokens both in and outside
>> compound expressions
>>
>> My vote: 2.b
>>
>> Detailed vote summary
>> =====================
>>
>> Issue1:  Removing the requirement for a trailing whitespace after
>> quoted strings outside of bracketed constructs.
>>   Options:  1.1. Preserve the current convention as is
>>             1.2. Terminate all quoted strings on the occurance of the
>> trailing quoted delimiter without consideration of the next character
>>             1.3  Deprecate rather than require 1.2
>
> What does deprecate rather than require 1.2 mean? If a scientist asks, what
> does the formal language specification state concerning the absolute need
> for whitespace before and after a token, what is the answer?
>
> Please don't say we deprecate (definition: earnestly disapprove of)
> whitespace, that is just plain silly. In the specification a quoted string
> is terminated by the first occurrence of the matching quote (1.2), or it is
> terminated by a quote immediately followed by one or more whitespace (in
> which case you are actually voting for 1.1).
>
> Again (and again and again, how many times do I have to say this?)
> deprecation has to do with an implementation. What are we specifying?
>
>> 1.1: Nobody (Herbert prefers if 1.3 not an option)
>> 1.2: Brian (but whitespace required between tokens), Nick, Simon
>> 1.3: Herbert, James (but whitespace required between tokens)
>>
>> Difficult to determine any clear preference from John W., but he seems
>> happy to go along with the changes we are discussing so long as there
>> is a clear fallback position.
>>
>>   Issue2:  Restriction of the character set for non-delimited strings
>> outside of bracketed constructs
>>   Options  2.1.  Preserve the current convention as is
>>            2.2.  Modify the current convention to deprecate use of
>>                  any characters other than a strictly limited set
>>                  of characters, adding a warning oon reads and
>>                  defaulting to add quote marks on write
>>            2.3.  Modify the current convention to forbid the use of
>>                  any characters other than a strctly limited set
>>                  of characters, making it an error to read a non-delimited
>>                  string that does not comply even if the intention
>>                  can be inferred from context
>
> Same question, earnestly disapproving of a character set is not a
> specification. What will be specified for the language? Is the , allowed or
> not allowed in an unquoted string?
>>
>> 2.1: Nobody
>> 2.2: Herbert, James
>> 2.3: Nick, Simon, (John)
>>
>> UTF8:
>>
>> Do not use: Nobody
>> Use: Simon, Brian, John
>> Use, binary: Herbert, James
>> Use, asciified: Nick
>>
>> A clear preference for binary or ascii can't be gleaned from Brian and
>> Simon's and John's emails, so I've left them as simply 'Use'.
>>
>
> 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: Nick.Spadaccini@uwa.edu.au
>
>
>
>
>
> _______________________________________________
> ddlm-group mailing list
> ddlm-group@iucr.org
> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>
_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group

Reply to: [list | sender only]