Re: ACTION 614-12: Smart Quotes

> On 14 Sep 2015, at 14:47, Robie, Jonathan <jonathan.robie@emc.com> wrote:
> 
> I have two concerns about the chevron proposal.
> 
> 1. I think we should use characters that anybody knows how to type. Most programmers probably don't know how to type a chevron on their keyboard, and the way to do this depends on the OS and keyboard.  

There are many people in the world who are more likely to have chevrons on their keyboard than curly braces. Even in Anglophone countries, the programmers in question are generally working in the area of text processing, so they are very likely to be familiar with richer character sets.


> After all, smart quotes are a convenience feature, and it's only convenient if they are easy to type.  This isn't something that "tooling" is likely to fix for most of us in the near future.
> 
> 2. I don't like the fact that « is the opposite of « and you have to count the number of «'s in a nested construction to know whether a given « introduces a string literal or an expression.
> 

I think it will usually be pretty clear in practical cases, and I think it does have the benefit that the two symbols are clearly related.

Choosing chevron was inspired by the fact that (a) it has a relationship to our traditional use of angle brackets, and (b) chevrons are used for quoting text in many languages.

Looking at requirements, we need:

(a) an opening symbol that introduces a computed string (or whatever we call it). This can be any symbol that can appear without ambiguity at the start of an expression. There are many choices available, for example ~~[, <[, «, etc etc. 

(b) a closing symbol that terminates a computed string. It’s desirable that this (i) is symmetric with the symbol chosen for (a), and (ii) is rarely used within the kind of string/text that we want to express, (iii) is capable of being escaped, ideally using one of the escape conventions already used in XQuery

(c) an opening symbol that introduces an expression embedded within a computed string. It’s desirable that this (i) is rarely used within the kind of string/text that we want to express, (ii) is capable of being escaped, ideally using one of the escape conventions already used in XQuery.

(d) a closing expression to mark the end of an embedded expression. This is largely cosmetic, since the end of an expression can be detected without a special marker. It’s desirable that this is symmetric with (c).

How about <[ ]> <{ }> ? I like the fact that it retains the tradition of using angle brackets for switching between literal text and non-text information. “<[“ has vague connotations of CDATA sections, and <{ retains the “{“ which is associated with embedded expressions elsewhere in the language. And it’s visually clear.

let $json := <[ { “name”: { “first”:<{ $first }>,  “last”:<{ $last }> } ]>

Not sure about escaping <{ and ]>...

Despite Jonathan’s objections, I do actually like using the same symbol for (a+c) and for (b+d). People then only have two symbols to remember and are less likely to get them confused.

Michael Kay
Saxonica

Received on Monday, 14 September 2015 15:59:27 UTC