Hi,
Finding unsafeCoerce# in the documentation is challenging at best.
It's not indexed by Haddock, which in turn means its not indexed by
Hoogle. Lambdabot doesn't find it. Googling gave me GhcExts (from an
old Happy file), which I guessed at GHC.Exts.
Someone in #haskell suggested GHC.Base.
On 7/31/06, Neil Mitchell [EMAIL PROTECTED] wrote:
Hi,
Finding unsafeCoerce# in the documentation is challenging at best.
It's not indexed by Haddock, which in turn means its not indexed by
Hoogle. Lambdabot doesn't find it. Googling gave me GhcExts (from an
old Happy file), which I guessed at
Hello p,
Sunday, July 30, 2006, 7:21:07 AM, you wrote:
Leroy and even MLton uses GMP. Robert Dockins wrote a type-based
library for arbitrary that can (slowly) handle big numbers (up to
10^15), see http://www.eecs.tufts.edu/~rdocki01/typenats.html I don't
this don't have anything common
Hi
On 7/30/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
(Sorry for the repost: I needed to correct a few typos--thanks
Seth--and clarify a few things.)
GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum library, BN.
I have two questions concerning this:
(1) Why not use the
[EMAIL PROTECTED] wrote:
GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum
library, BN. I have two questions concerning this:
From the ticket, this looks very scary:
but its LGPL license is problematic for users of GHC
(it prohibits static linking of
On 7/30/06, Brian Hulley [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum
library, BN. I have two questions concerning this:
From the ticket, this looks very scary:
but its LGPL license is problematic for users of
On Sun, 2006-07-30 at 11:53 +0100, Brian Hulley wrote:
[EMAIL PROTECTED] wrote:
GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum
library, BN. I have two questions concerning this:
From the ticket, this looks very scary:
but its LGPL license is problematic for
Esa Ilari Vuokko wrote:
On 7/30/06, Brian Hulley [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum
library, BN. I have two questions concerning this:
From the ticket, this looks very scary:
but its LGPL license
Duncan Coutts wrote:
On Sun, 2006-07-30 at 11:53 +0100, Brian Hulley wrote:
[EMAIL PROTECTED] wrote:
GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum
library, BN. I have two questions concerning this:
From the ticket, this looks very scary:
but its LGPL license
Hi Duncan,
On 7/30/06, Duncan Coutts [EMAIL PROTECTED] wrote:
GHC only statically links Haskell code. It dynamically links to GMP and
the system C library and other C libs.
In Windows (mingw) GMP is linked in statically (even this dll-stuff is
bitrotted).
So you're fine.
On unix you can
Hi Brian,
On 7/30/06, Brian Hulley [EMAIL PROTECTED] wrote:
Still, a slight problem is that since there is one object file per source
file, the names of the object files give quite a lot of information away
about the structure of the program especially when they are arranged in a
module
Esa Ilari Vuokko wrote:
Hi Brian,
On 7/30/06, Brian Hulley [EMAIL PROTECTED] wrote:
Still, a slight problem is that since there is one object file per
source file, the names of the object files give quite a lot of
information away about the structure of the program especially when
they are
Brian,
The standard method of skirting the LGPL restriction and saving your
source code is to link dynamically in a separate step and then
distribute your program along with the dynamically linked LGPL'd
library. Compile with ghc -c (or with ghc -c -odir 'separate
directory where you want to
[EMAIL PROTECTED] wrote:
Brian,
The standard method of skirting the LGPL restriction and saving your
source code is to link dynamically in a separate step and then
distribute your program along with the dynamically linked LGPL'd
library. Compile with ghc -c (or with ghc -c -odir 'separate
On Sun, 2006-07-30 at 17:33 +0100, Brian Hulley wrote:
I think the main problem here is that I'm using Windows, so there is no way
to dynamically link with the runtime libraries - the GHC implementations
available for Windows only produce statically linked executables.
Perhaps Windows
Duncan Coutts wrote:
On Sun, 2006-07-30 at 17:33 +0100, Brian Hulley wrote:
I think the main problem here is that I'm using Windows, so there is
no way to dynamically link with the runtime libraries - the GHC
implementations available for Windows only produce statically linked
executables.
On Sun, 2006-07-30 at 19:03 +0100, Duncan Coutts wrote:
On Sun, 2006-07-30 at 17:33 +0100, Brian Hulley wrote:
I think part of the issue is that static linking is very convenient and
dynamic linking in this case would lead to some tricky administrative
problems.
Suppose for a moment that
Brian,
Sorry, I smash out emails without thinking and forgot GHC is
distributed with static archives in Windows. No more. Even if you
build the GHC runtime library from source as DLLs you will run into
another problem, as noted in the DLL-NOTES file (see http://
On Sun, 2006-07-30 at 20:02 +0100, Brian Hulley wrote:
Suppose for a moment that GHC did dynamically link gmp.dll, or indeed
HSbase.dll. Where exactly would these files go?
I'd install them in the same directory as ghc.exe because this directory has
to be on the %PATH% for the command
On Mon, 2006-07-31 at 05:00 +1000, skaller wrote:
On Sun, 2006-07-30 at 19:03 +0100, Duncan Coutts wrote:
On Sun, 2006-07-30 at 17:33 +0100, Brian Hulley wrote:
I think part of the issue is that static linking is very convenient and
dynamic linking in this case would lead to some tricky
Peter Tanski wrote:
[snip]
The advantage to free software is
that, like the Haskell language, you get to use some of the most
advanced programming available. So here I am, trying to figure out
what I can do to help GHC, since right now GHC is the only actively
maintained, current Haskell
Neil Mitchell wrote:
Hi Brian,
So here I am, trying to figure out
what I can do to help GHC, since right now GHC is the only actively
maintained, current Haskell compiler available.
nhc98 and Yhc are both compilers which are actively maintained.
(In any case, nhc98
uses GMP as well, so
Duncan Coutts wrote:
On Sun, 2006-07-30 at 20:02 +0100, Brian Hulley wrote:
[snip]
app. When the app runs, Windows will first look in the app's
directory and therefore find the correct set of DLLs.
Yes, it's fine for distributing applications but not much good for
libraries.
Hi Duncan -
On 29.07 13:25, Frederik Eaton wrote:
I think support for thread-local variables is something which is
urgently needed. It's very frustrating that using concurrency in
Haskell is so easy and nice, yet when it comes to IORefs there is no
way to get thread-local behavior. Furthermore, that one
On Sun, Jul 30, 2006 at 12:35:42PM +0300, Einar Karttunen wrote:
On 29.07 13:25, Frederik Eaton wrote:
I think support for thread-local variables is something which is
urgently needed. It's very frustrating that using concurrency in
Haskell is so easy and nice, yet when it comes to IORefs
On 30.07 11:49, Frederik Eaton wrote:
No, because the thread in which it runs inherits any thread-local
state from its parent.
So we have different threads modifying the thread-local state?
If it is a copy then updates are not propagated.
What about a design with 10 worker threads taking
On Mon, Jul 31, 2006 at 03:54:29AM +0300, Einar Karttunen wrote:
On 30.07 11:49, Frederik Eaton wrote:
No, because the thread in which it runs inherits any thread-local
state from its parent.
So we have different threads modifying the thread-local state?
If it is a copy then updates are
Hi All,
On 7/31/06, Einar Karttunen ekarttun@cs.helsinki.fi wrote:
My main objection to the TLS is that it looks like normal IO,
but changing the thread that evaluates it can break things in ways
that are hard to debug. E.g. we have an application that uses
TLS and passes an IO action to a
Hi all.
I've seen two definitions of a 'strict function', which I'm trying to
unite in my mind:
1) f is strict iff f _|_ = _|_.
2) f is strict iff it forces evaluation of its arguments.
There is a large sticking point that in my minds seems to fit (1) but
not (2): id. Clearly, id undefined is
On 29.07 14:07, Brian Sniffen wrote:
I'm very excited by the ability to pass functions or IO actions
between threads of the same program. But I don't see any language or
library support for doing so between programs, or between sessions
with the same program. OCaml provides a partial
David House [EMAIL PROTECTED] writes:
Hi all.
I've seen two definitions of a 'strict function', which I'm trying to
unite in my mind:
1) f is strict iff f _|_ = _|_.
2) f is strict iff it forces evaluation of its arguments.
There is a large sticking point that in my minds seems to fit
On Sun, Jul 30, 2006 at 09:44:25AM +0100, David House wrote:
I've seen two definitions of a 'strict function', which I'm trying to
unite in my mind:
1) f is strict iff f _|_ = _|_.
2) f is strict iff it forces evaluation of its arguments.
There is a large sticking point that in my minds
Hi -
Part 1 of 2 - Monoid versus MonadPlus
===
I've just run into a troublesome question when trying to design a sequence
class:
class ISeq c a | c - a where
empty :: c
single :: a - c
append :: c - c - c
However I've noticed that people
On 30/07/06, Ian Lynagh [EMAIL PROTECTED] wrote:
If the value of (id x) is demanded then the value of x will always be
demanded. Therefore id is strict in its first argument.
...
In place of your 2), I would say
(f x0 .. xn) is strict in xi if demanding the value of (f x0 .. xn)
requires
* SevenThunders:
OK it was stupid. Apparently GHC behaves differently according to what the
name of the high level source file is. If I renamed test.hc to main.hc
everything works the same as GHCi. I probably should actually read the
manual some day.
Some operating systems have a test
On Sun, 2006-07-30 at 10:56 +0100, Jón Fairbairn wrote:
David House [EMAIL PROTECTED] writes:
Hi all.
I've seen two definitions of a 'strict function', which I'm trying to
unite in my mind:
1) f is strict iff f _|_ = _|_.
2) f is strict iff it forces evaluation of its arguments.
Duncan Coutts [EMAIL PROTECTED] writes:
On Sun, 2006-07-30 at 10:56 +0100, Jón Fairbairn wrote:
David House [EMAIL PROTECTED] writes:
1) f is strict iff f _|_ = _|_.
2) f is strict iff it forces evaluation of its arguments.
In (2), you have to be evaluating f on an argument before f
On Sun, 2006-07-30 at 15:01 +0100, allan wrote:
however with version 6.4.2 I get the following error:
haskellprint$ ./Setup.hs build
Preprocessing executables for haskellprint-0.1...
Building haskellprint-0.1...
Chasing modules from: Main.hs
Could not find module
On Sun, 2006-07-30 at 13:22 +0100, Jón Fairbairn wrote:
Duncan Coutts [EMAIL PROTECTED] writes:
On Sun, 2006-07-30 at 10:56 +0100, Jón Fairbairn wrote:
David House [EMAIL PROTECTED] writes:
1) f is strict iff f _|_ = _|_.
2) f is strict iff it forces evaluation of its arguments.
The Text.ParserCombinators.Parsec modules are in the parsec module.
build-depends: base
Add parsec here:
build-depends: base, parsec
The reason it works when you run it without -hide-all-packages is that
by default for convenience all packages are 'exposed'. That is they can
be
Hi
so basically I was expecting 'Char' to be in the 'base' package, I guess
this is wrong?
Yes, Char is in the haskell98 package, the new name for Char is
Data.Char which exports a bit more. Either add haskell98 as a package,
or replace Char with Data.Char (which is in base), I'd recommend
Yes, Char is in the haskell98 package, the new name for Char is
Data.Char which exports a bit more. Either add haskell98 as a package,
or replace Char with Data.Char (which is in base), I'd recommend the
latter, but either should work.
Thanks
Neil
a ha, that works, thank you both very much,
On Sunday 30 July 2006 07:47, Brian Hulley wrote:
Hi -
Part 1 of 2 - Monoid versus MonadPlus
===
I've just run into a troublesome question when trying to design a sequence
class:
class ISeq c a | c - a where
empty :: c
single :: a - c
On 7/30/06, Einar Karttunen ekarttun@cs.helsinki.fi wrote:
On 29.07 14:07, Brian Sniffen wrote:
I'm very excited by the ability to pass functions or IO actions
between threads of the same program. But I don't see any language or
library support for doing so between programs, or between
Yes I do have another test on my path. It is in a utilities directory of
unix like commands that have been ported to windows. However I also have a
test.exe that was created by ghc that seems to do nothing, even if I type
./test.exe. Thanks for the hint though.
--
View this message in
Florian Weimer wrote:
* SevenThunders:
OK it was stupid. Apparently GHC behaves differently according to what
the
name of the high level source file is. If I renamed test.hc to main.hc
everything works the same as GHCi. I probably should actually read the
manual some day.
Some
On 30.07 12:12, Jason Dagit wrote:
Depending on the type of sandboxing that you need/want #2 might be
possible with GHC. Take lambdabot for example. lambdabot has made it
safe to allow arbitrary expression evaluation by disallowing IO and
not importing unsafePerformIO and similar unsafe
Robert Dockins wrote:
On Sunday 30 July 2006 07:47, Brian Hulley wrote:
Another option, is the Edison library which uses:
class (Functor s, MonadPlus s) = Sequence s where
so here MonadPlus is used instead of Monoid to provide empty and
append. So I've got three main questions:
1) Did
Hi everyone -
I'm very much a Haskell newbie, but have followed Haskell (and the
various Haskell sites) for quite a few months now, and I absolutely
*love* the language.
One thing that **fascinated** me a while ago was the site which gave
Haskell code for a Haskell-based fileserver/OS using
49 matches
Mail list logo
