Skip to content

[ re #10 ] n-ary functions manipulating lists #1840

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.

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

Merged
merged 1 commit into from
Oct 5, 2022

Conversation

gallais
Copy link
Member

@gallais gallais commented Sep 30, 2022

No description provided.

@jamesmckinna
Copy link
Contributor

I don't know what the library conventions are about pointfree vs. pointwise function composition, but how about

zipWith (suc n@(suc _)) f (v , vs) (w , ws) =
  f zero v w , zipWith n (f ∘ suc) vs ws

versus your

zipWith (suc n@(suc _)) f (v , vs) (w , ws) =
  f zero v w , zipWith n (λ k → f (suc k)) vs ws

@gallais
Copy link
Member Author

gallais commented Oct 1, 2022

I had started with that alternative but it does not typecheck.

@jamesmckinna
Copy link
Contributor

Hmmm. I begin to see why: the type of _∘_ would need to be generalised so that its Level arguments b,c were made dependent (resp. on (x : A), {x : A} (y : B y)... and even then the typechecker really gets confused, trying to unify Levelₙ lsas k ⊔ Levelₙ lsbs k ⊔ Levelₙ lscs k with Levelₙ lsas k ⊔ Levelₙ lsbs k ⊔ Levelₙ lscs k... so consider my query withdrawn... ;-)

... but I can't help wondering what would value dependent levels look like, and how should we expect them to behave?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants