Skip to content

WSCL issue: sequence-definition #50

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

WSCL issue: sequence-definition #50

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
e965167
Issue: sequence-definition
jcguu95 May 17, 2024
65f84f7
Add a name for the proposal.
jcguu95 May 19, 2024
42c62c4
Make the proposal more formal.
jcguu95 May 19, 2024
1a64c85
suggestion by yitzchak
jcguu95 May 25, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
72 changes: 72 additions & 0 deletions wscl-issues/draft/sequence-definition
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,72 @@
Issue: SEQUENCE-DEFINITION
Forum: Cleanup
Category: CLARIFICATION
Status: draft
Edit History: 16-May-24, Version 1 by Jin-Cheng Guu
References: SEQUENCE

Problem Description:

In the draft ANSI Common Lisp specification, the description of the system
class SEQUENCE [a] conflicts with the description of the Sequence Concepts
[b], where

[a]: The types vector and the type list are disjoint subtypes of type
sequence, but are not necessarily an exhaustive partition of sequence.

[b]: A sequence is an ordered collection of elements, implemented as
either a vector or a list.

Proposal: (SEQUENCE:A-SEQUENCE-CAN-BE-SOMETHING-ELSE)

This proposal changes the description of the Sequence Concepts so that [b]
instead reads:

> A sequence is an ordered collection of elements, implemented either as a
vector, a list, or possibly some other implementation-defined object.

Test Cases:

N/A (Test cases are difficult to provide, because conformating
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(subtypep 'sequence '(or vector list)) could return T NIL or NIL NIL on an implementation conforming to this proposal, but NIL T would indicate nonconformance.

Also: "conforming"

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about this.. For a conforming implementation, we do need (subtypep '(or vector list) 'sequence) to return T T. However, the point of this issue is to give such an implementation the freedom to have something else in the type sequence.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You read the arguments backwards. I'm saying you can test whether sequence is a subtype of (or vector list), not the other way around. If any non-list non-vector sequences are possible, sequence is not a subtype of (or vector list).

Of course I suppose this proposal doesn't necessarily require implementations to have non-vector non-list sequences, so maybe the subtype is inappropriate after all. Considered that way, having test cases at all would be inappropriate, since it's just making the standard more flexible without requiring any implementation to make any changes whatsoever.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am still confused. Why would (subtypep 'sequence '(or vector list))'s returning NIL T indicate nonconformance to this proposal? This proposal aims to provide the freedom for an implementation to have sequence to possibly have things more than just vectors and lists.

Copy link
Member

@yitzchak yitzchak May 25, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A value of NIL, T or NIL, NIL indicates the implementation does not conform to the current [b].

For this issue, the test cases would not indicate conformance or non-conformance, but indicate whether LIST and VECTOR are exhaustive for the typespace of SEQUENCE. Supporting extensible sequences would require returning NIL, T, I would think.

Test Cases:

  (defun one ()
    (subtypep 'sequence '(or vector list)))

  (one) ; => T, T

Rationale:

  This is a plain contradiction in dpANS.

Current Practice:

  ABCL 1.9.3-dev-fasl43
    (one) ; => NIL, NIL

  SBCL 2.4.1
    (one) ; => NIL, T

  CLASP cclasp-boehmprecise-2.5.0-247-g4b148619f-g85ffab47-cst
    (one) ; => T, T

  ECL 23.9.9-f477a3ef
    (one) ; => T, T

  CMU 2024-03-10 18:28:32 (21E Unicode)
    (one) ; => T, T

  CCL 1.12-f98
    (one) ; => T, T

implementations are not expected to expose its definition of a SEQUENCE
programmatically.)

Rationale:

For Common Lisp implementations that support user defined sequences via a
mechanism like Extensible Sequences LIST and VECTOR will not be an
exhaustive partition of SEQUENCE. In this case [a] is an accurate statement,
but [b] will not be sufficient.

Current Practice:

SBCL 2.4.1
(slot-value (sb-kernel::specifier-type 'sequence) 'sb-kernel::types)
;; => (#<SB-KERNEL:CONS-TYPE CONS>
#<SB-KERNEL:MEMBER-TYPE NULL>
#<SB-KERNEL:ARRAY-TYPE VECTOR>
#<SB-KERNEL:NAMED-TYPE SB-KERNEL:EXTENDED-SEQUENCE>)

Cost to Implementors:

None.

Cost to Users:

None.

Cost of non-adoption:

None.

Benefits:

Remove a conflict from the standard.

Aesthetics:

No influence.

Discussion:

None.