Mikhail Vorozhtsov | 2 Apr 11:42 2012
Picon

Proposal: unsnoc, unsafeInit and unsafeLast for the bytestring library

Hi.

I propose to add the missing counterparts of `uncons` and 
`unsafeHead/Tail` functions to the bytestring library.

Discussion deadline: 2 weeks

The patch is attached.
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Michael Snoyman | 2 Apr 11:47 2012

Re: Proposal: unsnoc, unsafeInit and unsafeLast for the bytestring library

On Mon, Apr 2, 2012 at 12:42 PM, Mikhail Vorozhtsov
<mikhail.vorozhtsov <at> gmail.com> wrote:
> Hi.
>
> I propose to add the missing counterparts of `uncons` and `unsafeHead/Tail`
> functions to the bytestring library.
>
> Discussion deadline: 2 weeks
>
> The patch is attached.
>
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>

+1 on unsnoc in particular, I know I've been surprised a few times
that it's not there. I haven't specifically missed the other two, but
I agree that they should be added.

Michael
Simon Meier | 3 Apr 14:35 2012
Picon

Re: Proposal: unsnoc, unsafeInit and unsafeLast for the bytestring library

Hi Mikhail,

I've never used these functions in my code. So I cannot judge their
usefulness. Having inspected your patch, I see the following points
for optimization:

1. The clarity of the code of Data.ByteString.unsnoc would profit from
using your 'unsafeInit and unsafeLast' functions.

2. It might well be that some other places could profit from your
'unsafeInit' and 'unsafeLast' functions; e.g., the 'init' and 'last'
functions. It would be great if you also updated other related
definitions.

3. The implementation of Data.ByteString.Lazy.unsnoc is too strict in
my opinion. I would expect it to return 'Just
<combined-init-and-last-computation>', as soon as it has proven that
the ByteString is non-empty. To avoid unnecessary code duplication, it
might make sense to inline only the wrapper and let GHC decide what it
wants to do for the actual worker.

best regards,
Simon

2012/4/2 Mikhail Vorozhtsov <mikhail.vorozhtsov <at> gmail.com>:
> Hi.
>
> I propose to add the missing counterparts of `uncons` and `unsafeHead/Tail`
> functions to the bytestring library.
>
(Continue reading)

Duncan Coutts | 3 Apr 15:00 2012

Re: Proposal: unsnoc, unsafeInit and unsafeLast for the bytestring library

On 3 April 2012 13:35, Simon Meier <iridcode <at> gmail.com> wrote:
> Hi Mikhail,
>
> I've never used these functions in my code. So I cannot judge their
> usefulness. Having inspected your patch, I see the following points
> for optimization:

> 3. The implementation of Data.ByteString.Lazy.unsnoc is too strict in
> my opinion. I would expect it to return 'Just
> <combined-init-and-last-computation>', as soon as it has proven that
> the ByteString is non-empty. To avoid unnecessary code duplication, it
> might make sense to inline only the wrapper and let GHC decide what it
> wants to do for the actual worker.

Actually, I think it doesn't make sense to provdide unsnoc for lazy
bytestring at all. It's a bit of a silly operation for lazy
bytestrings for the same reason as for lists. It's reasonable for
strict bytestrings because you have the same access to the end of the
string as the beginning, but the same is not true of lazy bytestrings.

Duncan
Mikhail Vorozhtsov | 3 Apr 15:40 2012
Picon

Re: Proposal: unsnoc, unsafeInit and unsafeLast for the bytestring library

On 04/03/2012 07:35 PM, Simon Meier wrote:
> Hi Mikhail,
>
> I've never used these functions in my code. So I cannot judge their
> usefulness. Having inspected your patch, I see the following points
> for optimization:
>
> 1. The clarity of the code of Data.ByteString.unsnoc would profit from
> using your 'unsafeInit and unsafeLast' functions.
The same can be said about `uncons`. `unsnoc` is pretty much a product 
of copy-and-paste.

> 2. It might well be that some other places could profit from your
> 'unsafeInit' and 'unsafeLast' functions; e.g., the 'init' and 'last'
> functions. It would be great if you also updated other related
> definitions.
Good point. I updated the patch.

> 3. The implementation of Data.ByteString.Lazy.unsnoc is too strict in
> my opinion. I would expect it to return 'Just
> <combined-init-and-last-computation>', as soon as it has proven that
> the ByteString is non-empty. To avoid unnecessary code duplication, it
> might make sense to inline only the wrapper and let GHC decide what it
> wants to do for the actual worker.
Done. Thanks for the review!
_______________________________________________
Libraries mailing list
(Continue reading)

Simon Meier | 3 Apr 15:50 2012
Picon

Re: Proposal: unsnoc, unsafeInit and unsafeLast for the bytestring library

2012/4/3 Duncan Coutts <duncan.coutts <at> googlemail.com>:
> On 3 April 2012 13:35, Simon Meier <iridcode <at> gmail.com> wrote:
>> Hi Mikhail,
>>
>> I've never used these functions in my code. So I cannot judge their
>> usefulness. Having inspected your patch, I see the following points
>> for optimization:
>
>> 3. The implementation of Data.ByteString.Lazy.unsnoc is too strict in
>> my opinion. I would expect it to return 'Just
>> <combined-init-and-last-computation>', as soon as it has proven that
>> the ByteString is non-empty. To avoid unnecessary code duplication, it
>> might make sense to inline only the wrapper and let GHC decide what it
>> wants to do for the actual worker.
>
> Actually, I think it doesn't make sense to provdide unsnoc for lazy
> bytestring at all. It's a bit of a silly operation for lazy
> bytestrings for the same reason as for lists. It's reasonable for
> strict bytestrings because you have the same access to the end of the
> string as the beginning, but the same is not true of lazy bytestrings.

