unicode was: Re: Stop using "Int" for microsecond delays in "base"
Christian.Maeder at dfki.de
Mon Mar 28 10:35:34 CEST 2011
Am 27.03.2011 11:17, schrieb Bas van Dijk:
> On 27 March 2011 07:59, Edward Kmett<ekmett at gmail.com> wrote:
>> On Sat, Mar 26, 2011 at 3:44 PM, Bas van Dijk<v.dijk.bas at gmail.com> wrote:
>>> Or take the one from concurrent-extra:
>> I'll admit the main problem that I have with the threadDelay in
>> concurrent-extra is the gratuitously unicode source file.
>> I wound up having to reimplement it inside a library of mine to avoid adding
>> a dependency on that extension and the unrelated dependency on stm. =(
>> (Technically, I implemented it directly first, then found concurrent-extra
>> and wasn't willing to refactor to use yours as a result of those.)
>> You are of course free to implement things as you see fit, but little things
>> like that do impact adoption.
> Note that 'delay' uses the 'threadDelay' function internally. AFAIK,
> this function is only supported in GHC. So to build the module you
> need GHC anyway which already supports the UnicodeSyntax language
> extension (since 6.12.1).
With this argument you should use many more ghc extensions. The
dependency on base-unicode-symbols is unfortunate, too!
If this dependency was supposed to advertise your base-unicode-symbols
package I consider this dependency as spam. Basic coding style should
> I do agree that the dependency on stm is unfortunate. I will see if I
> can put the modules Control.Concurrent.Thread.Delay and
> Control.Concurrent.Timeout into a separate package. Any naming
> suggestions? unbounded-delays or something?
More information about the Libraries