Fix documentation

docs/src/api.md

@@ -1,10 +1,12 @@
 # API Reference
+```@meta
+CurrentModule = SymbolicUtils
+```
 
 ## Symbols and Terms
 ```@docs
 SymbolicUtils.@syms
 SymbolicUtils.Sym
-SymbolicUtils.issym
 SymbolicUtils.symtype
 SymbolicUtils.Term
 SymbolicUtils.Add
@@ -17,19 +19,19 @@ SymbolicUtils.promote_symtype
 
 ```@docs
 @rule
-SymbolicUtils.Rewriters
+Rewriters
 ```
 
 ## Simplify
 
 ```@docs
-SymbolicUtils.simplify
-SymbolicUtils.expand
-SymbolicUtils.substitute
+simplify
+expand
+substitute
 ```
 
 ## Utilities
 
 ```@docs
-SymbolicUtils.@timerewrite
-```
+@timerewrite
+```

docs/src/index.md

@@ -3,13 +3,13 @@
 ## Features
 
 - Fast expressions
-- A [rule-based rewriting language](/rewrite/#rule-based_rewriting).
-- A [combinator library](/rewrite/#composing_rewriters) for making rewriters.
-- [Efficient representation](/representation/) of numeric expressions
+- A [rule-based rewriting language](@ref "Rule-based rewriting").
+- A [combinator library](@ref "Composing rewriters") for making rewriters.
+- [Efficient representation](@ref "Term representation and simplification") of numeric expressions
 - Type promotion:
-  - Symbols (`Sym`s) carry type information. ([read more](#creating_symbolic_expressions))
-  - Compound expressions composed of `Sym`s propagate type information. ([read more](#expression_interface))
-- Set of extendable [simplification rules](#Simplification).
+  - Symbols (`Sym`s) carry type information. ([read more](@ref "Creating symbolic expressions"))
+  - Compound expressions composed of `Sym`s propagate type information. ([read more](@ref "Expression interface"))
+- Set of extendable [simplification rules](@ref "Simplification").
 
 
 ## Creating symbolic expressions
@@ -106,14 +106,14 @@ g(2//5, g(1, β))
 
 ## Expression interface
 
-Symbolic expressions are of type `Term{T}`, `Add{T}`, `Mul{T}`, `Pow{T}` or `Div{T}` and denote some function call where one or more arguments are themselves such expressions or `Sym`s. See more about the representation [here](/representation/).
+Symbolic expressions are of type `Term{T}`, `Add{T}`, `Mul{T}`, `Pow{T}` or `Div{T}` and denote some function call where one or more arguments are themselves such expressions or `Sym`s. See more about the representation [here](@ref "Term representation and simplification").
 
 All the expression types support the [TermInterface.jl](https://github.com/0x0f0f0f/TermInterface.jl) interface.
 Please refer to the package for the complete reference of the interface.
 
 ## Term rewriting
 
-SymbolicUtils contains [a rule-based rewriting language](/rewrite/#rule-based_rewriting) for easy pattern matching and rewriting of expression. There is also a [combinator library](/rewrite/#composing_rewriters) to combine rules to chain, branch and loop over rules.
+SymbolicUtils contains [a rule-based rewriting language](@ref "Rule-based rewriting") for easy pattern matching and rewriting of expression. There is also a [combinator library](@ref "Composing rewriters") to combine rules to chain, branch and loop over rules.
 
 ## Simplification
 
@@ -158,11 +158,11 @@ If you read the previous section on the rules DSL, you should be able to read an
 
 It is common to want to generate executable code from symbolic expressions and blocks of them. We are working on experimental support for turning Symbolic expressions into executable functions with specific focus on array input and output and performance which is critical to the Differential Equations ecosystem which is making heavy use of this package.
 
-See [Code generation](/codegen/) for more about this.
+See [Code generation](@ref codegen) for more about this.
 
 ## Learn more
 
-If you have a package that you would like to utilize rule-based rewriting in, look at the suggestions in the [Interfacing](/interface/) section to find out how you can do that without any fundamental changes to your package. Look at the [API documentation](/api/) for docstrings about specific functions or macros.
+If you have a package that you would like to utilize rule-based rewriting in, look at the suggestions in the [Interfacing](@ref "Interfacing with SymbolicUtils.jl") section to find out how you can do that without any fundamental changes to your package. Look at the [API Reference](@ref) for docstrings about specific functions or macros.
 
 Head over to the github repository to ask questions and [report problems](https://github.com/JuliaSymbolics/SymbolicUtils.jl)! Join the [Zulip stream](https://julialang.zulipchat.com/#narrow/stream/236639-symbolic-programming) to chat!
 

docs/src/manual/codegen.md

@@ -1,4 +1,4 @@
-# Code generation
+# [Code generation](@id codegen)
 
 **Note: this feature is experimental and the API might change frequently**
 
@@ -35,4 +35,4 @@ SymbolicUtils.Code.MakeArray
 SymbolicUtils.Code.MakeSparseArray
 SymbolicUtils.Code.MakeTuple
 SymbolicUtils.Code.LiteralExpr
-```
+```

docs/src/manual/representation.md

@@ -4,7 +4,7 @@ Performance of symbolic simplification depends on the datastructures used to rep
 
 The most basic term representation simply holds a function call and stores the function and the arguments it is called with. This is done by the `Term` type in SymbolicUtils. Functions that aren't commutative or associative, such as `sin` or `hypot` are stored as `Term`s. Commutative and associative operations like `+`, `*`, and their supporting operations like `-`, `/` and `^`, when used on terms of type `<:Number`, stand to gain from the use of more efficient datastrucutres.
 
-All term representations must support `operation` and `arguments` functions. And they must define `iscall` and `isexpr` to return `true` when called with an instance of the type. Generic term-manipulation programs such as the rule-based rewriter make use of this interface to inspect expressions. In this way, the interface wins back the generality lost by having a zoo of term representations instead of one. (see [interface](/interface/) section for more on this.)
+All term representations must support `operation` and `arguments` functions. And they must define `iscall` and `isexpr` to return `true` when called with an instance of the type. Generic term-manipulation programs such as the rule-based rewriter make use of this interface to inspect expressions. In this way, the interface wins back the generality lost by having a zoo of term representations instead of one. (see [interface](@ref "Interfacing with SymbolicUtils.jl") section for more on this.)
 
 
 ### Preliminary representation of arithmetic

src/rewriters.jl

@@ -24,7 +24,7 @@ rewriters.
    threaded spawn.
 - `Postwalk(rw; threaded=false, thread_cutoff=100)` similarly does post-order traversal.
 - `Fixpoint(rw)` returns a rewriter which applies `rw` repeatedly until there are no changes to be made.
-- `FixpointNoCycle` behaves like [`Fixpoint`](@ref) but instead it applies `rw` repeatedly only while it is returning new results.
+- `FixpointNoCycle` behaves like `Fixpoint` but instead it applies `rw` repeatedly only while it is returning new results.
 - `PassThrough(rw)` returns a rewriter which if `rw(x)` returns `nothing` will instead
    return `x` otherwise will return `rw(x)`.
 
@@ -113,7 +113,6 @@ end
     end
 end
 
-
 struct Fixpoint{C}
     rw::C
 end

src/simplify.jl

@@ -8,7 +8,7 @@ simplify(x; expand=false,
 ```
 
 Simplify an expression (`x`) by applying `rewriter` until there are no changes.
-`expand=true` applies [`expand`](/api/#expand) in the beginning of each fixpoint iteration.
+`expand=true` applies [`expand`](@ref) in the beginning of each fixpoint iteration.
 
 By default, simplify will assume denominators are not zero and allow cancellation in fractions.
 Pass `simplify_fractions=false` to prevent this.

src/types.jl

@@ -106,7 +106,7 @@ end
 ###
 
 """
-$(SIGNATURES)
+symtype(x)
 
 Returns the [numeric type](https://docs.julialang.org/en/v1/base/numbers/#Standard-Numeric-Types) 
 of `x`. By default this is just `typeof(x)`.