You may also want to read the discussions on and linked to from:
http://www.haskell.org/haskellwiki/Regular_expressions
You may also want to consult my regular expression library regex-tdfa which has
a Parsec parser for extended regular expressions at:
http://darcs.haskell.org/packages/regex-uns
Hi Michael,
Michael Speer schrieb:
I know it is possible with ghc to have a function that accepts its
own output as its input so long as it does not utilize that piece of
output in generating itself. [...]
It seems though, if you try this same trick with two different
functions that rely on
I doubt this is a problem with the compiler as you state;
It's not immediately obvious by looking at your code what the problem is;
the code is really dense and it's not immediately obvious what you are
trying to accomplish. I suspect that either you have a bug, or you are
pattern-matching again
The code I reference is located at :
http://michaelspeer.blogspot.com/2007/06/impossible-is-only-possible-sometimes.html
In the code I am building a parser for regular expressions. I know it
is possible with ghc to have a function that accepts its own output as
its input so long as it does not
2nd Central-European Functional Programming School
CEFP 2007
Cluj-Napoca, June 23-30, 2007
http://cs.ubbcluj.ro/cefp2007/
Call for PhD student presentation - Last call for participation
PhD students are invited to submit the abst
The range from U+E000 to U+F8FF is Private Use, and, thus, in use.
There are also usable ranges from U+F900 up to U+, and beyond.
The only big invalid range in UTF-8 encoding, is for the codepoints
in the surrogates area: U+D800 to U+DFFF. These are used by UTF-16 to
encode codepoints o
I've got a bug report concerning the UTF decoding
in HXT. I've copied the source containing the bug from the
Haskell Internationalisation Working Group.
I guess this source is also used in other
projects, e.g. darcs.
My question: Is this really a bug or is it a feature.
My knowlege so far was, t
