## Named quasi-literals

Traditional Scheme has only a few kinds of values, and thus only a few builtin kinds of literals. Modern Scheme allows defining new types, so it is desirable to have a mechanism for defining literal values for the new types.

Consider the `URI` type. You can create a new instance of a `URI` using a constructor function:

    (URI "http://example.com/")

This isn’t too bad, though the double-quote characters are an ugly distraction. However, if you need to construct the string it gets messy:

    (URI (string-append base-uri "icon.png"))

Instead use can write:

    &URI{http://example.com/}

or:

    &URI{&[base-uri]icon.png}

This syntax is translated by the Scheme reader to the more familiar but more verbose equivalent forms:

    ($construct$:URI "http://example.com/")
    ($construct$:URI $<<$ base-uri $>>$ "icon.png")

So for this to work there just needs to be a definition of `$construct$:URI`, usually a macro. Normal scope rules apply; typically you’d define `$construct$:URI` in a module.

The names `$<<$` and `$>>$` are bound to unique zero-length strings. They are used to allow the implementation of `$construct$:URI` to determine which arguments are literal and which come from escaped expressions.

If you want to define your own `$construct$:`tag``, or to read motivation and details, see the SRFI 108 specification.

`extended-datum-literal` `::=`
`&` `cname` `{` [`initial-ignored`] `named-literal-part`* `}`
| `&` `cname` `[` `expression`* `]{` [`initial-ignored`] `named-literal-part`* `}`
`cname` `::=` `identifier`
`named-literal-part` `::=`
any character except `&`, `{` or `}`
| `{` `named-literal-part`+ `}`
| `char-ref`
| `entity-ref`
| `special-escape`
| `enclosed-part`
| `extended-datum-literal`