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

[Ganesh Sittampalam]

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