feat(core): quantum memory layout for quantum data types by Adithyaphani · Pull Request #134 · hhat-lang/hhat_lang

Adithyaphani · 2026-06-10T06:05:15Z

Closes #113

Adds layout/quantum.rs to hhat_core — the quantum-side counterpart to the classical
TypeLayout / LayoutCache machinery. Classical layouts count bytes and insert
alignment padding; quantum layouts count qubits with no padding at all (wasting qubits
is not an option).

What's added:

QuantumPrimitiveLayout — qubit counts: @bool→1, @u2→2, @u3→3, @u4→4, @u8→8.
Panics early on classical types rather than silently returning zero.
QuantumStructLayout / QuantumMemberLayout — walks quantum members only, sums
their qubit counts linearly, tracks per-member qubit_offset for Q3L register naming.
QuantumEnumLayout — always 1 qubit; asserts exactly 2 variants at layout time
(first = |0⟩, second = |1⟩).
QuantumTypeLayout — unified Primitive | Struct | Enum with a single .qubits().
QuantumInstruction — minimal stub carrying ancilla_qubits: u32.
QuantumLayoutCache — HashMap<Ty, QuantumTypeLayout> so each type is computed once
across all quantum variables in a program. Struct entries pre-populate their members
recursively before building their own entry.
QuantumProgram — root layout + accumulated ancilla qubits from instructions +
classical register bits from cast attributes. .total_qubits() is what the Q3L
backend needs.

Files changed:

rust/hhat_lang/hhat_core/src/layout/quantum.rs   (new)
rust/hhat_lang/hhat_core/src/layout/mod.rs       (+1 line: pub mod quantum;)

Classical layout path is untouched. Array quantum layout is stubbed as
unimplemented!() — not specified in the issue.

Tests (20 total): all six categories from the issue — all five primitive types,
simple struct, enum, nested structs (two- and three-level), classical/quantum layout
round-trip, and a full QuantumProgram with instructions and cast.

Generative AI/LLM disclosure

Code and Logic Architecture/Design:

The code and logic architecture/design contain no generative AI/LLM
The code and logic architecture/design are partially performed by generative AI/LLM
- 30% performed by the author(s)
The code and logic architecture/design are fully performed by generative AI/LLM

Code content:

The code contains no generative AI/LLM work
The code is partially written by generative AI/LLM
- 25% performed by the author(s)
The code is fully written by generative AI/LLM

Code review:

The code review contains no generative AI/LLM
The code review is partially done by generative AI/LLM
The code review is fully done by generative AI/LLM

Code tests:

The code tests contain no generative AI/LLM
The code tests are partially written by generative AI/LLM
- 30% performed by the author(s)
The code tests are fully written by generative AI/LLM

Adithyaphani · 2026-06-10T08:02:08Z

@Doomsk looking forward to your response on this PR and happy to make further changes if needed.

Doomsk · 2026-06-10T09:07:14Z

Hi @Adithyaphani thank you for this PR. Please make sure to properly fill in the checks at the AI disclaimer before I proceed with the review, and use the arch_scaffold branch instead of the main branch as the target branch to merge this PR.
No LLM response.

Adithyaphani · 2026-06-10T09:21:26Z

@Doomsk I fixed the target branch and corrected the AI Disclosure part .Looking forward to your response and review. Happy to make further changes if needed.

Doomsk

Thank you @Adithyaphani . Please fix this PR branch. There are too many unnecessary changes coming from other branches/commits that are unrelated with the issue.

Doomsk · 2026-06-10T09:42:25Z

+///
+#[derive(Clone, Debug, PartialEq, Eq)]
+pub struct QuantumEnumLayout {
+    pub qubits: u32,
+}


Can you explain this without using LLM?

@Doomsk I added those thinking they'd be needed for equality checks in tests, but the tests only compare the .qubits field directly which is just a u32 — not the struct itself. So they were unnecessary and I've removed them in the updated version.

Doomsk · 2026-06-10T09:44:47Z

