Skip to content

[ new ] Data.SnocList.Base (re #2684)#2982

Open
gallais wants to merge 9 commits intoagda:masterfrom
gallais:snoclists
Open

[ new ] Data.SnocList.Base (re #2684)#2982
gallais wants to merge 9 commits intoagda:masterfrom
gallais:snoclists

Conversation

@gallais
Copy link
Copy Markdown
Member

@gallais gallais commented Apr 16, 2026

This is offering feature parity with Data.List.Base (+ additional functions like fish & chips)

In the process, I fixed a bug in Data.List.Base: linesBy was trying to be too clever about
empty lines when it's just more principled to return a trailing empty line if there is indeed
a trailing newline character at the end of the string being considered.

@gallais gallais added the bug label Apr 16, 2026
Copy link
Copy Markdown
Collaborator

@JacquesCarette JacquesCarette left a comment

Choose a reason for hiding this comment

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

One minor nitpick.

Otherwise, this would be a lovely test case for a "rich" metaprogramming setup where this fully commented source file ought to be derivable.

Comment thread src/Data/String/Base.agda
Comment thread src/Data/SnocList/Base.agda Outdated
Comment thread src/Data/SnocList/Base.agda Outdated
infixl 5 _<:_

data List< (A : Set a) : Set a where
[<] : List< A
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Part of me likes the clean separation of the constructors, going as far as to rename [] but I can't help thinking this is a case where the ability to overload constructor types/reuse constructor names is a virtue.

Would there be a problem with using [] throughout?


data List< (A : Set a) : Set a where
[<] : List< A
_<:_ : List< A → A → List< A
Copy link
Copy Markdown
Collaborator

@jamesmckinna jamesmckinna Apr 18, 2026

Choose a reason for hiding this comment

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

Separately to the above, but related, the library expends considerable effort on 'left'/'right' superscript designators for concepts which arise as 'handed' notions.

I fully understand the different (symbolic/naming) legacy which this PR draws on (including 'fish' and 'chips'... ) and in this instance it may be a case of having constructor symbols clash with defined function names ... but why not _∷ˡ_ and _∷ʳ_ instead?

... and then fish and chips become eg _ˡ++ʳ_ and _ʳ++ˡ_ which would be 'more stdlib-like'...?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Worth having the discussion. I rather like the current names in Snoc. (I think we over-use left/right, to be honest; but that's a complete-rewrite issue, not even an item worth contemplating in v3.0). _ˡ++ʳ_ is not nice at all, IMHO.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

and then fish and chips become eg _ˡ++ʳ_ and _ʳ++ˡ_ which would be 'more stdlib-like'...?

Note that fish & chips additionally document the type of the output whereas these do not

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Not a hill I planned to die on, but I think that 'consistency' in naming ('style') is something worth striving for...

Co-authored-by: jamesmckinna <31931406+jamesmckinna@users.noreply.github.com>
@Taneb Taneb linked an issue Apr 22, 2026 that may be closed by this pull request
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Snoclists?

3 participants