X-Git-Url: https://git.stderr.nl/gitweb?p=matthijs%2Fmaster-project%2Freport.git;a=blobdiff_plain;f=Chapters%2FFuture.tex;h=6be0ba8be0d465adc19063ffa2030c9779d016cd;hp=38904bea13edb937ff83be17dac29f56b928ae77;hb=a472d8d94908d8f466a4cafe4d55c4c9410161d8;hpb=ffa1ca538962fbb10e49c6d4d6614883af793154

diff --git a/Chapters/Future.tex b/Chapters/Future.tex
index 38904be..6be0ba8 100644
--- a/Chapters/Future.tex
+++ b/Chapters/Future.tex
@@ -23,7 +23,7 @@ Using custom combinators would work
 
 \section{Recursion}
 The main problems of recursion have been described in
-\at{section}[sec:recursion]. In the current implementation, recursion is
+\in{section}[sec:recursion]. In the current implementation, recursion is
 therefore not possible, instead we rely on a number of implicit list-recursive
 builtin functions.
 
@@ -213,7 +213,7 @@ take multiple cycles. Some examples include:
   \item A large combinatoric expressions that would introduce a very long
   combinatoric path and thus limit clock frequency. Such an expression could
   be broken up into multiple stages, which effectively results in a pipelined
-  system (see also \at{section}[sec:future:pipelining]) with a known delay.
+  system (see also \in{section}[sec:future:pipelining]) with a known delay.
   There should probably be some way for the developer to specify the cycle
   division of the expression, since automatically deciding on such a division
   is too complex and contains too many tradeoffs, at least initially.