• Places
    • Home
    • Graphs
    • Prefixes
  • Admin
    • Users
    • Settings
    • Plugins
    • Statistics
  • CPACK
    • Home
    • List packs
    • Submit pack
  • Repository
    • Load local file
    • Load from HTTP
    • Load from library
    • Remove triples
    • Clear repository
  • Query
    • YASGUI SPARQL Editor
    • Simple Form
    • SWISH Prolog shell
  • Help
    • Documentation
    • Tutorial
    • Roadmap
    • HTTP Services
  • Login

5 SWI-Prolog extensions
All Application Manual Name SummaryHelp

  • Documentation
    • Reference manual
      • SWI-Prolog extensions
        • Lists are special
        • The string type and its double quoted syntax
        • Syntax changes since SWI-Prolog 7
        • Dicts: structures with named arguments
        • Integration of strings and dicts in the libraries
          • Dicts and option processing
          • Dicts in core data structures
          • Dicts, strings and XML
          • Dicts, strings and JSON
          • Dicts, strings and HTTP
        • Single Sided Unification rules
        • Remaining issues
    • Packages

5.5 Integration of strings and dicts in the libraries

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.

5.5.1 Dicts and option processing

System predicates and predicates based on library library(options) process dicts as an alternative to traditional option lists.

5.5.2 Dicts in core data structures

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

5.5.3 Dicts, strings and XML

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

5.5.4 Dicts, strings and JSON

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.

5.5.5 Dicts, strings and HTTP

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

ClioPatria (version V3.1.1-51-ga0b30a5)