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

YAGNI was aimed at:  "(But I don't need it right now.)"

I might have even used that library once, rings bells! Well, when you emit a U+0007 it does ;)


> On 6 Nov 2023, at 10:42, Volker Wysk <[email protected]> wrote:
> 
> 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] <mailto:[email protected]>
> https://lists.mercurylang.org/listinfo/users

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