Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
ansi-test
ansi-test
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 13
    • Issues 13
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 6
    • Merge Requests 6
  • Operations
    • Operations
    • Incidents
  • Analytics
    • Analytics
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • ansi-test
  • ansi-testansi-test
  • Issues
  • #25

Closed
Open
Created Dec 01, 2019 by Michał Herda@mherda🤔Contributor

Factor and annotate PRINT-UNREADABLE-OBJECT-{2,3}

These two tests check the following from the spec:

If type is true, the output from forms is preceded by a brief description of the object's type and a space character. If identity is true, the output from forms is followed by a space character and a representation of the object's identity, typically a storage address.

Strict reading of the spec implies that that #<NULL > and #< #x41300> are correct printouts in cases where, respectively, :TYPE is true but :IDENTITY is false, and where :IDENTITY is true but :TYPE is false.

I know at least one implementation (CCL) whose maintainers argue that the strictly-standard-compliant variants are ugly, due to the extra space that does not delimit meaningful data inside the angle brackets, and therefore #<NULL> and #<#x41300> are preferable. A further claim is that the spec does not take into account situations where :TYPE and BODY are null but :IDENTITY is true and where :IDENTITY and BODY are null but :TYPE is true, and therefore this is an omission in the spec. Furthermore, it is very unlikely that any existing code depends on this behaviour, as the output of PRINT-UNREADABLE-OBJECT is meant to be eye candy for human readers (which it is somewhat less of, due to the extra space) and to signal errors in the Lisp reader (which behaviour is kept intact, since the #< in the beginning is not modified).

I propose to factor out checks for spaces in these two situations into a separate pair of testcases and to annotate these tests with :PRINT-UNREADABLE-OBJECT-EXTRA-SPACE (and debatably :ANSI-SPEC-PROBLEM), so an implementation may choose to ignore these tests and willingly not conform to that part of the specification.

I can perform these changes and make a MR if you think that this request is agreeable.

Edited Dec 01, 2019 by Michał Herda
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None