I agree. I don't see a usecase for unsnoc on lazy bytestrings in
production code.

It nevertheless might make sense to provide it for one-off scripting
code and for interface consistency. The necessarily bad implementation
shows in the runtime given in the comment. Hence, I'd marginally vote
for inclusion of the lazy bytestring unsnoc.

 <at> mikkhail: Note that at least the runtime for
(Continue reading)

Ben Millwood | 3 Apr 16:35 2012
Picon

Re: Proposal: unsnoc, unsafeInit and unsafeLast for the bytestring library

On Tue, Apr 3, 2012 at 2:50 PM, Simon Meier <iridcode <at> gmail.com> wrote:
> 2012/4/3 Duncan Coutts <duncan.coutts <at> googlemail.com>:
>>
>> Actually, I think it doesn't make sense to provdide unsnoc for lazy
>> bytestring at all. It's a bit of a silly operation for lazy
>> bytestrings for the same reason as for lists. It's reasonable for
>> strict bytestrings because you have the same access to the end of the
>> string as the beginning, but the same is not true of lazy bytestrings.
>
> I agree. I don't see a usecase for unsnoc on lazy bytestrings in
> production code.
>
> It nevertheless might make sense to provide it for one-off scripting
> code and for interface consistency. The necessarily bad implementation
> shows in the runtime given in the comment. Hence, I'd marginally vote
> for inclusion of the lazy bytestring unsnoc.

Agreed on the interface consistency comment; also it's worth
remembering that what type of bytestring you use is sometimes the
choice of the library you want to work with, rather than yours :)

An explicit warning in the docs, maybe, but keep it in there nonetheless.

yrs,
Ben
Mikhail Vorozhtsov | 3 Apr 16:48 2012
Picon

Re: Proposal: unsnoc, unsafeInit and unsafeLast for the bytestring library

On 04/03/2012 08:50 PM, Simon Meier wrote:
> 2012/4/3 Duncan Coutts<duncan.coutts <at> googlemail.com>:
[snip]
>  <at> mikkhail: Note that at least the runtime for
> Data.ByteString.Lazy.Char8 is wrong. It should be O(n/c) instead of
> O(1).
Fixed.

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Mikhail Vorozhtsov | 3 Apr 16:51 2012
Picon

Re: Proposal: unsnoc, unsafeInit and unsafeLast for the bytestring library

On 04/03/2012 08:00 PM, Duncan Coutts wrote:
> On 3 April 2012 13:35, Simon Meier<iridcode <at> gmail.com>  wrote:
>> Hi Mikhail,
>>
>> I've never used these functions in my code. So I cannot judge their
>> usefulness. Having inspected your patch, I see the following points
>> for optimization:
>
>> 3. The implementation of Data.ByteString.Lazy.unsnoc is too strict in
>> my opinion. I would expect it to return 'Just
>> <combined-init-and-last-computation>', as soon as it has proven that
>> the ByteString is non-empty. To avoid unnecessary code duplication, it
>> might make sense to inline only the wrapper and let GHC decide what it
>> wants to do for the actual worker.
>
> Actually, I think it doesn't make sense to provdide unsnoc for lazy
> bytestring at all. It's a bit of a silly operation for lazy
> bytestrings for the same reason as for lists. It's reasonable for
> strict bytestrings because you have the same access to the end of the
> string as the beginning, but the same is not true of lazy bytestrings.
Hm, why `(,) <$> init <*> last` makes less sense than `init` and `last` 
themselves?
Evan Laforge | 4 Apr 21:34 2012
Picon

Re: Proposal: add clearEnv and setEnvironment to System.Posix.Env

While you're doing this, could you submit my patch from here:

http://hackage.haskell.org/trac/ghc/ticket/5930

I don't have permission, and I'd almost totally forgotten about it.

On Fri, Mar 30, 2012 at 8:07 AM, Paolo Capriotti <p.capriotti <at> gmail.com> wrote:
> On Fri, Mar 9, 2012 at 3:33 PM, Paolo Capriotti <p.capriotti <at> gmail.com> wrote:
>> Hi all,
>> System.Posix.Env doesn't currently define a binding for the POSIX
>> function clearenv. I propose to add:
>>
>> clearEnv :: IO ()
>> setEnvironment :: [(String, String)] -> IO ()
>>
>> 'clearEnv' is a direct wrapper for the underlying function, while
>> 'setEnvironment' is a higher-level utility function which mirrors the
>> interface of the existing 'getEnvironment'. See attached patches here:
>> http://hackage.haskell.org/trac/ghc/ticket/5648.
>>
>> Discussion deadline: 24 Mar 2012.
>
> We are past the deadline, so, if there are no objections, I'll go
> ahead and push my patches.
>
> BR,
> Paolo
>
> _______________________________________________
> Libraries mailing list
(Continue reading)


Gmane