Skip to content

Conversation

e-mniang
Copy link
Contributor

This PR updates #1945 by bringing the functional vector and module structures/bundles in line with current stdlib conventions and removing nested submodules.

Next, I’ll add the necessary entry to the CHANGELOG.

Reviews and comments are welcome.

Copy link
Contributor

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

A few minor style things, but this looks quite good.

lift₁ᴹ f = map f

-- Vector RawMagma construction
VecRawMagma : RawMagma a ℓ → (n : ℕ) → RawMagma a ℓ
Copy link
Contributor

Choose a reason for hiding this comment

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

I would use (say) Data.Sum.Algebra as a guide for naming conventions of these.


-- Left scalar action obtained from the ring/semiring multiplication
_*ₗ_ : {S : Set a} → Op₂ S → Opₗ S (Vector S n)
_*ₗ_ _*_ r xs = map (λ x → _*_ r x) xs
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
_*ₗ_ _*_ r xs = map (λ x _*_ r x) xs
_*ₗ_ _*_ r xs = map (r *_) xs

Copy link
Contributor

Choose a reason for hiding this comment

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

Also, worth adding some global variable declarations to avoid having to mention {S : Set a} prefixes in types at all?


-- Right scalar action (same underlying Op₂, but as a right action)
_*ᵣ_ : {S : Set a} → Op₂ S → Opᵣ S (Vector S n)
_*ᵣ_ _*_ xs r = map (λ x → _*_ x r) xs
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
_*ᵣ_ _*_ xs r = map (λ x _*_ x r) xs
_*ᵣ_ _*_ xs r = map (_* r) xs

