[commit: containers] master: Change ASCII character for underline from ^ to ~. (0e61527)

Paolo Capriotti <[email protected]>
Newsgroups gmane.comp.lang.haskell.cvs.libraries
Message-ID <[email protected]>
Repository : ssh://darcs.haskell.org//srv/darcs/packages/containers

On branch  : master

http://hackage.haskell.org/trac/ghc/changeset/0e6152727e6ef60b7ac12951a4c88c27952f210e

>---------------------------------------------------------------

commit 0e6152727e6ef60b7ac12951a4c88c27952f210e
Author: Milan Straka <[email protected]>
Date:   Mon Apr 23 16:44:01 2012 +0200

    Change ASCII character for underline from ^ to ~.
    
    We use the following:
      -- [Note: Some superimportant message]
      -- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Unfortunately, -- ^ is wrongly picked up by Haddock.
    Instead we now use
      -- [Note: Some superimportant message]
      -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>---------------------------------------------------------------

 Data/IntMap/Base.hs |    6 +++---
 Data/IntSet.hs      |    6 +++---
 Data/Map/Base.hs    |   10 +++++-----
 Data/Set.hs         |   10 +++++-----
 4 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/Data/IntMap/Base.hs b/Data/IntMap/Base.hs
index d93d581..c10a5b3 100644
--- a/Data/IntMap/Base.hs
+++ b/Data/IntMap/Base.hs
@@ -20,7 +20,7 @@
 -----------------------------------------------------------------------------
 
 -- [Note: INLINE bit fiddling]
--- ^^^^^^^^^^^^^^^^^^^^^^^^^^^
+-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 -- It is essential that the bit fiddling functions like mask, zero, branchMask
 -- etc are inlined. If they do not, the memory allocation skyrockets. The GHC
 -- usually gets it right, but it is disastrous if it does not. Therefore we
@@ -28,7 +28,7 @@
 
 
 -- [Note: Local 'go' functions and capturing]
--- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 -- Care must be taken when using 'go' function which captures an argument.
 -- Sometimes (for example when the argument is passed to a data constructor,
 -- as in insert), GHC heap-allocates more than necessary. Therefore C-- code
@@ -37,7 +37,7 @@
 
 
 -- [Note: Order of constructors]
--- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 -- The order of constructors of IntMap matters when considering performance.
 -- Currently in GHC 7.0, when type has 3 constructors, they are matched from
 -- the first to the last -- the best performance is achieved when the
diff --git a/Data/IntSet.hs b/Data/IntSet.hs
index 514e94d..1316a39 100644
--- a/Data/IntSet.hs
+++ b/Data/IntSet.hs
@@ -50,7 +50,7 @@
 -----------------------------------------------------------------------------
 
 -- [Note: INLINE bit fiddling]
--- ^^^^^^^^^^^^^^^^^^^^^^^^^^^
+-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 -- It is essential that the bit fiddling functions like mask, zero, branchMask
 -- etc are inlined. If they do not, the memory allocation skyrockets. The GHC
 -- usually gets it right, but it is disastrous if it does not. Therefore we
@@ -58,7 +58,7 @@
 
 
 -- [Note: Local 'go' functions and capturing]
--- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 -- Care must be taken when using 'go' function which captures an argument.
 -- Sometimes (for example when the argument is passed to a data constructor,
 -- as in insert), GHC heap-allocates more than necessary. Therefore C-- code
@@ -67,7 +67,7 @@
 
 
 -- [Note: Order of constructors]
--- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 -- The order of constructors of IntSet matters when considering performance.
 -- Currently in GHC 7.0, when type has 3 constructors, they are matched from
 -- the first to the last -- the best performance is achieved when the
diff --git a/Data/Map/Base.hs b/Data/Map/Base.hs
index 23ef38f..90f48aa 100644
--- a/Data/Map/Base.hs
+++ b/Data/Map/Base.hs
@@ -43,7 +43,7 @@
 -----------------------------------------------------------------------------
 
 -- [Note: Using INLINABLE]
--- ^^^^^^^^^^^^^^^^^^^^^^^
+-- ~~~~~~~~~~~~~~~~~~~~~~~
 -- It is crucial to the performance that the functions specialize on the Ord
 -- type when possible. GHC 7.0 and higher does this by itself when it sees th
 -- unfolding of a function -- that is why all public functions are marked
@@ -51,7 +51,7 @@
 
 
 -- [Note: Using INLINE]
--- ^^^^^^^^^^^^^^^^^^^^
+-- ~~~~~~~~~~~~~~~~~~~~
 -- For other compilers and GHC pre 7.0, we mark some of the functions INLINE.
 -- We mark the functions that just navigate down the tree (lookup, insert,
 -- delete and similar). That navigation code gets inlined and thus specialized
@@ -64,14 +64,14 @@
 
 
 -- [Note: Type of local 'go' function]
--- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 -- If the local 'go' function uses an Ord class, it must be given a type
 -- which mentions this Ord class. Otherwise it is not passed as an argument and
 -- it is instead heap-allocated at the entry of the outer method.
 
 
 -- [Note: Local 'go' functions and capturing]
--- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 -- Care must be taken when using 'go' function which captures an argument.
 -- Sometimes (for example when the argument is passed to a data constructor,
 -- as in insert), GHC heap-allocates more than necessary. Therefore C-- code
@@ -80,7 +80,7 @@
 
 
 -- [Note: Order of constructors]
--- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 -- The order of constructors of Map matters when considering performance.
 -- Currently in GHC 7.0, when type has 2 constructors, a forward conditional
 -- jump is made when successfully matching second constructor. Successful match
diff --git a/Data/Set.hs b/Data/Set.hs
index ffc73ce..993aeef 100644
--- a/Data/Set.hs
+++ b/Data/Set.hs
@@ -41,7 +41,7 @@
 -----------------------------------------------------------------------------
 
 -- [Note: Using INLINABLE]
--- ^^^^^^^^^^^^^^^^^^^^^^^
+-- ~~~~~~~~~~~~~~~~~~~~~~~
 -- It is crucial to the performance that the functions specialize on the Ord
 -- type when possible. GHC 7.0 and higher does this by itself when it sees th
 -- unfolding of a function -- that is why all public functions are marked
@@ -49,7 +49,7 @@
 
 
 -- [Note: Using INLINE]
--- ^^^^^^^^^^^^^^^^^^^^
+-- ~~~~~~~~~~~~~~~~~~~~
 -- For other compilers and GHC pre 7.0, we mark some of the functions INLINE.
 -- We mark the functions that just navigate down the tree (lookup, insert,
 -- delete and similar). That navigation code gets inlined and thus specialized
@@ -62,14 +62,14 @@
 
 
 -- [Note: Type of local 'go' function]
--- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 -- If the local 'go' function uses an Ord class, it must be given a type
 -- which mentions this Ord class. Otherwise it is not passed as an argument and
 -- it is instead heap-allocated at the entry of the outer method.
 
 
 -- [Note: Local 'go' functions and capturing]
--- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 -- Care must be taken when using 'go' function which captures an argument.
 -- Sometimes (for example when the argument is passed to a data constructor,
 -- as in insert), GHC heap-allocates more than necessary. Therefore C-- code
@@ -78,7 +78,7 @@
 
 
 -- [Note: Order of constructors]
--- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 -- The order of constructors of Set matters when considering performance.
 -- Currently in GHC 7.0, when type has 2 constructors, a forward conditional
 -- jump is made when successfully matching second constructor. Successful match
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.