[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] Straw poll results
- To: Nick.Spadaccini@uwa.edu.au, Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] Straw poll results
- From: "Herbert J. Bernstein" <yaya@bernstein-plus-sons.com>
- Date: Tue, 13 Oct 2009 15:32:54 -0400 (EDT)
- In-Reply-To: <C6FAEAFB.120AC%nick@csse.uwa.edu.au>
- References: <C6FAEAFB.120AC%nick@csse.uwa.edu.au>
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 > _______________________________________________ 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 (Nick Spadaccini)
- References:
- Re: [ddlm-group] Straw poll results (Nick Spadaccini)
- 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):