While lacking proper string support and dicts when designed, many
predicates and libraries use interfaces that must be classified as
suboptimal. Changing these interfaces is likely to break much more code
than the changes described in this chapter. This section discusses some
of these issues. Roughly, there are two cases. There where key-value
associations or text is required as input, we can facilitate
the new features by overloading the accepted types. Interfaces that
produce text or key-value associations as their output however
must make a choice. We plan to resolve that using either options that
specify the desired output or provide an alternative library.
System predicates and predicates based on library library(options)
process dicts as an alternative to traditional option lists.
Some predicates now produce structured data using compound terms and
access predicates. We consider migrating these to dicts. Below is a
tentative list of candidates. Portable code should use the provided
access predicates and not rely on the term representation.
- Stream position terms
- Date and time records
The XML representation could benefit significantly from the new
features. In due time we plan to provide an set of alternative
predicates and options to existing predicates that can be used to
exploit the new types. We propose the following changes to the data
representation:
- The attribute list of the
element(Name, Attributes, Content)
will become a dict.
- Attribute values will remain atoms
- CDATA in element content will be represented as strings
The JSON representation could benefit significantly from the new
features. In due time we plan to provide an set of alternative
predicates and options to existing predicates that can be used to
exploit the new types. We propose the following changes to the data
representation:
- Instead of using
json(KeyValueList), the new interface
will translate JSON objects to a dict. The type of this dict will be json.
- String values in JSON will be mapped to strings.
- The values
true, false and null
will be represented as atoms.
The HTTP library and related data structures would profit from
exploiting dicts. Below is a list of data structures that might be
affected by future changes. Code can be made more robust by using the library(option)
library functions for extracting values from these structures.
- The HTTP request structure
- The HTTP parameter interface
- URI components
- Attributes to HTML elements