isSemiringVec = record {
isSemiringWithoutAnnihilatingZero = record
{ +-isCommutativeMonoid = isCommutativeMonoid n +-isCommutativeMonoid
; *-cong = λ x≈y u≈v i → *-cong (x≈y i) (u≈v i)
Copy link
Contributor

Choose a reason for hiding this comment

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

there are many combinators in Function.Base that could be used here.

@jamesmckinna
Copy link
Contributor

jamesmckinna commented Aug 29, 2025

No review as such, but an observation about a global problem with both Base and Properties, echoing @JacquesCarette 's 'style' comment: in many/most/all(?) of the definitions, there is a need to standardise apart the name of a derived construction from that of its 'base' counterpart, and this PR adopts three distinct strategies to achieve this

  • superscript ̌
  • vec-/Vec prefixing
  • base as a generic name for the 'base' notion (eg IsCommutativeMonoid), and the 'usual' isCamelCase : IsCamelCase idiom for naming the derived notion

Some of this seems to come about because of name clashes, either directly, or as a result of local opening of a base record.
It would be great if, even at the cost of some slightly more involved qualified imports/private module declarations, that such things could be avoided, moreover in such a way as to make the above '(in)elegant variation' go away...

Suggest also that, for all these update/'redux' PRs:

  • the title of the PR be a copy/tidying up of the original, but with the additional pointer to the original as you have it, eg here "[ add ] Pointwise lifting of algebra to Data.Vec.Functional (Functional vector module #1945 redux)", rather than the more gnomic "Update of...", which requires the reader to follow one level of indirection in order to know what's going on...

@e-mniang e-mniang changed the title Update of pr 1945 [ add ] Pointwise lifting of algebra to Data.Vec.Functional (Functional vector module #1945 redux) Aug 29, 2025
Comment on lines +30 to +31
pointwiseᵛ : ( _≈_ : Rel A ℓ ) → Rel (Vector A n) ℓ
pointwiseᵛ _≈_ = Pointwise _≈_
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this (redundant) repetition worth the gain (eg in uniformity of naming?)
I'd be tempted to do two things here:

  • make the import on L20 qualified, as Pointwise
  • inline all uses of pointwiseᵛ in favour simply of Pointwise as it stands...

Comment on lines +33 to +37
zipWithᵛ : Op₂ A → Op₂ (Vector A n)
zipWithᵛ _∙_ = zipWith _∙_

mapᵛ : Op₁ A → Op₁ (Vector A n)
mapᵛ f = map f
Copy link
Contributor

Choose a reason for hiding this comment

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

Ditto. (and all the more so, now that 3 imported definitions are being subject to the same treatment...)

Comment on lines +42 to +43
rawMagmaᵛ : RawMagma a ℓ → (n : ℕ) → RawMagma a ℓ
rawMagmaᵛ M n =
Copy link
Contributor

Choose a reason for hiding this comment

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

Now that M is being referenced only locally via the where clause, again... I'd drop the superscript.

Comment on lines +97 to +98
_*ₗᵛ_ : {S : Set a} → Op₂ S → Opₗ S (Vector S n)
_*ₗᵛ_ _*_ r xs = map (r *_) xs
Copy link
Contributor

Choose a reason for hiding this comment

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

Two suggestions:

  • eta-contract (no need to mention xs on either LHS or RHS)
  • now you've used map, rather than mapᵛ, its alias...

... so I'd go all the way now:

Suggested change
_*ₗᵛ_ : {S : Set a} Op₂ S Opₗ S (Vector S n)
_*ₗᵛ_ _*_ r xs = map (r *_) xs
_*ₗ_ : {S : Set a} Op₂ S Opₗ S (Vector S n)
_*ₗ_ _*_ r = map (r *_)

Comment on lines +100 to +101
_*ᵣᵛ_ : {S : Set a} → Op₂ S → Opᵣ S (Vector S n)
_*ᵣᵛ_ _*_ xs r = map (_* r) xs
Copy link
Contributor

Choose a reason for hiding this comment

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

Ditto.

module VM = RawMagma magmaᵛ
module M = RawMagma rawMagma

open IsEquivalence
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this needed?

Comment on lines +44 to +49
isMagmaᵛ : IsMagma M._≈_ M._∙_ → IsMagma VM._≈_ VM._∙_
isMagmaᵛ base = record
{ isEquivalence = flip Pointwise.isEquivalence _ B.isEquivalence
; ∙-cong = λ x≈y u≈v i → B.∙-cong (x≈y i) (u≈v i)
}
where module B = IsMagma base
Copy link
Contributor

Choose a reason for hiding this comment

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

Now you've chosen base for the 'base' argument, you won't need the superscript...?

As for module B = IsMagma base why change the names module CM = ..., module SG = ... of the subsequent locally-bound modules... when B would suffice in those instances as well?

Comment on lines +76 to +78
monoidᵛ = rawMonoidᵛ rawMonoid n
module VM = RawMonoid monoidᵛ
module RM = RawMonoid rawMonoid
Copy link
Contributor

@jamesmckinna jamesmckinna Sep 2, 2025

Choose a reason for hiding this comment

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

Again, I see no use of monoidᵛ besides the definition of module VM, so consider inlining it:

Suggested change
monoidᵛ = rawMonoidᵛ rawMonoid n
module VM = RawMonoid monoidᵛ
module RM = RawMonoid rawMonoid
module VM = RawMonoid (rawMonoid M n)
module M = RawMonoid M

etc. No need for RM here?

Comment on lines +724 to +725
module' : Module _ _ _
module' = record { isModule = isModule } No newline at end of file
Copy link
Contributor

Choose a reason for hiding this comment

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

For the underlying name of the bundle, stdlib uses in eg. Algebra.Module.Construct.TensorUnit the name ⟨module⟩, and I would follow suit here, for the sake of consistency.

@jamesmckinna
Copy link
Contributor

Thanks for the updates @e-mniang ! My recent round of nitpicks really home in on wanting to avoid the superscripts altogether:

  • for the function/relation names on Vectors, the existing infrastructure suffices?
  • for your additions of structure/bundle inheritance, with careful choice of parameter names, there's no need either!

Hope this

  • is clear
  • helps!

@JacquesCarette
Copy link
Contributor

FYI: @e-mniang says she'll finish this once she's established a proper rhythm with this term's courses, back in France.

@jamesmckinna
Copy link
Contributor

FYI: @e-mniang says she'll finish this once she's established a proper rhythm with this term's courses, back in France.

Safe journeys back!

Given the current merge hiatus thanks to GitHub, it seems fine to also have a hiatus in fretting too much about when updates get pushed...

... while commentary remains the stream that can never be shut off!

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

Successfully merging this pull request may close these issues.

3 participants