Skip to content

feat(Computability): introduce TapeEncodable class for Turing machine types#591

Open
Sfgangloff wants to merge 7 commits into
leanprover:mainfrom
Sfgangloff:all_type_tm
Open

feat(Computability): introduce TapeEncodable class for Turing machine types#591
Sfgangloff wants to merge 7 commits into
leanprover:mainfrom
Sfgangloff:all_type_tm

Conversation

@Sfgangloff
Copy link
Copy Markdown

Description

This PR addresses phase 1 of #590 (and resolves the first TODO in Cslib/Computability/Turing/SingleTapeTM.lean).

It introduces the TapeEncodable typeclass to establish a standardized framework for encoding arbitrary types onto a SingleTapeTM tape. Currently, computability in CSLib is restricted to functions of type List Symbol → List Symbol. This typeclass is the required foundational step to allow TimeComputable and PolyTimeComputable to operate on standard computable types (like Nat, Bool, pairs, and eventually Rat).

Changes

  • Created Cslib/Computability/Turing/Encoding.lean.
  • Defined class TapeEncodable (α : Type) (Symbol : Type).
  • Provided the trivial instance TapeEncodable (List Symbol) Symbol to ensure backwards compatibility with existing machines.
  • Added public import Cslib.Computability.Turing.Encoding to SingleTapeTM.lean.

Next Steps (Future PRs)

  • Provide basic TapeEncodable instances (Bool, Nat, α × β).
  • Refactor TimeComputable to accept arbitrary types α and β given [TapeEncodable α Symbol] and [TapeEncodable β Symbol].

Copy link
Copy Markdown

@crei crei left a comment

Choose a reason for hiding this comment

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

While I think this is something that is definitely needed, I'm wondering a bit how we would actually encode e.g. a pair.

What I'm getting at is that in order to make this work in a generic way, we need things like "commas" and "parentheses" and a promise that the inner types respect the parentheses.

Of course we could see this as specific to the machine type, and then it would not matter too much if it is not generic.

Comment thread Cslib/Computability/Machines/SingleTapeTuring/Encoding.lean Outdated
Comment thread Cslib/Computability/Machines/SingleTapeTuring/Encoding.lean Outdated
import Mathlib.Tactic.Basic

/-!
# Turing Machine Tape Encodings
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

I wonder if this should not be a bit more generic, unrelated to Turing machines. Also the class could be called "StringEncodable" (in contrast to the generic Mathlib Encodable that encodes to Nat).

Copy link
Copy Markdown
Author

@Sfgangloff Sfgangloff May 26, 2026

Choose a reason for hiding this comment

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

@crei Thanks, that makes sense. It is true that it may be usable in other contexts.

/-- Attempts to parse a list of symbols back into the type -/
decode : List Symbol → Option α
/-- Proof that decoding a freshly encoded value yields the original value -/
decode_encode_eq : ∀ (a : α), decode (encode a) = some 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.

I wonder if encode_inj : encode.Injective would be nicer here?

Copy link
Copy Markdown
Author

@Sfgangloff Sfgangloff May 26, 2026

Choose a reason for hiding this comment

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

@SamuelSchlesinger I think for the case of Turing machines we want both an encoding and decoding procedure, to interpret the results. In other cases, it is true that we may want some weaker notions of encoding (say, for indexing), but I think that should be introduced at the same time as these use cases.

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.

Yes, Injective implies the existence of such a decoding, though making it explicit is fine too.

instance : TapeEncodable (List Symbol) Symbol where
encode := id
decode := some
decode_encode_eq _ := rfl
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.

I think it would be nice if we had instances for common types, which I understand is hard to do with a generic Symbol. Feels not so useful without that.

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