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
