RE: [Ogdl-core] Extraneous Commas and Parens

[didge <di...@fo...>]

For me, this is a robustness issue.  Being tolerant is great, but not at the
cost of robustness.  But, being new here, I'm not sure what exactly what
being tolerant means to you.

Being tolerant, to me, means that users are free to use white space,
indentation, grouping, quoting or blocking as it makes sense for their needs
and tastes.

But I'm still interested in hearing anyone's experience in which extra
punctuation was being produced (and why) because I think that since extra
punctuation has no useful purpose, it can only be the product of sloppiness,
laziness or errors on the part of the producer.

Disallowing extra punctuation in my humble opinion does not make OGDL any
less tolerant according to my definition and makes OGDL more robust because
OGDL without extra punctuation is easier to read and can't mask any
potential errors.

I think I've made my point regarding extra punctuation, so I won't belabor
it anymore.  But please read my other responses below to points you make, if
you have the time :)

Regards,

didge

Rolf wrote:
> 
> didge wrote:
> 
> > Allowing for a single trailing comma and empty end of group, each of
> these
> > examples is suspicious because the extra punctuation suggests that there
> is
> > something missing (denoted by the '?'):
> >
> >  ?,a
> >
> >  a,?,
> >
> >  ?(a)
> >
> >  a(?(b))
> >
> >  a(?())
> >
> >  a,?()
> >
> > Are there any examples of systems or individuals that currently author
> OGDL
> > with extra punctuation and why?
> 
> I want the OGDL parser to be robust and tolerant, that is the main idea.
> 
> Case by case:
> 
> 1)   ,a    +1 to signal this as an error
> 
> 2)   a,,   -0. I don't care to much, but tolerance is for me desirable.
>            Just be sure that this will not round trip, no empty nodes
>            will be generated.

Shouldn't a round trip reproduce as accurately as possible the input?  In
other words, if the input contains case 2, should I expect this to be
preserved in a round trip?

What is the definition of a round trip?

> 3)   ()   -1. Empty group should be allowed. No nodes are generated.
> 4)   (a)  -1. Equivalent to scalar 'a'.
> 5)   ((a)) -1. Equivalente to scalar 'a'.
> 
> Once thing is that we disallow nodes after groups, and other one is to
> limit groups to more than one element.
> 
> > What would be the downside of not allowing extra punctuation?
> 
> Programs that generate OGDL do not need to care for this special cases,
> that can occur, especially groups with less than 2 element.

To clarify, a group with one element is fine by me.  The problem with cases
3, 4 and 5 is that the grouping suggests that parent nodes for each of the
groups are missing.

> 
> > For my needs, I want to treat extra punctuation as possible errors in
> order
> > to eliminate real errors in my systems as quickly as possible.
> Therefore,
> > my parser will by default disallow extra punctuation (and probably
> trailing
> > commas and empty groups, too), but may include an option to allow them
> if
> > desired.
> 
> Totally acceptable of course, if the option remains. What you require
> from OGDL streams could be considered as a stricter and unambiguous
> syntax, canonical in some sense.
> 

What I want is to clarify the usage of extraneous commas and parens such
that readers and parsers can read some OGDL, see an extra comma and
immediately know that it is an error and not just sloppy data.

I'm not sure what canonical means however.  I do think there is a form that
an OGDL document can have, that might be called canonical form (though I
call it 'normal form' borrowing from RDBMS terminology) in which the stream
is composed of nodes, each of which is separated by line breaks and the
minimum number of space characters necessary to determine structure.

So, for example, the normal form of:

 a  (b)

is

 a
  b