fix

docs/Imports.md

@@ -11,11 +11,9 @@ Therefore, if users wish to utilize Exo constructs, they must import them into t
 2. [Core Exo Module](#2-core-exo-module)
 3. [Memory Libraries](#3-memory-libraries)
 4. [Instruction Libraries](#4-instruction-libraries)
-5. [Frontend Syntax Utilities](#5-frontend-syntax-utilities)
-6. [Standard Library Modules](#6-standard-library-modules)
-   - [6.1 Scheduling Utilities](#61-scheduling-utilities)
-   - [6.2 Standard Library Functions](#62-standard-library-functions)
-7. [External Interfaces](#7-external-interfaces)
+5. [Extern Libraries](#5-extern-libraries)
+6. [Frontend Syntax Utilities](#6-frontend-syntax-utilities)
+7. [Standard Library Scheduling Functions](#7-standard-library-scheduling-functions)
 8. [API Cursors](#8-api-cursors)
 
 
@@ -89,7 +87,7 @@ Alternatively, users can define their own scheduling operations by composing sch
 
 ## 8. API Cursors
 
-Cursors (see [Cursors.md](./Cursors.md)) are Exo's reference mechanism that allows users to navigate and inspect object code. When users define new scheduling operators using Cursors, they may wish to write their own inspection pass (see [inspection.md](./inspection.md). API Cursors define types that will be useful for user inspection.
+Cursors (see [Cursors.md](./Cursors.md)) are Exo's reference mechanism that allows users to navigate and inspect object code. When users define new scheduling operators using Cursors, they may wish to write their own inspection pass (see [inspection.md](./inspection.md)). API Cursors define types that will be useful for user inspection.
 
 ```python
 from exo.API_cursors import ForCursor, AssignCursor, InvalidCursor

docs/object_code.md

@@ -31,15 +31,14 @@ def generic_conv1d(
 - [Annotations and Decorators](#annotations-and-decorators)
   - [`@proc` Decorator](#proc-decorator)
   - [Type and Memory Annotations](#type-and-memory-annotations)
-- [Procedure Arguments](#procedure-arguments)
-- [Variable Declarations](#variable-declarations)
-- [Memory Spaces](#memory-spaces)
+  - [Procedure Arguments](#procedure-arguments)
+  - [Allocations](#allocations)
+  - [Memories](#memories)
 - [Loops](#loops)
   - [`for` Loop Syntax](#for-loop-syntax)
 - [Conditional Statements](#conditional-statements)
-- [Operations and Assignments](#operations-and-assignments)
+- [Assignments](#assignments)
 - [Understanding the Example](#understanding-the-example)
-- [Conclusion](#conclusion)
 
 ## Annotations and Decorators
 
@@ -67,7 +66,7 @@ name: type[size] @ memory
 - **`@ memory`**: The memory space where the variable resides.
 
 
-#### Procedure Arguments
+### Procedure Arguments
 
 Procedure arguments are declared with their types, sizes, and memory spaces. They can have sizes that depend on other arguments.
 
@@ -145,7 +144,30 @@ foo(y[0:5], y[2:7])
 
 This limitation exists because the analysis would be imprecise if we allowed such aliasing. This is similar to how C++ compilers can perform more optimization when you use the `__restrict__` keyword to explicitly indicate that you're not aliasing your buffers.
 
-#### Allocations
+
+#### Passing Tensor Window Slices to Functions Expecting Non-Window Tensors
+
+It is not allowed to pass _window_ to a function that expects a non-window tensor as an argument. Consider the following example:
+
+```python
+@proc
+def callee(x: f32[10]):
+    pass
+
+@proc
+def caller(x: f32[2, 10]):
+    callee(x[0])     # Error: Passing a window slice to a function expecting a non-window tensor
+    callee(x[1, :])  # Error: Passing a window slice to a function expecting a non-window tensor
+```
+
+In this code snippet, the `callee` function expects a non-window tensor `x` of shape `f32[10]`. However, in the `caller` function, we attempt to pass slices of the `x` tensor (`x[0]` and `x[1]`) to the `callee` function. These slices are windows of the original tensor, and passing them to a function expecting a non-window tensor is not allowed.
+
+To resolve this issue, you can either:
+1. Modify the `callee` function to accept a window tensor as an argument, or
+2. Create a new non-window tensor from the slice before passing it to the `callee` function.
+
+
+### Allocations
 
 Variables within the procedure are declared similarly to arguments.
 
@@ -159,12 +181,14 @@ y: i32
 - **`i32`**: The data type (32-bit integer).
 - **No memory annotation**: Defaults to `DRAM` if memory is unspecified.
 
-#### Memories
+### Memories
 
 Memory annotations in Exo are used to model different hardware memory regions, such as DRAM, caches, or specialized memories. The `@` symbol is used to specify the memory space, for example: `@DRAM`, `@AVX2`, or `@Neon`.
 Memory annotations for your custom hardware accelerators can be defined externally to Exo and can be used as annotations in the same way.
 While Exo provides default memory (`DRAM`) and some library memory definitions for convenience (`AVX2`, `AVX512`, `Neon`, `GEMM_SCRATCH`, etc.), it is recommended and encouraged that users define their own memory annotations for their specific hardware. For more information on defining custom memory annotations, refer to [memories.md](./memories.md).
 
+
+
 ## Loops
 
 ### `for` Loop Syntax