Maxime Henrion | 14 Dec 17:14
Favicon

Proposal: Add variants of tails & inits not returning empty lists

	Hi all,

I just opened a Trac ticket (#1979), to suggest the addition of the
inits1 and tails1 functions, which don't return empty lists unlike
their counterpart.  They're defined as such :

inits1 = tail . inits
tails1 = init . tails

I've needed them a few times so I thought they would make a nice
addition to the base package.  And, I've got to say, the symmetry
in this code is is nice :-).

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

Cheers,
Maxime
Bulat Ziganshin | 14 Dec 17:34

Re: Proposal: Add variants of tails & inits not returning empty lists

Hello Maxime,

Friday, December 14, 2007, 7:17:38 PM, you wrote:

> I just opened a Trac ticket (#1979), to suggest the addition of the

i have dozens of small funcs in my Utils.hs file. every experienced
Haskeller has such set. are all these functions should be really added
too?

--

-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin <at> gmail.com
Juanma Barranquero | 14 Dec 17:56

Re: Proposal: Add variants of tails & inits not returning empty lists

On Dec 14, 2007 5:34 PM, Bulat Ziganshin <bulat.ziganshin <at> gmail.com> wrote:

> i have dozens of small funcs in my Utils.hs file. every experienced
> Haskeller has such set. are all these functions should be really added
> too?

Yes, if there is a lot of overlay in every experienced haskeller's set
of small utility funcs :)

             Juanma
Maxime Henrion | 14 Dec 20:53
Favicon

Re: Proposal: Add variants of tails & inits not returning empty lists

Bulat Ziganshin wrote:
> Hello Maxime,
> 
> Friday, December 14, 2007, 7:17:38 PM, you wrote:
> 
> > I just opened a Trac ticket (#1979), to suggest the addition of the
> 
> i have dozens of small funcs in my Utils.hs file. every experienced
> Haskeller has such set. are all these functions should be really added
> too?

I am entirely open to discussion about whether these two functions
are useful enough to fit in the base libraries or not.  I personally
feel that they are, seeing that I had to use them several times in
a relatively short period of time.  I thus expect that many others
have needed to write those functions as well.  This may very well
turn out to be a completely wrong :-).

I guess one step towards is the answer would be knowing if you ever
needed those functions?

Cheers,
Maxime
Bulat Ziganshin | 14 Dec 22:25

Re[2]: Proposal: Add variants of tails & inits not returning empty lists

Hello Maxime,

Friday, December 14, 2007, 10:53:26 PM, you wrote:

>> i have dozens of small funcs in my Utils.hs file. every experienced
>> Haskeller has such set. are all these functions should be really added
>> too?

> I am entirely open to discussion about whether these two functions

well, are you have other common functions that are used in many
projects? how many haskell code you've developed so much? are you plan
to propose to add to stdlib every function that you used "a few
times"?

--

-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin <at> gmail.com
Simon Marlow | 28 Jan 12:28

Re: Proposal: Add variants of tails & inits not returning empty lists

Maxime Henrion wrote:
> Bulat Ziganshin wrote:
>> Hello Maxime,
>>
>> Friday, December 14, 2007, 7:17:38 PM, you wrote:
>>
>>> I just opened a Trac ticket (#1979), to suggest the addition of the
>> i have dozens of small funcs in my Utils.hs file. every experienced
>> Haskeller has such set. are all these functions should be really added
>> too?
> 
> I am entirely open to discussion about whether these two functions
> are useful enough to fit in the base libraries or not.  I personally
> feel that they are, seeing that I had to use them several times in
> a relatively short period of time.  I thus expect that many others
> have needed to write those functions as well.  This may very well
> turn out to be a completely wrong :-).
> 
> I guess one step towards is the answer would be knowing if you ever
> needed those functions?

For proposals like this, I think we need a significant number of people 
saying "yes please!", otherwise the default is for the code to go in 
without much discussion, and if we're not careful we end up adding things 
that are rarely useful.

My data point: I've never used/needed inits1 or tails1, AFAIR, and I don't 
think "tail.inits" is too hard to write, so I vote against.

Cheers,
(Continue reading)

Neil Mitchell | 28 Jan 12:44

Re: Proposal: Add variants of tails & inits not returning empty lists

Hi

> For proposals like this, I think we need a significant number of people
> saying "yes please!", otherwise the default is for the code to go in
> without much discussion, and if we're not careful we end up adding things
> that are rarely useful.
>
> My data point: I've never used/needed inits1 or tails1, AFAIR, and I don't
> think "tail.inits" is too hard to write, so I vote against.

I vote against, unless new names can be found which give a more
instant connection to the meaning. (I kind of said this in my original
post, but should be a bit clearer I guess)

Thanks

Neil
John Meacham | 28 Jan 21:46
Favicon

Re: Proposal: Add variants of tails & inits not returning empty lists

On Mon, Jan 28, 2008 at 11:28:23AM +0000, Simon Marlow wrote:
> For proposals like this, I think we need a significant number of people 
> saying "yes please!", otherwise the default is for the code to go in 
> without much discussion, and if we're not careful we end up adding things 
> that are rarely useful.

Maybe some sort of quorum is needed. Like, some percentage of interested
parties must make their feelings known before a final decision is made.
Or the default should be 'no' on new additions unless a lot of people
chime in saying yes.

        John

--

-- 
John Meacham - ⑆repetae.net⑆john⑈
Lennart Augustsson | 1 Feb 00:33
Favicon

Re: Proposal: Add variants of tails & inits not returning empty lists

I've never needed them.  So, no thanks.

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Neil Mitchell | 15 Dec 17:13

Re: Proposal: Add variants of tails & inits not returning empty lists

Hi Maxime,

> inits1 = tail . inits
> tails1 = init . tails

They look useful, and I have used ones like these before. However, the
name is slightly misleading. foldr1 and foldl1 don't "not return the
empty list", but both crash if given the empty list. These ones do
something very similar and very different from the other ...1
functions, so giving them similar names might result in confusion.
That said, I can't think of anything better.

Thanks

Neil
Maxime Henrion | 19 Dec 16:06
Favicon

Re: Proposal: Add variants of tails & inits not returning empty lists

Neil Mitchell wrote:
> Hi Maxime,
> 
> > inits1 = tail . inits
> > tails1 = init . tails
> 
> They look useful, and I have used ones like these before. However, the
> name is slightly misleading. foldr1 and foldl1 don't "not return the
> empty list", but both crash if given the empty list. These ones do
> something very similar and very different from the other ...1
> functions, so giving them similar names might result in confusion.
> That said, I can't think of anything better.

Yeah, I agree those names aren't great and could lead to confusion.
I have thought about calling them tails' and inits' but I think
that would be worse, since the trailing single quote is used to
indicate a more strict version most of the time and this has nothing
to do with strictness.

At least the tails1 and inits1 names carry the same "non-empty list"
concept as foldl1 and foldr1, although in a different sense.

Anyone has any better suggestion?

Cheers,
Maxime

Gmane