[Haskell-cafe] Re: [Haskell] Top Level <-

Ganesh Sittampalam ganesh at earth.li
Fri Aug 29 18:52:37 EDT 2008

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 

>> 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.


More information about the Haskell-Cafe mailing list