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