Discussion List Archives

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

Re: [ddlm-group] Simon's elide proposal

Dear Herbert, forgive me, but it seems I've been 'thinking aloud' too much
in recent posts at the expense of clarity.

The point I was trying to make is that scheme F works on its own by
*not* requiring the lexer to interpret the escape sequence before it
has identified the delimiters. So in practical terms, if I were to code
for scheme F and later a python scheme were to be adopted, it would
not be a simple extension in terms of coding to incorporate the
python escape sequences, which need to be processed in order to correctly
identify the delimiters - hence the 'incompatabilty' of scheme F with python -
purely a coding issue as far as I can see.

Agreed, this enforces your assertions that we need fully documented specs.

Cheers

Simon



From: Herbert J. Bernstein <yaya@bernstein-plus-sons.com>
To: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
Sent: Wednesday, 12 January, 2011 21:31:37
Subject: Re: [ddlm-group] Simon's elide proposal

According to James and John B., the interpretation of proposal
F is that "\\n"" would _not_ be interpreted as """.  If they
are mistaken and "\\n"" is interpreted as """ than my original
concern is valid, and your proposal to _not_ completely resolve
Ralf's point.

This sort of discussion is precisely why we need to work from
fully documented specs of whatever we will do on quoting,
preferably with supporting software and examples.  We will
be at this for a very long time or make serious mistakes
if we don't do that.

I know I sounds like the voice of doom when I say that, but
I think it is a realistic estimate based on what has happened
thus far with CIF2.

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, 12 Jan 2011, SIMON WESTRIP wrote:

> I accept that in these examples, Ralf's proposal provides a 'cleaner'
> presentation when using the treble-quotes delimiters (I note though that
> using \n; delimiters would provide an even 'cleaner' presentation in many of
> these examples).
>
> I also cannot fault the python approach per se, but am uneasy about its
> suitability in the
> context of CIF.
>
> Perhaps most importantly with regard to using proposal F as a building block
> for
> a more complete python-type eliding scheme, I am concerned that proposals of
> type F
> that operate after the identification of the delimiters, are not appropriate
> when
> using the initial lexical analysis to handle escape sequences. For example,
> using scheme F,
> if the \<newline> were to be processed in the sequence "\<newline>"" before
> the "" were processed,
> would the lexer not think it had found the closing """ ?
>
> The intention of scheme F is to address the issues of storing values that
> may contain all the CIF delimiters
> within a CIF, with the bonus of providing a line-folding protocol that is
> part of the base syntax, with
> minimal overhead with respect to manipulation of the data to be stored and
> the complexity of CIF syntax.
> Unfortunately, I don't believe it can be considered a subset of python - so
> doesn't help the compromise much :-(
>
> Cheers
>
> Simon
>
>
>
>
>
> ____________________________________________________________________________
> From: Herbert J. Bernstein <yaya@bernstein-plus-sons.com>
> To: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
> Cc: FCB <fcb@epsilon.pair.com>
> Sent: Wednesday, 12 January, 2011 19:29:29
> Subject: Re: [ddlm-group] Simon's elide proposal
>
> My thanks for John for giving these translations into
> Simon's proposal. They are similar to what we have
> had to do for many years with the line folding protocol
> in CIF1 and semi-colon-delimited string.
>
> Correcting my typos and summarizing thre first couple of
> examples, it appears that we are being presented with the following
> choice.  Ralf, Simon and John, please correct me for what
> I have misunderstood.  If I have this right, Ralf's proposal
> seems a cleaner way to do each task, but Simon's does
> seem able to cope.  I have verified that Simon's proposal
> is a valid non-conflicting subset of Ralf's proposal, even
> including the end-of-line elide to post elide the extra
> quote marks.  All the more reason to support the proposed
> compromise -- start with Simon's proposal and then explore
> fully extending to the cleaner whole of Ralf's proposal.
> Note that the r"""...""" and r'''...''' constructs would
> do a particularly neat job of preserving elides to be
> passed on to higher levels.
>
> A.  Ralf's proposal:
>
> One way to deliver " to an application would be """\""""
> One way to deliver ' to an application would be '''\''''
> An alternative, is, of course '"' in the first case, and "'"
> in the second, but if we are working with both, as in say,
> to deliver '"O'" to an application we could use """'"O'\""""
> or '''\'"O'"'''
>
> One way to deliver \" to an application for its own elide
> processing would be r"""\""""
> One way to deliver \' to an application for its own elide
> processing would be r'''\''''
> An alternative, is, of course '\"' in the first case, and
> "\'" in the second, but if we are working with both, as in
> say to deliver '"O'\" to an application we could use
> r"""'"O'\"""".
>
> B.  Simon's proposal
>
> One way to deliver " to an application would be """"\\n"""
> One way to deliver ' to an application would be ''''\\n'''
> An ternative is, of course '"' in the first case, and "'"
> in the second, but is we are working with both, as in say
> to deliver '"O'" to an application we could use
> """'"O'"\n""" or ''''\n"I'"'''
>
> One way to deliver \" to an application for its own elide
> processing would be """\\\"\\n"""
> One way to deliver \' to an application for its own elide
> processing would be '''\\\'\\n'''
> An alternative, is, of course '\"' in the first case, and
> "\'" in the second, but if we are working with both, as in
> say to deliver '"O'\" to an application we could use
> """'"O'\\\"\\n""".
>
>
>
> =====================================================
>   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, 12 Jan 2011, Bollinger, John C wrote:
>
> > On Wednesday, January 12, 2011 7:39 AM, Herbert J. Bernstein wrote:
> >
> >> Please state the proposal F handling of the following strings, both
> syntax and semantics, here presented in their python form
> >
> > I take this as a response to James's invitation, but inasmuch as he is (I
> hope) sleeping at the moment, I will endeavor to pick up the flag.
> >
> >> """\""""
> >> '''\''''
> >
> > Taking the first of these as representative of this pair:
> >
> > This is a string containing one quote character.  The best elision under
> proposal F would be
> > """"\
> > """
> > Easier, however, would be to write it as one of these:
> > '"'
> > '''"'''
> >
> >> r"""\"'''
> >> r'''\''''
> >
> > Supposing that you mean r"""\"""" in the former case, and taking the
> second as representative of the pair:
> >
> > This is a string containing a backslash character followed by an
> apostrophe character.  The best proposal F elision would be
> > '''\'\
> > '''
> > Simpler representations would be
> > '\"'
> > '''\"'''
> >
> >
> >> """\
> >> \"\
> >> """
> >
> > The string contains one quote character, just like the first example.  The
> elision is therefore the same.
> >
> >> r"""\
> >> \"\
> >> """
> >
> > This is a string containing six characters: backslash, newline, backslash,
> quote, backslash, newline.  The best elision for this string under proposal
> F would be:
> > """\\
> > \\"\\
> > """
> > There is an equivalent form using ''', but it is no simpler.
> >
> >
> > Cheers,
> >
> > John
> > --
> > John C. Bollinger, Ph.D.
> > Department of Structural Biology
> > St. Jude Children's Research Hospital
> >
> >
> >
> >
> > Email Disclaimer:  www.stjude.org/emaildisclaimer
> >
> > _______________________________________________
> > 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
>
>
_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
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.