Discussion List Archives

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

Re: [ddlm-group] Straw poll results

Dear Nick,

   If you will provide the lex and/or yac for these constructs as you are 
proposing them, I will be happy to indicate what needs doing for a 
lexer/parse supporting deprecation of these features.  Right now I am very 
unclear about what the new strict definition is.  Hopefully you can 
clarify it for me tomorrow.

   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
                  [email protected]
=====================================================

On Wed, 14 Oct 2009, Nick Spadaccini wrote:

> Yes we can and we will. BUT no one has answered my question yet. I am happy
> for people to implement parsers which do more that implement a
> specification. I just want to know what the specification is.
>
> As for punning and related approaches, it is loosely defined as
>
> "In computer science, type punning is a common term for any programming
> technique that subverts or circumvents the type system of a programming
> language in order to achieve an effect that would be difficult or impossible
> to achieve within the bounds of the formal language."
>
> It is implemented in the GCC compiler, but is it in the C language
> specification. It is designed to circumvent to strict specification.
>
> Most compilers will do a good job recovering from a poorly constructed type
> definition, BUT allowing for poorly constructed type definitions are NOT
> part of a language's specification. The language would SPECIFY correctly
> constructed type definitions.
>
> Can you or James clearly tell me what will be specified for Issues 1 and 2
> for this language. I believe you are both heading toward 1.1 and 2.1 (no
> change in both cases) from the point of view of what is in the formal
> specification for this language. If not you are both heading toward 1.2 and
> 2.3 in terms of what is written in the language specification.
>
> Granted you are both going to IMPLEMENT parsers that will operate under 1.3
> and 2.2.
>
> Nick
>
>
> On 14/10/09 2:13 AM, "Herbert J. Bernstein" <[email protected]>
> wrote:
>
>> 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
>>                   [email protected]
>> =====================================================
>>
>> On Wed, 14 Oct 2009, Nick Spadaccini wrote:
>>
>>>
>>>
>>>
>>> On 13/10/09 11:27 PM, "James Hester" <[email protected]> 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: [email protected]
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
_______________________________________________
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