Duncan Coutts wrote:
[...] The advantage of doing this is that it makes things easier for the
package managers. Each individual file can belong to the appropriate
package and so instead of having to execute registration/unregistration
actions on install/uninstall it's just another file to
Volker Stolz writes:
Fixed in CVS
I've tried it moments ago: Works correctly here, too, now.
Thank you.
Peter
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Peter Simons wrote:
Linux x86, I configure my build with the script:
| #! /bin/sh --
|
| GHC=ghc-6.2.2
| SUBDIRS=alex ghc haddock happy hslibs libraries
|
| for n in ${SUBDIRS} .; do
| echo $n/mk/build.mk XMLDocWays := html
| done
|
| autoreconf -i
| ./configure
Benjamin Franksen wrote:
main = let ?b = True in use_b
--use_b :: (?g::Bool) = IO ()
use_b = print ?b
It isn't: ghc -fimplicit-params says
Unbound implicit parameter (?b :: a)
arising from use of implicit parameter `?b' at TestBug.hs:4
In the first argument of `print', namely `?b'
On Saturday 06 November 2004 17:57, you wrote:
Benjamin Franksen wrote:
My question: Is this as it should be or is it a bug?
The Monomorphism Restriction.
Grumble... I almost suspected it. Only the context in which I got the error
originally didn't _look_ as if MR would apply, and when I
Hello
It appears that the console is not reset correctly with
System.Console.SimpleLineEditor. The terminal does not
echo characters until it is reset.
The following program demonstrates it:
import System.Console.SimpleLineEditor
main = initialise getLineEdited prompt = print restore
This
On Friday 05 November 2004 22:07, Keean Schupke wrote:
myRef :: IORef Int
myRef = unsafePerformIO $ newIORef 0
This should always return the same reference, whereas:
myIORef :: IO (IORef Int)
myIORef = newIORef 0
Will return a new reference every time. I agree it would seem that
the
The problem I see here is how to proove the IO in safeIO is indeed
safe. Perhaps UnsafeIO is a better name, as infact the IO is still
unsafe - the compiler has to take special notice of this type and
not inline its definitions.
Your oneShot function has the same problem - if the compiler
inlines
Vincenzo Ciancia wrote:
Yes, but I guess everybody would like a solution where
myRef1 = unsafePerformIO $ newIORef 0
myRef2 = unsafePerformIO $ newIORef 0
are different variables. Also, it's not true that it's perfectly safe,
I don't understant this - they would be different variables with
Inling isn't the only optimization, which can lead to a wrong behavior,
let floating out and common subexpression elimination can also
change the behavior
of programs using unsafePerformIO.
Our research group has developed the calculus FUNDIO as a semantic basis:
It's a non-deterministic
Just been reading arround. According to ghc docs, the noinline
pragma is in the Haskell98 report. On that basis what is wrong
with using the following to initialise these top-level constants?
{-# NOINLINE newref #-}
newref :: IORef Int
newref = unsafePerformIO $ newIORef 0
Keean.
I hope this is not a stupid idea - but why not contribute the changes
as patches back to the main GHC development?
Keean.
David Sabel wrote:
Inling isn't the only optimization, which can lead to a wrong behavior,
let floating out and common subexpression elimination can also
change the
On 6 Nov 2004, at 13:07, Keean Schupke wrote:
Just been reading arround. According to ghc docs, the noinline
pragma is in the Haskell98 report. On that basis what is wrong
with using the following to initialise these top-level constants?
{-# NOINLINE newref #-}
newref :: IORef Int
newref
The main reason is: Nobody asks for it.
I conjecture, a problem is:
if you use FUNDIO as a semantics for Haskell, you have to give up
referential transparency in the strong sense. FUNDIO-programs are
only referential transparent with respect to the defined contextual
equivalence.
David
Keean
David Sabel wrote:
The main reason is: Nobody asks for it.
Actually I think Simon Marlow has talked in the past about wanting
to make GHC only do safe optimisations on unsafePerformIO.
I conjecture, a problem is:
if you use FUNDIO as a semantics for Haskell, you have to give up
referential
Keean Schupke wrote:
David Sabel wrote:
The main reason is: Nobody asks for it.
Actually I think Simon Marlow has talked in the past about wanting
to make GHC only do safe optimisations on unsafePerformIO.
I conjecture, a problem is:
if you use FUNDIO as a semantics for Haskell, you have to give
On Saturday 06 Nov 2004 12:27 pm, Keean Schupke wrote:
The problem I see here is how to proove the IO in safeIO is indeed
safe. Perhaps UnsafeIO is a better name, as infact the IO is still
unsafe -
I don't agree. All top level bindings currently have the property that
their value is
On Saturday 06 Nov 2004 1:07 pm, Keean Schupke wrote:
Just been reading arround. According to ghc docs, the noinline
pragma is in the Haskell98 report. On that basis what is wrong
with using the following to initialise these top-level constants?
{-# NOINLINE newref #-}
newref ::
As an experiment, I just finished to change the Haskell Web Server with
Plugins such that all global variables (unsafePerformIO-style) are replaced
by standard argument passing. It wasn't difficult. The main work was
(1) get it to compile with ghc-6.2.2
(2) understand how the code is organized
I was wondering whether there might be any sort of trick one could use to
create an empty Weak a, i.e. one that has already been GCed? It should be
possible to create such a pointer without having an object of type a.
mkEmptyWeakPtr :: IO (Weak a)
I know I could get this effect by using instead
On Saturday 06 November 2004 08:36 am, you wrote:
snip
It might be an immense project, but I also think it would be interesting.
I wonder if Haskell would be much faster after being restructured around
arrows.
If an arrow-based version of Haskell existed, I'd love to try it.
I think
Since I have been experimenting with Arrows quite a bit just
recently, I feel compelled to add something to the
discussion.
I too think that Arrow are a beautifully simple and elegant
concept. However, once you write production code, you notice
quickly that there is a significant difference
On Saturday 06 November 2004 05:49 pm, Peter Simons wrote:
Since I have been experimenting with Arrows quite a bit just
recently, I feel compelled to add something to the
discussion.
I too think that Arrow are a beautifully simple and elegant
concept. However, once you write production
23 matches
Mail list logo
