On Sat, 6 Sep 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Sep 6, at 18:25, Ashley Yakeley wrote:
2. If the dynamic loader loads an endless stream of different modules
containing initialisers, memory will thus leak.
I think if the issue is this vs. not being able to guarantee any
On 2008 Sep 7, at 6:23, Ganesh Sittampalam wrote:
On Sat, 6 Sep 2008, Ashley Yakeley wrote:
Ganesh Sittampalam wrote:
The set of ACIO expressions exp is the static initialisers of
M. The RTS must note when each static initialiser is run, and
cache its result val. Let's call this cache of
On 2008 Sep 7, at 12:10, Ganesh Sittampalam wrote:
On Sun, 7 Sep 2008, Brandon S. Allbery KF8NH wrote:
Since you consider memory leaks to be worse than correct behavior,
Not leaking memory is *part* of correct behaviour. If - is to be
created at all, it should be created with restrictions
On Sun, 7 Sep 2008, Brandon S. Allbery KF8NH wrote:
You seem to think we must never insure that something will only be run
once, that any program that does require this is broken. As such, the
standard Haskell libraries (including some whose interfaces are H98) are
unfixably broken and you'd
On 2008 Sep 6, at 6:10, Ashley Yakeley wrote:
Ganesh Sittampalam wrote:
I would call it a leak if something that is no longer being used
cannot be reclaimed. The endless stream of different modules is
possible in long-running systems where the code being run evolves
or changes over time
On Sat, 6 Sep 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Sep 6, at 6:10, Ashley Yakeley wrote:
The set of ACIO expressions exp is the static initialisers of M. The RTS
must note when each static initialiser is run, and cache its result val.
Let's call this cache of vals the static
On 2008 Sep 6, at 11:22, Ganesh Sittampalam wrote:
On Sat, 6 Sep 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Sep 6, at 6:10, Ashley Yakeley wrote:
The set of ACIO expressions exp is the static initialisers of M.
The RTS must note when each static initialiser is run, and cache
its result
On Sat, 6 Sep 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Sep 6, at 11:22, Ganesh Sittampalam wrote:
On Sat, 6 Sep 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Sep 6, at 6:10, Ashley Yakeley wrote:
The set of ACIO expressions exp is the static initialisers of M. The
RTS must note when each
On 2008 Sep 6, at 18:06, Ashley Yakeley wrote:
Ganesh Sittampalam wrote:
The set of ACIO expressions exp is the static initialisers of
M. The RTS must note when each static initialiser is run, and
cache its result val. Let's call this cache of vals the static
results cache of M.
When M
On 2008 Sep 6, at 18:25, Ashley Yakeley wrote:
1. Results from initialisers cannot be GC'd even if they become
otherwise unreachable, because the dynamic loader might re-load the
module (and then we'd need those original results).
2. If the dynamic loader loads an endless stream of different
Jim Apple wrote:
Does anyone have examples of these? This one scares the foo out of me:
* It's not even safe in general to add a signature giving the same type
that the compiler would infer anyway
Here's an example:
len :: [a] - Int
len xs = let ?accum = 0 in len' xs
len'
Ben Rudiak-Gould wrote:
len :: [a] - Int
len xs = let ?accum = 0 in len' xs
len' :: forall a. (?accum :: Int) = [a] - Int
len' [] = ?accum
len' (x:xs) = let ?accum = ?accum + (1::Int) in len' xs
*Main :t len'
len' :: forall a. (?accum :: Int) = [a] - Int
Can a C function be pure? I guess it can... The trouble is you cannot
proove its
pure?
But - why would you want to use a pure C function. The chances of any useful
C library function being pure are slim - and the performance of GHC in some
of the benchmarks shows that there is hardly any speed
Keean Schupke wrote:
Can a C function be pure? I guess it can... The trouble is you cannot
proove its
pure?
But - why would you want to use a pure C function.
Because it already exists? E.g. most BLAS/LAPACK functions are pure;
should they be re-written in Haskell?
[Yes, I know that
Keean Schupke wrote:
Can a C function be pure? I guess it can... The trouble is you cannot
proove its
pure?
A C function might have no observable side effects, even if it operates
destructively over its own private data structures. It mightn't be too
hard to establish a sound test for this sort
Have you looked at Linear Aliasing, the type system used for TAL (typed
assembly
language)... one would assume that if a C compiler which compiles to TAL
were
produces, then you could proove purity?
Keean.
Conor McBride wrote:
Keean Schupke wrote:
Can a C function be pure? I guess it can... The
Glynn Clements wrote:
I thought these libraries did have some global state, like choosing
which solver is used... In which case treating them as pure could
be dangerous...
Keean.
Keean Schupke wrote:
Can a C function be pure? I guess it can... The trouble is you cannot
proove its
pure?
But
On Tuesday 23 November 2004 10:03, you wrote:
But - why would you want to use a pure C function. The chances of any
useful C library function being pure are slim - and the performance of GHC
in some of the benchmarks shows that there is hardly any speed advantage
The typical case (for me) is a
On Mon, Nov 22, 2004 at 08:32:33PM +, Graham Klyne wrote:
[Switching to Haskell-cafe]
At 11:26 22/11/04 +, you wrote:
I would ask an alternative question - is it possible to live without
unsafePerformIO? I have never needed to use it!
There are plenty of non-IO reasons to use
David Roundy wrote:
There are plenty of non-IO reasons to use unsafePerformIO, for which it is
essential. If you want to write haskell code that uses a pointer
(allocated possibly via an FFI C routine), it has to be in the IO monad.
If you know that this pointer doesn't access memory that'll be
On Tue, Nov 23, 2004 at 01:51:24PM +, Keean Schupke wrote:
David Roundy wrote:
There are plenty of non-IO reasons to use unsafePerformIO, for which it is
essential. If you want to write haskell code that uses a pointer
(allocated possibly via an FFI C routine), it has to be in the IO
On Monday 22 November 2004 23:22, Keean Schupke wrote:
It seems to me that as unsafePerformIO is not in the standard and only
implemented on some
compilers/interpreters, that you limit the portability of code by using
it, and that it is best avoided. Also as any safe use of unsafePerformIO
22 matches
Mail list logo
