[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] Straw poll results
- To: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] Straw poll results
- From: Nick Spadaccini <nick@csse.uwa.edu.au>
- Date: Wed, 14 Oct 2009 02:42:03 +0800
- Authentication-Results: postfix;
- In-Reply-To: <20091013141006.C48223@epsilon.pair.com>
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
Reply to: [list | sender only]
- Follow-Ups:
- Re: [ddlm-group] Straw poll results (Herbert J. Bernstein)
- References:
- Re: [ddlm-group] Straw poll results (Herbert J. Bernstein)
- Prev by Date: Re: [ddlm-group] Straw poll results
- Next by Date: Re: [ddlm-group] Straw poll results
- Prev by thread: Re: [ddlm-group] Straw poll results
- Next by thread: Re: [ddlm-group] Straw poll results
- Index(es):