[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] Characterset of non-delimited strings insidecompound data items
- To: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] Characterset of non-delimited strings insidecompound data items
- From: James Hester <jamesrhester@gmail.com>
- Date: Tue, 9 Nov 2010 14:14:55 +1100
- In-Reply-To: <alpine.BSF.2.00.1011082115550.70856@epsilon.pair.com>
- References: <AANLkTimVXn5ZEEBZx37YtgjP3g8AdZGZEise7fF=C+Ee@mail.gmail.com><alpine.BSF.2.00.1011082115550.70856@epsilon.pair.com>
Indeed. I agree that "ease of use of flex" is not a good criterion. A better way of putting it would be "simplicity of implementation". Glad you don't object to excluding close brackets. James. On Tue, Nov 9, 2010 at 1:23 PM, Herbert J. Bernstein <yaya@bernstein-plus-sons.com> wrote: > While I have no particular objection to excluding the close brackets from > non-delimited strings, personally I think making easy use of flex a > criterion for the design of CIF2 is not a good idea. -- 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 Tue, 9 Nov 2010, James Hester wrote: > >> Dear DDLm group, >> >> John Bollinger has alerted me to a glitch in the current DDLm >> specification, to wit: (i) close bracket characters are allowed as >> non-final characters in a non-delimited string, and (ii) there is no >> requirement for whitespace between a datavalue and the close bracket >> symbol that denotes the end of a table or list value. >> >> This means that, in order to decide whether a close bracket character >> terminates a list or is just another character in the non-delimited >> string, the parser must look ahead, potentially many levels of >> nesting. For example: >> >> _t [outer [inner1 inner2]] >> >> >> The parser does not know that the first close bracket closes the inner >> list until it has read past the second close bracket. Or even more >> confusingly: >> >> _t [ depth_1 [ depth_2 [ depth_3 x=a1[a2[a3[a4[i]]]];]]] >> >> >> While this behaviour is not intractable, it is also not possible to >> use simple lexing tools (e.g. flex) to handle such syntax. I would >> therefore like to propose the following change to the current draft >> specification: >> >> "The characters ']' and '}' may not appear anywhere in a non-delimited >> datavalue" >> >> James. >> -- >> T +61 (02) 9717 9907 >> F +61 (02) 9717 3145 >> M +61 (04) 0249 4148 >> _______________________________________________ >> 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 > -- T +61 (02) 9717 9907 F +61 (02) 9717 3145 M +61 (04) 0249 4148 _______________________________________________ ddlm-group mailing list ddlm-group@iucr.org http://scripts.iucr.org/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- Follow-Ups:
- References:
- [ddlm-group] Characterset of non-delimited strings inside compounddata items (James Hester)
- Re: [ddlm-group] Characterset of non-delimited strings insidecompound data items (Herbert J. Bernstein)
- Prev by Date: Re: [ddlm-group] Characterset of non-delimited strings insidecompound data items
- Next by Date: Re: [ddlm-group] Characterset of non-delimited strings insidecompound data items
- Prev by thread: Re: [ddlm-group] Characterset of non-delimited strings insidecompound data items
- Next by thread: Re: [ddlm-group] Characterset of non-delimited strings insidecompound data items
- Index(es):