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

Re: [ddlm-group] Straw poll results

Dear Nick,

   I don't understand what you are saying.  We have a current, rather 
detailed spec of CIF 1.1.  It is posted on the web at

   http://www.iucr.org/resources/cif/spec/version1.1/cifsyntax
and
   http://www.iucr.org/resources/cif/spec/version1.1/semantics

You are proposing to make changes in that specification.  I have tried to 
suggest the python lexical scan as a base to define the new CIF lexical 
scan.  If you don't like the python lexical scan as a base, please suggest 
what you are thinking of as a base. The python scan seems to take care of 
the concerns about how to nest treble quotes and character encodings, but 
this is not a religious matter, just one of many possible engineering 
alternative.  Now we need to get down the the details of the specific 
changes _you_ are proposing to the existing CIF specification so we can 
try to put something specific together that will support the existing base 
of files while allowing us to move forward to a new format.

Are you asking James or me to write the lexer and parser for your new 
ideas?  I would need a much better understanding of what you are proposing 
in order to do that.  Maybe James is further along in his understanding 
than I am, but I suspect we would all do better if you would take the time 
to be more specific about what you are proposing.

Let's talk about it 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
                  yaya@dowling.edu
=====================================================

On Wed, 14 Oct 2009, Nick Spadaccini wrote:

> I give up. I think I am trapped in the twilight zone. It seems that no-one
> can answer the question what will be the formal specification of the
> language. We need to deprecate FROM something. What is that something?
>
> At this rate there is no formal specification that has changed, which means
> deprecation is not necessary - nothing is changing. If someone thinks they
> can formally specify the CIF syntax (or any language) in terms of
> deprecation and "alternative" behaviours in parsing, then good luck with
> getting that published.
>
> Thanks for the offer Herb, but I do know how to write parsers that implement
> a formal specification and then apply deprecation and work arounds, I have
> done that in the CIF/STAR parsers I have written. BUT there, there was a
> formal specification I could work from.
>
> At the moment there isn't one that is any different to the original.
>
> I await the answer to my question with bated breath.
>
>
> On 14/10/09 3:32 AM, "Herbert J. Bernstein" <yaya@bernstein-plus-sons.com>
> wrote:
>
>> 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
>>                   yaya@dowling.edu
>> =====================================================
>>
>> 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" <yaya@bernstein-plus-sons.com>
>>> 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
>>>>                   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
>>>>>
>>>
>>> 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
>>>
>
> 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]