update pyi for fortran

README.md

@@ -430,10 +430,10 @@ File: tests/data/fortran/general/modern_pyi_example.f90
 class particle:
     id: Int32
     mass: Float64
-    position: Float64[Shape('3'), ORDER_F]
+    position: Float64[3]
 
 class vector3:
-    values: Float64[Shape('3'), ORDER_F]
+    values: Float64[3]
 
 @private
 class hidden_state:
@@ -443,46 +443,47 @@ counter: Int32
 
 hidden_scale: private[Float64]
 
-@native_call([Return(0), Arg(0), Arg(1), Arg(2), Arg(3), Arg(4)])
 def init_particle(
-    pid: Int32,
-    mass: Float64,
-    x: Float64,
-    y: Float64,
-    z: Float64
-) -> particle: ...
+    p: Annotated[Ptr(particle), Intent('out')],
+    pid: Ptr(Const(Int32)),
+    mass: Ptr(Const(Float64)),
+    x: Ptr(Const(Float64)),
+    y: Ptr(Const(Float64)),
+    z: Ptr(Const(Float64))
+) -> None: ...
 
 def kinetic_energy(
-    p: particle,
-    vx: Float64,
-    vy: Float64,
-    vz: Float64
+    p: Ptr(Const(particle)),
+    vx: Ptr(Const(Float64)),
+    vy: Ptr(Const(Float64)),
+    vz: Ptr(Const(Float64))
 ) -> Float64: ...
 
 def scale_vector(
-    v: Float64[Shape(':'), ORDER_F],
-    alpha: Float64
-) -> Returns["v", Float64[Shape(':'), ORDER_F]]: ...
+    v: Float64[::Strided],
+    alpha: Ptr(Const(Float64))
+) -> None: ...
 
 def dot3(
-    a: Float64[Shape('3'), ORDER_F],
-    b: Float64[Shape('3'), ORDER_F]
+    a: Const(Float64[3]),
+    b: Const(Float64[3])
 ) -> Float64: ...
 
-@native_call([Return(0)])
-def fill_identity3() -> Float64[Shape('3', '3'), ORDER_F]: ...
+def fill_identity3(
+    a: Annotated[Float64[3, 3], ORDER_F, Intent('out')]
+) -> None: ...
 
 def normalize_particle(
-    p: particle
-) -> Returns["p", particle]: ...
+    p: Ptr(particle)
+) -> None: ...
 
 @private
 def hidden_proc(
-    x: Int32
+    x: Ptr(Const(Int32))
 ) -> None: ...
 ```
 
-This snapshot is also verified in `tests/pyi/test_pyi_printer_modern_example.py`.
+This snapshot is also verified in `tests/semantics/test_pyi_printer_modern_example.py`.
 
 Parse output for the same fixture now includes the derived type definition and field list:
 

docs/architecture/semantic_multilanguage_wrapper_runtime_architecture.md

@@ -327,13 +327,13 @@ def solve(
         From(np.ndarray),
         ORDER_F,
         Writable,
-        Shape("N", "N"),
+        "N", "N",
     ],
     b: Float64Vector[
         From(np.ndarray),
-        Shape("N"),
+        "N",
     ],
-) -> Float64Vector[Shape("N")]: ...
+) -> Float64Vector["N"]: ...
 ```
 
 This means:
@@ -366,7 +366,7 @@ Examples:
 * `ORDER_F`
 * `ORDER_C`
 * `CPUResident`
-* `Shape(N, N)`
+* shape subscriptions such as `Float64["N", "N"]`
 * `Aligned(64)`
 * `Finite`
 * `NonNull`

docs/c_parser/c_parser_architecture.md

@@ -683,7 +683,8 @@ Planned mapping:
 - C parameter -> `SemanticArgument`
 - C primitive -> `SemanticType`
 - C pointer -> constraints and ownership metadata
-- C array -> `Shape(...)`, `ORDER_C`, and pointer/extent metadata
+- C array -> subscription shape notation such as `T[n]`, order metadata such as
+  `ORDER_C`, and pointer/extent metadata
 - `const` -> read-only ownership/constraint metadata
 - `restrict` -> aliasing metadata
 - structs/unions -> `SemanticClass` or named opaque semantic type
@@ -712,10 +713,11 @@ Likely stub patterns:
 - plain scalar functions:
   - `def f(x: Int32) -> Float64: ...`
 - pointer arguments:
-  - use semantic constraints such as `Pointer`, `Writable`, `Const`, `Shape`
-    only after the IR supports them cleanly
+  - use storage/calling contracts such as `Ptr(...)`, `Const(...)`, writable
+    metadata, and explicit extent metadata only after the IR supports them
+    cleanly
 - arrays:
-  - `Float64[Shape("n"), ORDER_C]`
+  - `Annotated[Float64[n], ORDER_C]`
 - opaque handles:
   - classes or named semantic types with ownership constraints
 - structs:
@@ -727,9 +729,9 @@ Likely stub patterns:
   - `Final[...]`
 
 The existing `.pyi` parser already supports `Final`, `private`, `native_call`,
-imports, classes, functions, shapes, and native projection entries. C-specific
-work should extend the semantic model intentionally before changing `.pyi`
-syntax.
+imports, classes, functions, shape subscriptions, storage contracts, metadata,
+and native projection entries. C-specific work should extend the semantic model
+intentionally before changing `.pyi` syntax.
 
 For function pointers and callbacks, parser extraction and later wrappability
 are separate decisions. The parser should extract the function pointer type into

docs/semantics/c_pyi_self_contained_specification.md

@@ -188,9 +188,16 @@ runnable C Phase 1 wrapper requires the corresponding native routine to
 accept that storage layout directly. For a rank-one array, `ORDER_C` and
 `ORDER_F` do not distinguish storage, contiguous or strided, so no order
 constraint is written.
-For a multidimensional strided annotation, `ORDER_F` is orientation metadata,
-not a requirement that NumPy report `F_CONTIGUOUS`; non-unit strides remain
-part of the contract.
+   For a multidimensional strided annotation, `ORDER_F` is orientation metadata,
+   not a requirement that NumPy report `F_CONTIGUOUS`; non-unit strides remain
+   part of the contract.
+   Source frontends may retain original declaration dimensions, source bounds
+   or native dummy categories as internal provenance. Those source facts are
+   not part of the canonical public array annotation unless they produce an
+   actual storage constraint. In particular, Fortran dummy bounds are
+   established by native association rather than supplied as Python array
+   metadata. This does not add C semantic conversion support; C conversion
+   remains deferred.
 
 Stride-aware dimensions use a slice step marker: