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 plugins where the order of evaluation matters.
Another C++ comparison is with a virtual base class, where A::B::D and
A::C::D are supposed to be equal, irrespective of whether it was B or C
that first called the constructor. In this case, some witness (a vtable)
is necessary to ensure that this happens correctly.
Dan
Ganesh Sittampalam wrote:
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 what
is being dynamically loaded. But this is too complex an issue
for me to get in to right now.
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 two
completely independent libraries? For added complications, imagine that
one of the libraries uses a different implementation instead (e.g. Hugs)
- one Haskell program loads several different plugins in a way that
allows Haskell values to pass across the plugin boundary
How do these scenarios work with use cases for <- like (a) Data.Unique
and (b) preventing multiple instantiation of a sub-library?
Actually as far as things like hs-plugins are concerned I'd alway
meant one day what exactly a "plugin" is, semantically. But as I've
never had cause to use them so never got round to it. Like is it a
value, or does it have state and identity or what?
Personally I think of them as values. I'm not sure what your questions
about state and identity mean. If you don't have global variables, then
state doesn't matter.
What about remote procedure calls?
Dunno, what problem do you anticipate?
Will Data.Unique still work properly if a value is sent across a RPC
interface?
Also what if I want a thread-local variable?
Well actually I would say that threads are bad concurrency model so
I'm not keen on thread local state at all. Mainly because I'd like to
get rid of threads, but also a few other doubts even if we keep
threads.
Even if you don't like them, people still use them.
(I.E. Just making existing practice *safe*, at least in the sense that
the compiler ain't gonna fcuk it up with INLINING or CSE and every one
understands what is and isn't safe in ACIO)
Creating new language features means defining their semantics rather
more clearly than just "no inlining or cse", IMO.
Ganesh
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
