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

[Dan Weston]

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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 
>