VOUnits: _another_ version, based on implementation feedback
Markus Demleitner
msdemlei at ari.uni-heidelberg.de
Tue Oct 29 12:46:10 PDT 2013
Hi Rick,
On Tue, Oct 29, 2013 at 03:18:09PM +0100, Frederic V. Hessman wrote:
> > The unit production on p. 39 allows
> >
> > unit: STRING QUOTED_STRING
> >
> > which is there to allow prefixes on quoted units, like
> > M'jupiterMass'. I'm fairly opposed to that; as Norman writes in
> > 2.12.1, "this is not often likely to be a good idea," and I could
> > find stronger language about it.
> >
> > Does *anyone* actually want this? If yes, so be it, but if not,
> > let's not do it. It complicates the already ungraceful quoted units
> > business even more.
>
> I thought the only purpose of this was to insure a robust parsing
> of unusual/ambiguous units? I don't remember the example off hand,
> but there were two different ways of parsing the unit string.
If "this" is "quoted units" then yes, the purpose is to keep VOUnits
parsers from interpreting furlong as femto-urlong. But that wasn't
what I disputed here.
If "this" is "prefixes on quoted units" I'd need a bit more
elaboration of the statement.
> Thus, it doesn't have a semantic but just a technical function and
> so should be utterly harmless.
Well, "utterly"... it certainly is not an implementation nightmare,
but if we want this, we should really put more work into it. The
way the grammar stands now, something like
gargantuan'jupiterMass'
would be grammatical, and we certainly don't want this, do we? I
believe if what we want to do here is allow prefixes on quoted units,
things should look somewhat like
siPrefix: "u" | "c" | "d" | "da" | "h" |...
unit: ...
| siPrefix QUOTED_STRING
-- and that would be ugly because we don't otherwise talk about SI
prefixes in the grammar, and I'd not feel to good about introducing
them now.
If, on the other hand, the "gargantuan" above should only blow up
during unit interpretation, we have another error type that would
come out of the parser, something like "invalid SI prefix", and
that's arguably a complication of the interface, not to speak of the
parser function for the unit production.
So, it may still be on the mostly harmless side of specification
prose, but I'd still say we shouldn't just do it because we can --
unless somebody clearly speaks out in favour of it (so we have a
target for pointing fingers later:-) I'd still prefer if it weren't
there.
Cheers,
Markus
More information about the semantics
mailing list