Hello Guys,
I saw that GHC already has complete support for Unicode character
classification. I tend to use it but I saw that currently GHC.Unicode
exports only few of all classification routines. Is it intentional?
Cheers,
Krasimir
___
On Tue, Jan 17, 2006 at 10:33:51AM +0200, Krasimir Angelov wrote:
I saw that GHC already has complete support for Unicode character
classification. I tend to use it but I saw that currently GHC.Unicode
exports only few of all classification routines. Is it intentional?
It exports some
The problem is that I have to use 'generalCategory' function which
isn't exported. It returns the general category which tells me a lot
more about the character.
2006/1/17, Ross Paterson [EMAIL PROTECTED]:
On Tue, Jan 17, 2006 at 10:33:51AM +0200, Krasimir Angelov wrote:
I saw that GHC already
On Tue, Jan 17, 2006 at 11:29:42AM +0200, Krasimir Angelov wrote:
The problem is that I have to use 'generalCategory' function which
isn't exported. It returns the general category which tells me a lot
more about the character.
But Data.Char does export generalCategory.
Oh, Sorry! I didn't see it at first sight and I immediately went to
GHC.Unicode. In this case is the GHC.Unicode module still in use?
2006/1/17, Ross Paterson [EMAIL PROTECTED]:
On Tue, Jan 17, 2006 at 11:29:42AM +0200, Krasimir Angelov wrote:
The problem is that I have to use
On Tue, Jan 17, 2006 at 11:44:00AM +0200, Krasimir Angelov wrote:
Oh, Sorry! I didn't see it at first sight and I immediately went to
GHC.Unicode. In this case is the GHC.Unicode module still in use?
It's an internal module, like most GHC.* modules (except GHC.Exts).
|Eta-expand some higher-rank functions. GHC is about to
|move to *invariant* rather than *contra-variant* in function
|arguments, so far as type subsumption is concerned. These
|eta-expansions are simple, and allow type inference to
|go through with invariance.
|
| Why drop
Dear GHC users
As part of a revision of GHC to make type inference for GADTs simpler
and more uniform, I propose to change the way in which lexically-
scoped type variables work in GHC. (Indeed, I have done so, and will
commit it shortly.) This message explains the new system, highlighting
the
On the syntax of type signatures: I'd like to be able to write e. g.
do
x :: Int - randomRIO ( 0, 10 )
print x
Currently I have to put ( x :: Int ) in parentheses. Is this necessary?
--
-- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 --
http://www.imn.htwk-leipzig.de/~waldmann/
John Goerzen wrote:
* I will re-convert all of the top-level directories in the current
libraries darcs repo, except for: doc, mk, and Cabal
* Each new repo will be under darcs.haskell.org/packages
Inspired by the new browsable interface to the libraries repo at
Hi -
I'm wondering if anyone has a simple Visual Studio .NET C++ project that
would demonstrate how to link C++ with Haskell (or vice versa). Ie a .sln,
.vcproj, .cpp, and .h file containing one C++ function and a Haskell file
main.hs that calls this function, so that if I click on the .sln
On 2006-01-17, Malcolm Wallace [EMAIL PROTECTED] wrote:
Meanwhile, I noted that the HaXml repo on darcs.haskell.org seems
to be a verbatim copy of the darcs repo at York. This this right?
I was slightly disappointed, since I think I made a bit of a mess of
the CVS - darcs conversion of HaXml,
12 matches
Mail list logo
