David Roundy <[EMAIL PROTECTED]> writes:
> I'd say that rather than returning an Integer, we'd be better off just
> using a 64 bit Int on 64 platforms.
| 7.19.2. GHC's interpretation of undefined behaviour in Haskell 98
|
| This section documents GHC's take on various issues that are left
| undef
Sun and Dell both sell 64-bit boxes. But the core
question is why have two different types at all?
This issue is timely because I just got an error
in code that looks vaguely like:
h<-openFile "foo" AppendMode
pos <- hFileSize h
hPutStr $ show something
hClose h
content <- readFil
> I'm after advice on whether the following example is a safe use of
> unsafeCoerce, and if it is safe, if it's worth it.
It looks like it is safe but it feels like using a sledgehammer to crack a
nut ... in the presence of small children/ curious animals/ two left thumbs/
etc. so you have to t
On 24 April 2004 17:38, Duncan Coutts wrote:
> All,
>
> I'm after advice on whether the following example is a safe use of
> unsafeCoerce, and if it is safe, if it's worth it.
>
> In summary, if the following is ok:
>
> castFooToBar :: Ptr Foo -> Ptr Bar
> castFooToBar = castPtr
>
> then is th
On 26 April 2004 02:49, S. Alexander Jacobson wrote:
> Sun and Dell both sell 64-bit boxes. But the core
> question is why have two different types at all?
>
> This issue is timely because I just got an error
> in code that looks vaguely like:
>
>h<-openFile "foo" AppendMode
>pos <- hFi
On Mon, 26 Apr 2004, Simon Marlow wrote:
> Probably if the take function were being designed today, there would be
> no question about whether it should take Int or Integer. Back then, the
> Integer overhead was high enough to worry about, and lots of benchmark
> programs used take/drop. Nowadays
On Mon, 2004-04-26 at 15:42, Alastair Reid wrote:
> > I'm after advice on whether the following example is a safe use of
> > unsafeCoerce, and if it is safe, if it's worth it.
>
> It looks like it is safe but it feels like using a sledgehammer to crack a
> nut ... in the presence of small childre
Thanks to the hard work of Jeff Lewis, the
CVS pserver at cvs.haskell.org is now back up again,
--sigbjorn
- Original Message -
From: "Sigbjorn Finne" <[EMAIL PROTECTED]>
To: "MR K P SCHUPKE" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, April 22, 2004 08:42
Subject: Re: G
I am writing some utilities to deal with UTF-8 encoded text files (not
source). Currently, I'm just reading in the UTF-8 directly, and things
work reasonably well, since my parse tokens are ASCII, they are easy to
parse.
However, the character type seems perfectly happy with larger values for
eac
On Mon, 2004-04-26 at 18:49, David Brown wrote:
> Is anyone aware of any Haskell libraries for doing UTF-8 decoding and
> encoding? If not, I'll write something simple.
The gtk2hs library uses the following functions internally.
Credit to Axel Simon I believe unless he swiped them from somewhere
Duncan Coutts wrote:
On Mon, 2004-04-26 at 18:49, David Brown wrote: [...]
toUTF :: String -> String
Hmmm, "String -> [Word8]" would be nicer...
fromUTF :: String -> String
... and here: "[Word8] -> String" or "[Word8] -> Maybe String".
Furthermore, UTF-8 is not restricted to a maximum of 3 bytes
Hi folks,
I'm having a little problem when building the GHC as a package.
I've set the option 'BuildPackageGHC=YES' in the build.mk file and
done the usual steps to build the GHC under windows
(including the './configure --host=i386-unknown-mingw32
--with-gcc=c:/mingw/bin/gcc').
But I'm getting th
On Mon, Apr 26, 2004 at 08:33:38PM +0200, Sven Panne wrote:
> Duncan Coutts wrote:
> >On Mon, 2004-04-26 at 18:49, David Brown wrote: [...]
> >toUTF :: String -> String
>
> Hmmm, "String -> [Word8]" would be nicer...
>
> >fromUTF :: String -> String
>
> ... and here: "[Word8] -> String" or "[Wor
simonmar:
>
>
> The (Interactive) Glasgow Haskell Compiler -- version 6.2.1
>
>
> We are pleased to announce a new patchlevel release of the Glasgow
> Haskell Compil
G'day all.
Quoting "S. Alexander Jacobson" <[EMAIL PROTECTED]>:
> Sun and Dell both sell 64-bit boxes. But the core
> question is why have two different types at all?
Operations on an Integer (e.g. addition, multplication) are not O(1).
On an Int, they are (for all intents and purposes). This
15 matches
Mail list logo
