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

Error: «Introduced symbol cannot be removed.» Feature proposal job: primitive structure/record types to pack multiple arguments #1006

Closed
1337777 opened this issue Aug 1, 2023 · 1 comment · Fixed by #1007

Comments

@1337777
Copy link

1337777 commented Aug 1, 2023

  1. Test problem:
constant symbol Set : TYPE;
injective symbol τ : Set → TYPE; builtin "T" ≔ τ;

symbol mys : TYPE;
symbol myop :  mys →  mys →   mys;

symbol testfun : Π (Func : Set) (Hom : τ Func → Set) (Comp : Π [F : τ Func]  , τ (Hom F)) ,
 mys;

// RULE ERROR: "Introduced symbol [$179144] cannot be removed."
rule (myop (@testfun $Func $Hom $Comp ) (@testfun $Func $Hom $Comp    ) )
    ↪  (@testfun $Func $Hom $Comp ) ;
  1. Could anyone clarify what this error means? Temporary solution: this is solved by packing all the arguments of testfun into one value of a new inductive record/structure type.

  2. Any future plans for an implementation of automatic/better support of structure/records with (primitive) projections in Lambdapi ?

  3. Could the Lambdapi unif_rule command be used to simulate type classes or canonical structures, for (very) large library developments?

  4. Here is the context: I have a Lambdapi implementation of Dosen's categorial logic/programming/proof-assistant with "abstract" automatic decidability of equality/convertibility, where "abstract" means that it is in reality a proof-assistant for proving categorial lemmas.

https://github.com/1337777/cartier/blob/master/cartierSolution13.lp

Now the next step is to link the "abstract" implementation to a "concrete" implementation of categorial datatype structures for concrete computations, everything still within Lambdapi.

  1. And Lambdapi is currently the only framework, because of logical-dependent types and computational-rewrite rules, capable of merging both the "abstract" implementation for computationally-proving with the "concrete" implementation for computing, with categories... For example,

https://explore.jobs.ufl.edu/en-us/job/527710/systems-adminprogrammer-iv

in this AlgebraicJulia, for a "type-safe concrete" implementation, they have to hack a pseudo-dependent-type domain-specific-language embedded within Julia...

  1. Proposal: Lambdapi could employ somebody (or me) this 1 month of August to engineer tooling support for typeclasses or canonical-structures in Lambdapi.. and thereafter to produce a "concrete" (applied) implementation of categories which is linked to the existing "abstract" (prover) implementation. And I repeat that Lambdapi is currently in a unique strategic position to unify both worlds with a limitless payoff, n.b. that some entities linked above are already investing $100,000 - $130,000 (in a limited approach) ...

Voilà, à vous!
Christopher

@fblanqui
Copy link
Member

fblanqui commented Aug 1, 2023

Hi @1337777 . Thanks for your report.
2. This is a bug in unification. I will commit a patch soon.
3. No such plan at the moment. Which kind of support would you like?
4. In theory, yes, but this has not been extensively tested yet. An alternative is to use #418 which adds type classes in Lambdapi using ELPI.

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 a pull request may close this issue.

2 participants