+
+impl QuantumLayoutCache {


Please use the method names adopted in the classical version when handling same purpose methods.

@Doomsk Renamed get_or_insert to layout_of and compute_and_store to insert_layout to follow the same naming as the classical LayoutCache.

Doomsk · 2026-06-10T09:45:38Z

+///
+pub struct QuantumProgram {
+    /// Qubit layout for the variable's declared type.
+    pub root_layout: QuantumTypeLayout,
+    /// Qubit count coming purely from the type (no ancilla).
+    pub data_qubits: u32,
+    /// Ancilla qubits accumulated from instructions so far.
+    pub ancilla_qubits: u32,
+    /// Width of the classical output register (one bit per cast attribute).
+    pub classical_register_bits: u32,
+}


Can you explain this struct without using LLM?

@Doomsk The struct collects everything the backend needs to allocate for one quantum variable before it can run — how many qubits its type needs, how many extra ancilla qubits the gates on it will require at runtime, and how many classical bits to reserve for measurements. I separated data and ancilla qubits so the backend can tell apart type-required from gate-required allocations.

Doomsk · 2026-06-10T09:46:56Z

+    ///
+    pub fn cast_attribute(&mut self) {
+        self.classical_register_bits += 1;
+    }


when and why is it used for? Explain without using LLM.

@Doomsk In H-hat when a quantum attribute gets measured and the result stored classically, that's a cast. Each cast produces one classical bit. cast_attribute() is called once per cast during compilation so by the end the backend knows exactly how wide to make the classical register.

Doomsk · 2026-06-10T09:49:45Z

@@ -0,0 +1,544 @@
+//!


Quantum struct types can contain classical types as their members (fields).

@Doomsk good point — the code already handles : QuantumStructLayout only counts quantum fields since classical fields do not need qubits. Classical fields in a quantum struct are still covered by the classical LayoutCache. Updated the doc comment to make this explicit.

Adithyaphani · 2026-06-10T10:46:58Z

@Doomsk thanks for your swift response. I think most of unnecessary files are added due to cargo command . I will make necessary changes.

Adithyaphani · 2026-06-10T20:24:14Z

@Doomsk made the following changes.

Branch fix:
Reset to upstream base, only our commit is there now.

PartialEq/Eq:
Removed — tests only check .qubits (u32) directly, struct comparison wasn't needed.

Method names:
Renamed get_or_insert → layout_of, compute_and_store → insert_layout to match LayoutCache.
Classical members in quantum struct:
Code already handles it — only quantum fields are counted for qubits, classical fields stay under LayoutCache. Updated the doc comment to say this clearly.

QuantumProgram:
Holds the three numbers the backend needs before allocating anything for a quantum variable — qubits from the type, ancilla qubits gates need, and classical bits for measurements.

cast_attribute:
Called once per quantum field that gets measured. Each measurement needs one classical bit. The counter tells the backend how wide the classical register should be.

Looking forward to your response and happy to make further changes if needed.

Doomsk · 2026-06-10T20:29:30Z

I am closing this PR. According to the AI policies of this repo, no fully automated PRs are allowed.

github-project-automation Bot added this to H-hat lang kanban Jun 10, 2026

github-project-automation Bot moved this to Backlog in H-hat lang kanban Jun 10, 2026

Adithyaphani mentioned this pull request Jun 10, 2026

[IMPL] Add quantum programs memory layout for quantum data #113

Open

Adithyaphani changed the base branch from main to dev/rust_impl/pre0.3beta/arch_scaffold June 10, 2026 09:16

Adithyaphani force-pushed the feat/quantum-memory-layout-113 branch from 9ea1fcb to fdc7b99 Compare June 10, 2026 09:26

Doomsk requested changes Jun 10, 2026

View reviewed changes

feat(core): quantum memory layout for quantum data types

40bf97b

Adithyaphani force-pushed the feat/quantum-memory-layout-113 branch from fdc7b99 to 40bf97b Compare June 10, 2026 20:16

Doomsk closed this Jun 10, 2026

github-project-automation Bot moved this from Backlog to Done in H-hat lang kanban Jun 10, 2026

Adithyaphani deleted the feat/quantum-memory-layout-113 branch June 10, 2026 20:40


		impl QuantumLayoutCache {

Uh oh!

Conversation

Adithyaphani commented Jun 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Generative AI/LLM disclosure

Uh oh!

Adithyaphani commented Jun 10, 2026

Uh oh!

Doomsk commented Jun 10, 2026

Uh oh!

Adithyaphani commented Jun 10, 2026

Uh oh!

Doomsk left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Adithyaphani commented Jun 10, 2026

Uh oh!

Adithyaphani commented Jun 10, 2026

Uh oh!

Doomsk commented Jun 10, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Adithyaphani commented Jun 10, 2026 •

edited

Loading