Inconsistent behavior of "..." in [] constructor with non-list values #1368

New issue

2025-09-30T15:18:42Z

HMarcien commented

2025-09-30 15:18:42 +00:00

(Migrated from github.com)

As discovered during the documentation effort in PR #1367 , the ... operator in the [...] list constructor has some counter-intuitive behaviors when the preceding expression is not a list.

This issue is to track the work to define and implement a more consistent and user-friendly behavior.

As Vyzo noted in the PR review, there are two main problems:

Discarding Behavior: An expression like [1 2 3 ... 4] evaluates to (1 2 4), discarding the 3. A possible alternative behavior would be to treat the non-list value as a tail, producing (1 2 3 . 4).
Unwrapping "Bug": An expression like [42 ...] evaluates to 42 instead of (42). This is considered a bug and is inconsistent with the general list-building behavior.

The goal is to fix these inconsistencies and then update the documentation to reflect the new, correct behavior.

As discovered during the documentation effort in PR #1367 , the `...` operator in the `[...]` list constructor has some counter-intuitive behaviors when the preceding expression is not a list. This issue is to track the work to define and implement a more consistent and user-friendly behavior. As Vyzo noted in the PR review, there are two main problems: 1. **Discarding Behavior:** An expression like `[1 2 3 ... 4]` evaluates to `(1 2 4)`, discarding the `3`. A possible alternative behavior would be to treat the non-list value as a tail, producing `(1 2 3 . 4)`. 2. **Unwrapping "Bug":** An expression like `[42 ...]` evaluates to `42` instead of `(42)`. This is considered a bug and is inconsistent with the general list-building behavior. The goal is to fix these inconsistencies and then update the documentation to reflect the new, correct behavior.

drewc commented

2025-09-30 15:38:24 +00:00

(Migrated from github.com)

I think that destructuring a non-list should be an error, not "maybe turn a
the tail into an atom we try to splice an atom as the second last pair ...
we'll turn that atom into a cons and steal the cons from the next one
only if it's the last one, otherwise unspecified"

Why does "splice 3" become "destructure the following cons only if it is
the last the last cons"? I disagree 100% with that idea, it makes no sense.

I also think the *Unwrapping "Bug" *should be an error. Rather than
making things worse we should make them better :).

ie:

What should happen here?
[1 2 3 ... 4 ... 5 ...]
How about here?

[1 ... 2 ]
I think the only way to make it consistent as a list builder is to error
when trying non-consistent non-list behavior. No Monkey patching allowed.

Thoughts? --drewc

On Tue, Sep 30, 2025 at 8:19 AM Henri Fouda @.***>
wrote:

HMarcien created an issue (mighty-gerbils/gerbil#1368)
https://github.com/mighty-gerbils/gerbil/issues/1368

As discovered during the documentation effort in PR #1367
https://github.com/mighty-gerbils/gerbil/pull/1367 , the ... operator
in the [...] list constructor has some counter-intuitive behaviors when
the preceding expression is not a list.

This issue is to track the work to define and implement a more consistent
and user-friendly behavior.

As Vyzo noted in the PR review, there are two main problems:

Discarding Behavior: An expression like [1 2 3 ... 4] evaluates to (1
2 4), discarding the 3. A possible alternative behavior would be to
treat the non-list value as a tail, producing (1 2 3 . 4).
2.

Unwrapping "Bug": An expression like [42 ...] evaluates to 42
instead of (42). This is considered a bug and is inconsistent with the
general list-building behavior.

The goal is to fix these inconsistencies and then update the documentation
to reflect the new, correct behavior.

—
Reply to this email directly, view it on GitHub
https://github.com/mighty-gerbils/gerbil/issues/1368, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADVTXIA4HALMOMRID2MGN33VKNOTAVCNFSM6AAAAACH5ESF72VHI2DSMVQWIX3LMV43ASLTON2WKOZTGQ3DSOJYHAYTOOA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

I think that destructuring a non-list should be an error, not "maybe turn a the tail into an atom we try to splice an atom as the second last pair ... we'll turn that atom into a cons and steal the cons from the next one only if it's the last one, otherwise unspecified" Why does "splice 3" become "destructure the following cons only if it is the last the last cons"? I disagree 100% with that idea, it makes no sense. I also think the *Unwrapping "Bug" *should be an error. Rather than making things worse we should make them better :). ie: What should happen here? *[1 2 3 ... 4 ... 5 ...]* How about here? *[1 ... 2 ]* I think the only way to make it consistent as a list builder is to error when trying non-consistent non-list behavior. No Monkey patching allowed. Thoughts? --drewc On Tue, Sep 30, 2025 at 8:19 AM Henri Fouda ***@***.***> wrote: > *HMarcien* created an issue (mighty-gerbils/gerbil#1368) > <https://github.com/mighty-gerbils/gerbil/issues/1368> > > As discovered during the documentation effort in PR #1367 > <https://github.com/mighty-gerbils/gerbil/pull/1367> , the ... operator > in the [...] list constructor has some counter-intuitive behaviors when > the preceding expression is not a list. > > This issue is to track the work to define and implement a more consistent > and user-friendly behavior. > > As Vyzo noted in the PR review, there are two main problems: > > 1. > > *Discarding Behavior:* An expression like [1 2 3 ... 4] evaluates to (1 > 2 4), discarding the 3. A possible alternative behavior would be to > treat the non-list value as a tail, producing (1 2 3 . 4). > 2. > > *Unwrapping "Bug":* An expression like [42 ...] evaluates to 42 > instead of (42). This is considered a bug and is inconsistent with the > general list-building behavior. > > The goal is to fix these inconsistencies and then update the documentation > to reflect the new, correct behavior. > > — > Reply to this email directly, view it on GitHub > <https://github.com/mighty-gerbils/gerbil/issues/1368>, or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AADVTXIA4HALMOMRID2MGN33VKNOTAVCNFSM6AAAAACH5ESF72VHI2DSMVQWIX3LMV43ASLTON2WKOZTGQ3DSOJYHAYTOOA> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> >

vyzo commented

2025-09-30 15:39:41 +00:00

(Migrated from github.com)

yeah, error is also consistent behavior.

fare commented

2025-10-07 00:03:17 +00:00

(Migrated from github.com)

I think ... should basically behave as if you invoke append, and we have:

> (append '(1 2 . 3) '(4 5))
*** ERROR IN (stdin)@7.1-7.27 -- (Argument 1) PROPER LIST expected

So I vote for an error.

I think `...` should basically behave as if you invoke `append`, and we have: ``` > (append '(1 2 . 3) '(4 5)) *** ERROR IN (stdin)@7.1-7.27 -- (Argument 1) PROPER LIST expected ``` So I vote for an error.

Sign in to join this conversation.