On 2008-08-28 14:45 -0700 (Thu), Jonathan Cast wrote:
Now, I happen to know that the only top-level handles that can be
established without issuing an open system call are
stdin
stdout
stderr
(unless you're happy to have your global nonStdErr start its life
attached to an unopened FD).
Ashley Yakeley wrote:
Sittampalam, Ganesh wrote:
Oh dear. To fix this, I suppose the RTS would have to be able to
keep
track of all static initialisers. But it shouldn't otherwise affect
program optimisation.
What would the RTS actually do?
I don't know enough about the RTS to say. I
Sittampalam, Ganesh wrote:
Sounds plausible, although dynamic relocations do slow down linking.
Unloading is another interesting problem. Are we allowed to re-run -
if the module that contained it is unloaded and then reloaded? I'm not
quite sure what the conditions for allowing a module to be
Ashley Yakeley wrote:
I really don't know enough about the RTS to know. The
alternative would be to keep all initialised values
when the module is unloaded. I'm guessing this is more
feasible.
Easier, but a guaranteed memory leak.
Ganesh
Sittampalam, Ganesh wrote:
Ashley Yakeley wrote:
I really don't know enough about the RTS to know. The
alternative would be to keep all initialised values
when the module is unloaded. I'm guessing this is more
feasible.
Easier, but a guaranteed memory leak.
But it's limited to the
Ashley Yakeley wrote:
Sittampalam, Ganesh wrote:
In compiled code module boundaries don't necessarily exist. So how
do
you relink the loaded code so that it points to the unique copy of
the
module?
hs-plugins loads modules as single .o files, I believe.
Yes, but (a) the loading
Sittampalam, Ganesh wrote:
I talked to Don about this and you're right, that doesn't happen.
However
he also confirmed that it does load modules a second time if they are
in the main program as well as the plugin, and it would be difficult to
merge the static and dynamic versions of the module.
Adrian Hey wrote:
There's shed loads of information and semantic subtleties about pretty
much any operation you care to think of in the IO monad that isn't
communicated by it's type. All you know for sure is that it's weird,
because if it wasn't it wouldn't be in the IO monad.
So I think you're
Sittampalam, Ganesh wrote:
Oh dear. To fix this, I suppose the RTS would have to be able to
keep track of all static initialisers. But it shouldn't otherwise
affect program optimisation.
What would the RTS actually do?
I don't know enough about the RTS to say. I imagine initialisers would
Ganesh Sittampalam wrote:
In any case, what I'm trying to establish below is that it should be a
safety property of - that the entire module (or perhaps mutually
recursive groups of them?) can be duplicated safely - with a new name,
or as if with a new name - and references to it randomly
Ashley Yakeley wrote:
Ganesh Sittampalam wrote:
In any case, what I'm trying to establish below is that it should be
a
safety property of - that the entire module (or perhaps mutually
recursive groups of them?) can be duplicated safely - with a new
name,
or as if with a new name - and
David Menendez wrote:
Isn't that what we have right now? Typeable gives you a TypeRep, which
can be compared for equality. All the introspection stuff is in Data.
Oh, yes, you're right.
--
Ashley Yakeley
___
Haskell-Cafe mailing list
On Wed, Sep 3, 2008 at 2:53 AM, Ashley Yakeley [EMAIL PROTECTED] wrote:
It's worth mentioning that the current Data.Unique is part of the standard
base library, while hs-plugins is rather experimental. Currently Data.Unique
uses the NOINLINE unsafePerformIO hack to create its MVar. If
Dave Menendez wrote:
The Haskell 98 report includes NOINLINE, but
also states that environments are not required
to respect it. So hs-plugins wouldn't necessarily
be at fault if it didn't support Data.Unique.
Also, the definition of NOINLINE in the report doesn't
preclude copying both the
Sittampalam, Ganesh wrote:
That's not acceptable. This would cause Unique to break,
as its MVar would be created twice. It would also mean
that individual Unique and IOWitness values created by
- would have different values depending on which bit
of code was referencing them. It would render
David Menendez wrote:
On Wed, Sep 3, 2008 at 2:53 AM, Ashley Yakeley [EMAIL PROTECTED] wrote:
It's worth mentioning that the current Data.Unique is part of the standard
base library, while hs-plugins is rather experimental. Currently Data.Unique
uses the NOINLINE unsafePerformIO hack to create
Ashley Yakeley wrote:
I don't understand. If the dynamic loader were to load the same
package
name and version, and it duplicated the MVar, then Unique values would
have the same type and could be compared.
I am suggesting that this duplication process, whether conducted by the
dynamic loader
Ashley Yakeley wrote:
To solve this the hs-plugins dynamic loader maintains
state storing a list of what modules and packages have
been loaded already. If load is called on a module that
is already loaded, or dependencies are attempted to load,
that have already been loaded, the dynamic
Sittampalam, Ganesh wrote:
I am suggesting that this duplication process, whether conducted by the
dynamic loader or something else, should behave as if they did not have
the same package name or version.
This is certainly a valid transformation for Data.Unique, I am simply
saying that it
Ashley Yakeley wrote:
Sittampalam, Ganesh wrote:
I am suggesting that this duplication process, whether conducted by
the dynamic loader or something else, should behave as if they did
not
have the same package name or version.
This is certainly a valid transformation for Data.Unique,
Sittampalam, Ganesh wrote:
I think it treats them as compatible, using the fact that
Data.Typeable returns the same type reps (which was why I initially
mentioned Data.Typeable in this thread). This is fine for normal
modules. There's a bit of description in the Dynamic Typing section of
Ashley Yakeley wrote:
I think it's bad design for a dynamic loader to load a module more
than once anyway.
In compiled code module boundaries don't necessarily exist. So how
do you relink the loaded code so that it points to the unique copy
of the module?
It's a waste of memory, for a
Ashley Yakeley wrote:
Currently Data.Unique uses the NOINLINE unsafePerformIO
hack to create its MVar. If hs-plugins duplicates that MVar,
that's a bug in hs-plugins.
Sittampalam, Ganesh wrote:
Also, the definition of NOINLINE in the report doesn't
preclude copying both the MVar *and* its
Yitzhak Gale wrote:
Right. It would not be a bug in hs-plugins. That is
the most urgent problem right now.
[...]
For the short term - can we *please* get an ONLYONCE
pragma that has the correct semantics?
So the purpose of this pragma would solely be so that
you can declare hs-plugins buggy
I wrote:
For the short term - can we *please* get an ONLYONCE
pragma that has the correct semantics?
Sittampalam, Ganesh wrote:
So the purpose of this pragma would solely be so that
you can declare hs-plugins buggy for not respecting it?
No, the hs-plugins problem - whether hypothetical or
(apologies for misspelling your name when quoting you last time)
Yitzchak Gale wrote:
For the short term - can we *please* get an ONLYONCE pragma that has
the correct semantics?
Until a permanent solution is implemented and deployed in the
compilers (if ever), can we please have a pragma
For the short term - can we *please* get an ONLYONCE pragma that has
the correct semantics?
Sittampalam, Ganesh wrote:
How do you propose that this pragma would be implemented?
As far as I know now, in GHC it could currently just be
an alias for NOINLINE, but the GHC gurus could say for sure.
Yitzchak Gale wrote
Other applications and libraries that support the pragma - such as
other
compilers, and hs-plugins - would be required to respect the
guarantee, and bugs could be filed against them if they don't.
If hs-plugins were loading object code, how would it even know of the
I wrote
Other applications and libraries that support the pragma -
such as other compilers, and hs-plugins - would be
required to respect the guarantee, and bugs could be
filed against them if they don't.
Sittampalam, Ganesh wrote:
If hs-plugins were loading object code, how would it even
On Wed, Sep 3, 2008 at 9:30 AM, Yitzchak Gale [EMAIL PROTECTED] wrote:
I wrote
Other applications and libraries that support the pragma -
such as other compilers, and hs-plugins - would be
required to respect the guarantee, and bugs could be
filed against them if they don't.
Sittampalam,
Sittampalam, Ganesh wrote:
In compiled code module boundaries don't necessarily exist. So how
do you relink the loaded code so that it points to the unique copy
of the module?
hs-plugins loads modules as single .o files, I believe.
It crashes the RTS of the plugins loader, which is based on
Ganesh Sittampalam wrote:
You see this as a requirement that can be discharged by adding the ACIO
concept; I see it as a requirement that should be communicated in the type.
Another way of looking at it is that Data.Unique has associated with it
some context in which Unique values are safely
Ganesh Sittampalam wrote:
I have a feeling it might be non-trivial; the dynamically loaded bit of
code will need a separate copy of the module in question, since it might
be loaded into something where the module is not already present.
Already the dynamic loader must load the module into the
On Tue, 2 Sep 2008, Ashley Yakeley wrote:
Ganesh Sittampalam wrote:
I have a feeling it might be non-trivial; the dynamically loaded bit of
code will need a separate copy of the module in question, since it might be
loaded into something where the module is not already present.
Already the
On Tue, 2 Sep 2008, Adrian Hey wrote:
Ganesh Sittampalam wrote:
You see this as a requirement that can be discharged by adding the ACIO
concept; I see it as a requirement that should be communicated in the type.
Another way of looking at it is that Data.Unique has associated with it
some
Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Adrian Hey wrote:
Eh? Please illustrate your point with Data.Unique. What requirements
does it place on it's context? (whatever that might mean :-)
It requires that its context initialises it precisely once.
It's context being main? If so this
Adrian Hey wrote:
We have to have something concrete to discuss and this is the simplest.
Like I said there are a dozen or so other examples in the base package
last time I counted and plenty of people have found that other libs/ffi
bindings need them for safety reasons. Or at least they need
On Mon, 1 Sep 2008, Adrian Hey wrote:
Actually all this use of the tainted and derogatory term global
variable is causing me to be imprecise. All MVars/IORefs have global
main/process scope whether or not they're bound to something at the
top level.
Global variable is exactly the right term
On Thu, Aug 28, 2008 at 07:21:48PM -0400, Brandon S. Allbery KF8NH wrote:
OS provided one? What if you have an exokernel, where it is expected
these things _will_ be implemented in the userspace code. why
shouldn't
that part of the exokernel be written in haskell?
What's stopping it? Just
On Fri, Aug 29, 2008 at 04:33:50PM -0700, Dan Weston wrote:
C++ faced this very issue by saying that with global data, uniqueness of
initialization is guaranteed but order of evaluation is not. Assuming
that the global data are merely thunk wrappers over some common data
source, this
On Mon, 1 Sep 2008, John Meacham wrote:
On Mon, Sep 01, 2008 at 10:45:05PM +0100, Ganesh Sittampalam wrote:
Actually all this use of the tainted and derogatory term global
variable is causing me to be imprecise. All MVars/IORefs have global
main/process scope whether or not they're bound to
On 2008 Sep 1, at 18:08, Ganesh Sittampalam wrote:
On Mon, 1 Sep 2008, John Meacham wrote:
On Mon, Sep 01, 2008 at 10:45:05PM +0100, Ganesh Sittampalam wrote:
Actually all this use of the tainted and derogatory term global
variable is causing me to be imprecise. All MVars/IORefs have
global
On Mon, 1 Sep 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Sep 1, at 18:08, Ganesh Sittampalam wrote:
On Mon, 1 Sep 2008, John Meacham wrote:
for instance, windows dll's have
the ability to share individual variables across all loadings of said
dll. (for better or worse.)
Interesting, is
On Mon, 1 Sep 2008, Adrian Hey wrote:
Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Adrian Hey wrote:
Eh? Please illustrate your point with Data.Unique. What requirements
does it place on it's context? (whatever that might mean :-)
It requires that its context initialises it precisely
Ganesh Sittampalam wrote:
Well, the question of whether multiple copies of a module are ok is
still open, I guess - as you say later, it seems perfectly reasonable
for two different versions of Data.Unique to exist, each with their own
types and global variables - so why not two copies of the
On Mon, 1 Sep 2008, Ashley Yakeley wrote:
Ganesh Sittampalam wrote:
Well, the question of whether multiple copies of a module are ok is still
open, I guess - as you say later, it seems perfectly reasonable for two
different versions of Data.Unique to exist, each with their own types and
Ganesh Sittampalam wrote:
Right, but they might be the same package version, if one is a
dynamically loaded bit of code and the other isn't.
OK. It's up to the dynamic loader to deal with this, and make sure that
initialisers are not run more than once when it loads the package into
the RTS.
On Mon, 1 Sep 2008, Ashley Yakeley wrote:
Ganesh Sittampalam wrote:
Right, but they might be the same package version, if one is a dynamically
loaded bit of code and the other isn't.
OK. It's up to the dynamic loader to deal with this, and make sure that
initialisers are not run more than
Dan Doel wrote:
Here's a first pass:
-- snip --
{-# LANGUAGE Rank2Types, GeneralizedNewtypeDeriving #-}
module Unique where
import Control.Monad.Reader
import Control.Monad.Trans
import Control.Concurrent.MVar
-- Give Uniques a phantom region parameter, so that you can't accidentally
--
On Sat, 30 Aug 2008, Ashley Yakeley wrote:
OK. Let's call it top-level scope. Haskell naturally defines such a
thing, regardless of processes and processors. Each top-level - would
run at most once in top-level scope.
If you had two Haskell runtimes call by C code, each would have its own
On Sat, 30 Aug 2008, Adrian Hey wrote:
Ganesh Sittampalam wrote:
Well, yes, but if I implemented a library in standard Haskell it would
always be safely serialisable/deserialisable (I think). So the global
variables hack somehow destroys that property - how do I work out why it
does in some
On 2008 Aug 31, at 10:20, Ganesh Sittampalam wrote:
On Sat, 30 Aug 2008, Adrian Hey wrote:
But then again, I'm sure that some that will be adamant that any way
of making global variables is a hack. But they'll still be happy
to go on using file IO, sockets etc regardless, blissfully unaware
of
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 10:20, Ganesh Sittampalam wrote:
I'm not sure of precisely what you mean here, but stdin, stdout and
stderr are things provided by the OS to a process. That's what defines
them as having process scope, not something the
On 2008 Aug 31, at 10:29, Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 10:20, Ganesh Sittampalam wrote:
I'm not sure of precisely what you mean here, but stdin, stdout
and stderr are things provided by the OS to a process. That's what
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 10:29, Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 10:20, Ganesh Sittampalam wrote:
I'm not sure of precisely what you mean here, but stdin, stdout and
stderr are
On 2008 Aug 31, at 10:34, Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 10:29, Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 10:20, Ganesh Sittampalam wrote:
I'm not sure of precisely what
On Sun, 31 Aug 2008, Adrian Hey wrote:
Thanks for taking the time to do this Dan. I think the safety
requirement has been met, but I think it fails on the improved API. The
main complaint would be what I see as loss of modularity, in that
somehow what should be a small irrelevant detail of
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 10:34, Ganesh Sittampalam wrote:
I don't follow what you mean. stdin, stdout and stderr are just file
descriptors 0, 1 and 2, aren't they? You can create them as many times as
you want with using that information
On 2008 Aug 31, at 10:44, Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 10:34, Ganesh Sittampalam wrote:
I don't follow what you mean. stdin, stdout and stderr are just
file descriptors 0, 1 and 2, aren't they? You can create them as
many
Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Adrian Hey wrote:
Thanks for taking the time to do this Dan. I think the safety
requirement has been met, but I think it fails on the improved API.
The main complaint would be what I see as loss of modularity, in that
somehow what should be a
On 2008 Aug 31, at 11:20, Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 10:44, Ganesh Sittampalam wrote:
In that case it seems that any library that might be used from a
runtime that isn't the top-level of a process should avoid doing
IO
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 11:20, Ganesh Sittampalam wrote:
Where do the filehandle structures live in the latter case?
The place you clearly think so little of that you need to ask:
process-global (or process-local depending on how you think
On Sun, 31 Aug 2008, Adrian Hey wrote:
Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Adrian Hey wrote:
Thanks for taking the time to do this Dan. I think the safety requirement
has been met, but I think it fails on the improved API. The main complaint
would be what I see as loss of
On 2008 Aug 31, at 12:01, Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 11:20, Ganesh Sittampalam wrote:
Where do the filehandle structures live in the latter case?
The place you clearly think so little of that you need to ask:
Ganesh Sittampalam wrote:
On Sat, 30 Aug 2008, Ashley Yakeley wrote:
OK. Let's call it top-level scope. Haskell naturally defines such a
thing, regardless of processes and processors. Each top-level - would
run at most once in top-level scope.
If you had two Haskell runtimes call by C code,
On 2008-08-28, Yitzchak Gale [EMAIL PROTECTED] wrote:
However we work that out, right now we need a working
idiom to get out of trouble when this situation comes up.
What we have is a hack that is not guaranteed to work.
We are abusing the NOINLINE pragma and assuming
things about it that are
On Sat, 30 Aug 2008, Adrian Hey wrote:
Ganesh Sittampalam wrote:
Will Data.Unique still work properly if a value is sent across a RPC
interface?
A value of type Unique you mean? This isn't possible. Data.Unique has
been designed so cannot be Shown/Read or otherwise
serialised/deserialised
Ganesh Sittampalam wrote:
How do the implementers of Data.Unique know that they musn't let them be
serialised/deserialised?
Because if you could take a String and convert it to a Unique there
would be no guarantee that result was *unique*.
What stops the same rule from applying to
Ganesh Sittampalam wrote:
If you want to standardise a language feature, you have to explain its
behaviour properly. This is one part of the necessary explanation.
To be concrete about scenarios I was considering, what happens if:
- the same process loads two copies of the GHC RTS as part of
Philippa Cowderoy wrote:
Talking of which, we really ought to look at an IO typeclass or two (not
just our existing MonadIO) and rework the library ops to use it in
Haskell'. You're not the only one to want it, and if it's not fixed this
time it may never get fixed.
This could allow both the
On Sat, 30 Aug 2008, Ashley Yakeley wrote:
Ganesh Sittampalam wrote:
If you want to standardise a language feature, you have to explain its
behaviour properly. This is one part of the necessary explanation.
To be concrete about scenarios I was considering, what happens if:
- the same
On Sat, 30 Aug 2008, Adrian Hey wrote:
Ganesh Sittampalam wrote:
How do the implementers of Data.Unique know that they musn't let them be
serialised/deserialised?
Because if you could take a String and convert it to a Unique there
would be no guarantee that result was *unique*.
Well, yes,
Ganesh Sittampalam wrote:
Every single call to newIORef, across the whole world, returns a
different ref.
How do you know? How can you compare them, except in the same Haskell
expression?
The same one as a previous one can only be returned
once the old one has become unused (and GCed).
On Sat, 30 Aug 2008, Ashley Yakeley wrote:
Ganesh Sittampalam wrote:
Every single call to newIORef, across the whole world, returns a different
ref.
How do you know? How can you compare them, except in the same Haskell
expression?
I can write to one and see if the other changes.
The same
Ashley Yakeley wrote:
I don't really follow this. Do you mean the minimal such scope, or the
maximal such scope? The problem here is not about separate calls to
newIORef, it's about how many times an individual - will be executed.
Two IO executions are in the same global scope if their
Ganesh Sittampalam wrote:
How do the implementers of Data.Unique know that they musn't let them be
serialised/deserialised? What stops the same rule from applying to
Data.Random?
Unique values should be no more deserialisable than IORefs.
Is it the functionality of Data.Unique that you
On Sat, 30 Aug 2008, Ashley Yakeley wrote:
Is it the functionality of Data.Unique that you object to, or the fact that
it's implemented with a global variable?
If the former, one could easily build Unique values on top of IORefs, since
IORef is in Eq. Thus Data.Unique is no worse than IORefs
Ganesh Sittampalam wrote:
How can they be the same unless the memory management system is broken?
I consider different pointers on different machines or in different
virtual address spaces different too; it's the fact that they don't
alias that matters.
But the actual pointer value might
Ganesh Sittampalam wrote:
This seems fine to me. It's based on something that already does work
properly across a process scope,
But you agree that IORefs define a concept of process scope?
instead of some new language feature that is actually hard to implement across
the process scope.
On Sat, 30 Aug 2008, Ashley Yakeley wrote:
Ganesh Sittampalam wrote:
This seems fine to me. It's based on something that already does work
properly across a process scope,
But you agree that IORefs define a concept of process scope?
I'm not sure that they *define* process scope, because it
Ganesh Sittampalam wrote:
On Sat, 30 Aug 2008, Adrian Hey wrote:
Because if you could take a String and convert it to a Unique there
would be no guarantee that result was *unique*.
Well, yes, but if I implemented a library in standard Haskell it would
always be safely
Ganesh Sittampalam wrote:
On Sat, 30 Aug 2008, Ashley Yakeley wrote:
Ganesh Sittampalam wrote:
This seems fine to me. It's based on something that already does work
properly across a process scope,
But you agree that IORefs define a concept of process scope?
I'm not sure that they
On Sat, 30 Aug 2008, Ashley Yakeley wrote:
Ganesh Sittampalam wrote:
On Sat, 30 Aug 2008, Ashley Yakeley wrote:
Ganesh Sittampalam wrote:
This seems fine to me. It's based on something that already does work
properly across a process scope,
But you agree that IORefs define a concept of
Ganesh Sittampalam wrote:
Firstly, that's a property of the current implementation, rather than a
universal one, IMO. I don't for example see why you couldn't add a
newIORef variant that points into shared memory, locking issues aside.
OK, so that would be a new Haskell feature. And it's that
On Sat, 30 Aug 2008, Ashley Yakeley wrote:
Ganesh Sittampalam wrote:
Firstly, that's a property of the current implementation, rather than a
universal one, IMO. I don't for example see why you couldn't add a
newIORef variant that points into shared memory, locking issues aside.
OK, so that
Adrian Hey wrote:
Global variables are needed to ensure important safety properties,
but the only reasons I've seen people give for thread local variables
is that explicit state threading is just so tiresome and ugly. Well
that may be (wouldn't disagree), but I'm not aware of any library
that
On 2008 Aug 30, at 6:28, Adrian Hey wrote:
Ganesh Sittampalam wrote:
How do the implementers of Data.Unique know that they musn't let
them be serialised/deserialised?
Because if you could take a String and convert it to a Unique there
would be no guarantee that result was *unique*.
What
Ganesh Sittampalam wrote:
By global scope, I mean the largest execution scope an IORef created
by newIORef can have. Each top-level IORef declaration should create
an IORef at most once in this scope.
That's a reasonable definition, if by execution scope you mean your
previous definition of
Brandon S. Allbery KF8NH wrote:
On 2008 Aug 28, at 20:45, Adrian Hey wrote:
Lennart Augustsson wrote:
If Haskell had always taken the pragmatic path of adding what seems
easiest and most in line with imperative practice it would not be the
language it is today. It would be Perl, ML, or
On 2008 Aug 29, at 4:22, Adrian Hey wrote:
Brandon S. Allbery KF8NH wrote:
On 2008 Aug 28, at 20:45, Adrian Hey wrote:
Lennart Augustsson wrote:
If Haskell had always taken the pragmatic path of adding what seems
easiest and most in line with imperative practice it would not be
the
Brandon S. Allbery KF8NH wrote:
On 2008 Aug 29, at 4:22, Adrian Hey wrote:
Brandon S. Allbery KF8NH wrote:
On 2008 Aug 28, at 20:45, Adrian Hey wrote:
Lennart Augustsson wrote:
If Haskell had always taken the pragmatic path of adding what seems
easiest and most in line with imperative
On Thu, 28 Aug 2008, Adrian Hey wrote:
Ganesh Sittampalam wrote:
On Thu, 28 Aug 2008, Adrian Hey wrote:
There's no semantic difficulty with the proposed language extension,
How does it behave in the presence of dynamic loading?
To answer this you need to be precise about the semantics of
C++ faced this very issue by saying that with global data, uniqueness of
initialization is guaranteed but order of evaluation is not. Assuming
that the global data are merely thunk wrappers over some common data
source, this means that at minimum, there can be no data dependencies
between
On Fri, Aug 29, 2008 at 4:33 PM, Dan Weston [EMAIL PROTECTED] wrote:
C++ faced this very issue by saying that with global data, uniqueness of
initialization is guaranteed but order of evaluation is not.
In C++ circles, this is referred to as the static initialization
order fiasco, and it is a
I actually was more interested in the problems with the obvious fix
for this, namely the construct on first use idiom:
int A(int a) { static int aa = a; return aa; }
int B() { return A(3); }
int C() { return A(7); }
int D() { if (today() == Tuesday) B(); else C(); return a(0); }
Ganesh Sittampalam wrote:
Will Data.Unique still work properly if a value is sent across a RPC
interface?
A value of type Unique you mean? This isn't possible. Data.Unique has
been designed so cannot be Shown/Read or otherwise
serialised/deserialised (for obvious reasons I guess).
Also what
Bryan O'Sullivan wrote:
I haven't seen a coherent description of
what the semantics of top-level - should be, but avoidance of
widespread swearing would be at the top of my list of requirements.
Don't the ACIO monad properties satisfy you?
Anyway, as I pointed out in my last post, if this is
I'm certain you can write a kernel in Haskell where the only use of
global variables is those that hardware interfacing forces you to use.
On Thu, Aug 28, 2008 at 3:32 AM, John Meacham [EMAIL PROTECTED] wrote:
On Thu, Aug 28, 2008 at 12:15:10AM +0100, Lennart Augustsson wrote:
I didn't say
Hello Lennart,
Thursday, August 28, 2008, 12:00:41 PM, you wrote:
I'm certain you can write a kernel in Haskell where the only use of
global variables is those that hardware interfacing forces you to use.
moreover, you can write it in Turing machine. the question is just how
comfortable it
Jonathan Cast wrote:
On Wed, 2008-08-27 at 11:53 +0100, Adrian Hey wrote:
John Meacham wrote:
As with all design decisions, it is sometimes the right thing and
sometimes the wrong one. And sometimes the most expedient. (which,
occasionally, is a perfectly valid driving force behind a certain
1 - 100 of 176 matches
Mail list logo
