Re: [m-users.] Two more predicates for dealing wih threads

Am Montag, dem 06.11.2023 um 10:31 +0000 schrieb Sean Charles
(emacstheviking):
> YAGNI!

That's not the right philosophy for the standard libraries of a programming
language.

> 
> I have not used Haskell in the years since I began my Mercury journey TBH!

I'm also mainly using Mercury since I've learned it. I still do my shell
scripting in Haskell, though. I'm the author of the HsShellScript library
for Haskell, which I've written for that purpose.

> 
> > On 6 Nov 2023, at 10:29, Volker Wysk <[email protected]> wrote:
> > 
> > Am Montag, dem 06.11.2023 um 18:01 +1100 schrieb Peter Wang:
> > > On Mon, 06 Nov 2023 05:23:03 +0100 Volker Wysk <[email protected]> wrote:
> > > > Am Montag, dem 06.11.2023 um 14:28 +1300 schrieb Richard O'Keefe:
> > > > > 
> > > > > Surely a lighter-weight thread.channel is possible and desirable?
> > > > 
> > > > I don't know if it's possible, but 2N+4 semaphores sounds really heavy...
> > > > 
> > > 
> > > thread.channel was "inspired" by Tackling the Awkward Squad
> > > https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/mark.pdf
> > 
> > This looks interesting. (I also am a Haskell programmer).
> > 
> > > 
> > > IIRC what makes thread.channel hard to implement another way is the
> > > "duplicate" operation. I've never needed to duplicate a channel, though.
> > > Also, comparing channel.take to readChan in the GHC implementation shows
> > > that duplicated channels in Mercury never worked in the way they were
> > > intended, as broadcast channels. (The bug was present in the code in the
> > > original paper.)
> > > https://github.com/ghc/ghc/blob/e451139f7a97d219ed8630b054d3a0875037aa0c/libraries/base/src/Control/Concurrent/Chan.hs#L110
> > > 
> > > If we dropped "duplicate", it should be possible to create a lighter
> > > implementation of thread.channel. I still don't think it will be that
> > > straightforward using semaphores (as opposed to condition variables,
> > > which the Mercury standard library doesn't have).
> > 
> > Hmmm.. Perhaps this could be done? (But I don't need it right now.)
> > 
> > Cheers,
> > Volker
> > _______________________________________________
> > users mailing list
> > [email protected]
> > https://lists.mercurylang.org/listinfo/users
> 

_______________________________________________
users mailing list
[email protected]
https://lists.mercurylang.org/listinfo/users