Re: Minus signs in N3 (again)

On Monday 14 July 2003 06:20, Sandro Hawke wrote:

> > > The current solution is mapping sequences of "-" and "_" into sequences
> > > of  "_"
> > > by taking a contiguous sequence of - and _, replacing _ with 0 and -
> > > with 1,
> > > then adding a leading "1", taking what you have as a binary number,
> > > subtracting 1 from the result, and then writing that many _ signs.
> >
> > But most damningly, the escape mechanism devised to address this issue is
> > not only unwieldy and unfriendly, it is not even complete: how do you
> > escape "a-to-_"? My guess is cwm would currently escape it as a__to___,
> > which collides with the encoding of "a-to__". Not to mention the fact
> > that many N3 parsers don't seem to implement "identifier munging" at all
> > (see http://infomesh.net/2002/n3qname.html).
>
> I wouldn't argue this mapping was friendly or wieldy, but I'm not sure
> you've proven it's incorrect: as I follow the algorithm, "-_" turns
> into binary 10, prefix with 1 to get 110, subtract one to get five, so
> we get "a__to_____".  As far I can tell, cwm doesn't actually
> implement any mangling, though, and there's nothing in the test suite
> for it.

Yeah, you're right, I mis-read the spec. Sorry.

> > So here's hoping Tim is now ready to excise this wart from N3. If he were
> > serious about banishing '-' from RDF IDs, he should have fought that
> > battle a long time ago, back when RDF was being finalized. It would seem
> > much too late for that now, so the sensible thing to do is just accept
> > it, properly accommodate it, and move on.
>
> Why can't it be banished as a "best practice" instead of formally?
> Kind of like using identifiers like x0d457e059624dc933b1566c4fe5da in
> a C: it's allowed; it's just a really bad idea.

Because I don't think you'll be able to forge a consensus at this point that 
'-' and '.' are truly bad to use, especially if many people have already 
decided to use them in their current schemas.

> Meanwhile, I think forcing people to be careful with whitespace around
> operators is an iffy proposition in a modern formal language.
>
> > And while we're at it, the same thing goes for '.'. I expect some will
> > reflexively protest that the use of '.' as the statement terminator makes
> > this problematic. They might have a leg to stand on if it weren't for the
> > fact that '.' is already also permitted within numeric (rational)
> > literals.
>
> "." is also being used as an infix path operator now, which I think
> foils your plan.

That's news to me. I can understand people disliking '!'. But why not use '/'?

> Of course, this forces people to use spaces after the "." which ends a
> sentence and not to use spaces after the "." which is an operator....
> So much for my "iffy proposition".  :-)
> 
> (I did once design a language which cared about whether you had spaces
> between a term and an open paren, so (f (x)) was a pair while (f(x))
> was a function application, ... I managed to justify that to myself.
> As I recall, Tim razzed me for it.  :-)
>
>       -- sandro
>
> [1] http://lists.w3.org/Archives/Public/www-rdf-interest/2003Jul/0112.html

And again, the whitespace issue is moot if we can just stay away from 
operators that start with '-' or '.'.
-- 
Kevin D. Keck
http://vimss.lbl.gov/~kdkeck/
510-486-4856

Received on Monday, 14 July 2003 12:08:33 UTC