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

[HMarcien]

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]

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: @.***>

[vyzo]

yeah, error is also consistent behavior.

[fare]

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.