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

Reply via email to