Skip to content
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

[ fix #577 ] generic n-ary functions and products #608

Merged
merged 44 commits into from May 31, 2019

Conversation

@gallais
Copy link
Member

gallais commented Feb 12, 2019

Comes with documentation of the design decisions!

  • (un)curry
  • cong, subst
  • k-th projections
  • hole at position k (cf comment in #577)
  • acting on k-th position (both for arrows & product)
  • removing k-th element
  • adding k-th element
  • README module demonstrating how to use all of this
@MatthewDaggitt

This comment has been minimized.

Copy link
Contributor

MatthewDaggitt commented Feb 13, 2019

Looks great! I should play around with it a bit and see if I can get any other useful things out. A generalised projection function for products would be incredible...

@gallais

This comment has been minimized.

Copy link
Member Author

gallais commented Feb 13, 2019

Come to think of it, Product should probably not be -terminated if we want
un(curry) to be useful in practice...

Edit: and there's still the case of your hole combinator as well as projections.

gallais added 3 commits Feb 13, 2019
In order to define generic projections for n-ary products we need
to be able to import `Data.Fin.Base`. It itself currently imports
`Relation.Nullary.Decidable` which pulls all sorts of `Function.X`
depending on `Relation.Binary.PropositionalEquality` and thus on
n-ary product (because of generic congₙ and substₙ).

This commit cleans up the dependencies of the modules involved in
the cycle and splits off `Relation.Nullary.Decidable.Core` for
simple definitions.
@gallais

This comment has been minimized.

Copy link
Member Author

gallais commented Feb 13, 2019

Let's also try to give a bunch of examples in a README.X.Y.Z module.

@gallais gallais changed the title [ fix #577 ] n-ary (un)curry, cong, and subst [ fix #577 ] generic n-ary functions and product Feb 14, 2019
@gallais gallais changed the title [ fix #577 ] generic n-ary functions and product [ fix #577 ] generic n-ary functions and products Feb 14, 2019
gallais added 6 commits Feb 14, 2019
It makes more sense to call `map` the generalisation of the map
corresponding to the reader monad. It will arrive really soon.
Note that its type will only be inferred if it is used in a context
specifying what the type of the function ought to be. Just like the
usual const: there is no way to infer its domain from its argument.
I'll develop a bit more later today (hopefully).
@gallais

This comment has been minimized.

Copy link
Member Author

gallais commented Feb 14, 2019

Hmm. I don't think that what I called hole is your notion of hole.
I'm going to drop it for the moment.

FTR:

------------------------------------------------------------------------
-- holeₙ : ∀ n (k : Fin n) →
--         (A₁ → ⋯ Aₙ → B) → Aₖ₊₁ → A₁ → ⋯ → Aₖ → Aₖ₊₂ → ⋯ → Aₙ → B

-- As we have seen earlier, `cong` acts on a function's first variable.
-- If we want to access the second one, we can use `flip`. But what about
-- the fourth one? We typically use an explicit λ-abstraction shuffling
-- variables. Not anymore.

-- Reusing mod-helper just because it takes a lot of arguments:

  hole₁ :  k m n j  mod-helper k m n (j + 1) ≡ mod-helper k m n (suc j)
  hole₁ = λ k m n j  cong {!holeₙ 4 (# 3) mod-helper!} {!!} -- argh!!

Edit: never mind, got it (different definitions).

gallais added 2 commits Feb 14, 2019
There is no need to bother with Update because (for concrete
natural numbers), touching the k-th argument can be done by
only considering the function's type up to the (k-1)-th argument.
gallais and others added 2 commits May 14, 2019
@gallais

This comment has been minimized.

Copy link
Member Author

gallais commented May 16, 2019

It starts to feel like the module should be split up.
The content could be dispatched in:

  • Function.Nary
  • Relation.Nary (just like we have a lot of combinators in Relation.Unary)
  • Data.Product.Nary
  • Data.Sum.Nary (TODO)
@JacquesCarette

This comment has been minimized.

Copy link
Contributor

JacquesCarette commented May 16, 2019

This is really wonderful stuff; I agree that the code is getting large, and that splitting things up as you suggest seems like a good idea.

@gallais

This comment has been minimized.

Copy link
Member Author

gallais commented May 20, 2019

Ok, now that I have shipped my draft about this work (https://gallais.github.io/pdf/tyde19_draft.pdf),
I'll do the split.

@gallais

This comment has been minimized.

Copy link
Member Author

gallais commented May 20, 2019

I'm annoyed by the module names:

  • I like Function.Nary.NonDependent and Relation.Nary
  • Data.Product.N-ary.Heterogeneous looks meh
@JacquesCarette

This comment has been minimized.

Copy link
Contributor

JacquesCarette commented May 20, 2019

Why not just Data.Product.N-ary (or Nary)? There is no reason for the Heterogeneous as the homogeneous version is Data.Vec (at Set 'type').

@gallais

This comment has been minimized.

Copy link
Member Author

gallais commented May 20, 2019

Data.Product.N-ary already exists unfortunately :/

https://agda.github.io/agda-stdlib/Data.Product.N-ary.html

I was tempted to go for Data.Product.Nary.NonDependent to mirror the Function
one but is it not too confusing Nary vs. N-ary?

@JacquesCarette

This comment has been minimized.

Copy link
Contributor

JacquesCarette commented May 20, 2019

I would rename that one Data.Product.N-ary.Fixed (or even FixedN) !

About Nary vs N-ary: I don't really care which is used, consistency is however important. I think it is bad to use both.

@gallais

This comment has been minimized.

Copy link
Member Author

gallais commented May 24, 2019

If we do not mind a breaking change, we could move the existing
Data.Product.N-ary to e.g. Data.Vec.Recursive and DEPRECATE
the old ones while using Data.Product.Nary.NonDependent for
this work. This would have the added benefit of getting rid of a
bunch of hyphenated modules #265.

@MatthewDaggitt

This comment has been minimized.

Copy link
Contributor

MatthewDaggitt commented May 24, 2019

Don't have a strong opinion. Happy with whatever you decide!

@gallais

This comment has been minimized.

Copy link
Member Author

gallais commented May 27, 2019

I thought I had already committed the changes when I decided to amend them. But I
had not so the move + deprecation + renaming is mixed with the merge. Oh well, not
a big deal as we are going to squash everything together anyways.

@MatthewDaggitt MatthewDaggitt merged commit 56755f0 into master May 31, 2019
1 check passed
1 check passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@MatthewDaggitt MatthewDaggitt deleted the eqN branch May 31, 2019
@JacquesCarette

This comment has been minimized.

Copy link
Contributor

JacquesCarette commented Jun 1, 2019

By the way, nice TyDe draft. I very much enjoyed reading it.

@gallais

This comment has been minimized.

Copy link
Member Author

gallais commented Jun 1, 2019

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.