Generalize filterM to Applicative

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Generalize filterM to Applicative

David Feuer
Currently,

filterM          :: (Monad m) => (a -> m Bool) -> [a] -> m [a]
filterM p        = foldr go (return [])
  where
    go x r = do
      flg <- p x
      ys <- r
      return (if flg then x:ys else ys)


We could change this to


filterM :: (Applicative f) => (a -> f Bool) -> [a] -> f [a]
filterM p = foldr go (pure [])
  where
    go x r = f <$> p x <*> r
       where
          f flg ys = if flg then x:ys else ys
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Generalize filterM to Applicative

Yitzchak Gale
David Feuer wrote:
> filterM          :: (Monad m) => (a -> m Bool) -> [a] -> m [a]
> We could change this to
> filterM :: (Applicative f) => (a -> f Bool) -> [a] -> f [a]

Following the usual conventions, that should be filterA.

And I'm not sure where it should go. We could also
generalize the list parameter to a Foldable and put
it in Data.Foldable, but I don't think that would be
very useful, since in the end it anyway returns a list.

We could add a new "Filterable" class, but that's also
probably not too useful for anything not list-like. For
example, Data.Tree has two useful filters, filterGraft
and filterPrune.

So maybe it should go in Control.Applicative? Not very
satisfying. Any ideas?

As for the fate of the name filterM:

Personally, I would want filterM to remain a convenient
type-specialized version for monads. But recent madness
would turn it into yet another unsightly overly polymorphic
namespace wasting synonym for filterA.

Thanks,
Yitz
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Generalize filterM to Applicative

David Feuer
In a departure from the filterM tradition, I think if we add a filterA
for lists then it should go in Data.List. That way, we can have a
different filterA in Data.Sequence, etc. The A makes it Applicative
already; the rest seems tied to the container.

On Sun, Dec 28, 2014 at 1:14 PM, Yitzchak Gale <[hidden email]> wrote:

> David Feuer wrote:
>> filterM          :: (Monad m) => (a -> m Bool) -> [a] -> m [a]
>> We could change this to
>> filterM :: (Applicative f) => (a -> f Bool) -> [a] -> f [a]
>
> Following the usual conventions, that should be filterA.
>
> And I'm not sure where it should go. We could also
> generalize the list parameter to a Foldable and put
> it in Data.Foldable, but I don't think that would be
> very useful, since in the end it anyway returns a list.
>
> We could add a new "Filterable" class, but that's also
> probably not too useful for anything not list-like. For
> example, Data.Tree has two useful filters, filterGraft
> and filterPrune.
>
> So maybe it should go in Control.Applicative? Not very
> satisfying. Any ideas?
>
> As for the fate of the name filterM:
>
> Personally, I would want filterM to remain a convenient
> type-specialized version for monads. But recent madness
> would turn it into yet another unsightly overly polymorphic
> namespace wasting synonym for filterA.
>
> Thanks,
> Yitz
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Generalize filterM to Applicative

Edward Kmett-2
In reply to this post by Yitzchak Gale
The way we've been doing things so far is to just generalize the existing signature and keep the existing name.

This avoids needless name proliferation and keeping needlessly over-constrained versions of code lying around.

FWIW- I have no objection to a more general filterM.

-Edward

On Sun, Dec 28, 2014 at 1:14 PM, Yitzchak Gale <[hidden email]> wrote:
David Feuer wrote:
> filterM          :: (Monad m) => (a -> m Bool) -> [a] -> m [a]
> We could change this to
> filterM :: (Applicative f) => (a -> f Bool) -> [a] -> f [a]

Following the usual conventions, that should be filterA.

And I'm not sure where it should go. We could also
generalize the list parameter to a Foldable and put
it in Data.Foldable, but I don't think that would be
very useful, since in the end it anyway returns a list.

We could add a new "Filterable" class, but that's also
probably not too useful for anything not list-like. For
example, Data.Tree has two useful filters, filterGraft
and filterPrune.

So maybe it should go in Control.Applicative? Not very
satisfying. Any ideas?

As for the fate of the name filterM:

Personally, I would want filterM to remain a convenient
type-specialized version for monads. But recent madness
would turn it into yet another unsightly overly polymorphic
namespace wasting synonym for filterA.

Thanks,
Yitz
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Generalize filterM to Applicative

Andreas Abel
+1 generalize filterM to Applicative.

I am not fond of ...A functions if the ...M functions can be generalized
to Applicative, so -1 on filterA.

On 29.12.2014 00:15, Edward Kmett wrote:

> The way we've been doing things so far is to just generalize the
> existing signature and keep the existing name.
>
> This avoids needless name proliferation and keeping needlessly
> over-constrained versions of code lying around.
>
> FWIW- I have no objection to a more general filterM.
>
> -Edward
>
> On Sun, Dec 28, 2014 at 1:14 PM, Yitzchak Gale <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     David Feuer wrote:
>     > filterM          :: (Monad m) => (a -> m Bool) -> [a] -> m [a]
>     > We could change this to
>     > filterM :: (Applicative f) => (a -> f Bool) -> [a] -> f [a]
>
>     Following the usual conventions, that should be filterA.
>
>     And I'm not sure where it should go. We could also
>     generalize the list parameter to a Foldable and put
>     it in Data.Foldable, but I don't think that would be
>     very useful, since in the end it anyway returns a list.
>
>     We could add a new "Filterable" class, but that's also
>     probably not too useful for anything not list-like. For
>     example, Data.Tree has two useful filters, filterGraft
>     and filterPrune.
>
>     So maybe it should go in Control.Applicative? Not very
>     satisfying. Any ideas?
>
>     As for the fate of the name filterM:
>
>     Personally, I would want filterM to remain a convenient
>     type-specialized version for monads. But recent madness
>     would turn it into yet another unsightly overly polymorphic
>     namespace wasting synonym for filterA.
>
>     Thanks,
>     Yitz
>     _______________________________________________
>     Libraries mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://www.haskell.org/mailman/listinfo/libraries
>
>
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>


--
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Generalize filterM to Applicative

Edward Kmett-2
In reply to this post by Yitzchak Gale
Personally, I would want filterM to remain a convenient
type-specialized version for monads. But recent madness
would turn it into yet another unsightly overly polymorphic
namespace wasting synonym for filterA.

What would be gained for having a crippled version of filterM that only worked for monads, but didn't use any of the additional power gained by that constraint? 

To borrow from John Maynard Keynes: "When the facts change, I change my mind. What do you do, sir?" =)

Is it "madness" to want to avoid namespace proliferation and maximize the usefulness of an existing combinator now that the constraints that forged it have changed to allow it to be slightly more permissive?

-Edward

On Sun, Dec 28, 2014 at 1:14 PM, Yitzchak Gale <[hidden email]> wrote:
David Feuer wrote:
> filterM          :: (Monad m) => (a -> m Bool) -> [a] -> m [a]
> We could change this to
> filterM :: (Applicative f) => (a -> f Bool) -> [a] -> f [a]

Following the usual conventions, that should be filterA.

And I'm not sure where it should go. We could also
generalize the list parameter to a Foldable and put
it in Data.Foldable, but I don't think that would be
very useful, since in the end it anyway returns a list.

We could add a new "Filterable" class, but that's also
probably not too useful for anything not list-like. For
example, Data.Tree has two useful filters, filterGraft
and filterPrune.

So maybe it should go in Control.Applicative? Not very
satisfying. Any ideas?

As for the fate of the name filterM:

Personally, I would want filterM to remain a convenient
type-specialized version for monads. But recent madness
would turn it into yet another unsightly overly polymorphic
namespace wasting synonym for filterA.

Thanks,
Yitz
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Generalize filterM to Applicative

Kim-Ee Yeoh
Administrator

On Mon, Dec 29, 2014 at 7:58 PM, Edward Kmett <[hidden email]> wrote:
Is it "madness" to want to avoid namespace proliferation and maximize the usefulness of an existing combinator now that the constraints that forged it have changed to allow it to be slightly more permissive?

Madness is such strong language for this august list.

May I speak on behalf of haskell newcomers for a time?

Haskell places such an emphasis on uniformity and regularity. Functions with names that end with M once meant they were monadic variants of those that don't. That's no longer uniformly the case, because of the FAM restructuring.

The names of functions matter.

Anachronistic labels confuse.

Leaving filterM with a type signature of Applicative cannot be the long-term solution.

-- Kim-Ee

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Generalize filterM to Applicative

Andreas Abel
Or you can widen the interpretation of suffix ...M as "effectful", which
could be a monadic or applicative effect.

On 29.12.2014 16:50, Kim-Ee Yeoh wrote:

>
> On Mon, Dec 29, 2014 at 7:58 PM, Edward Kmett <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Is it "madness" to want to avoid namespace proliferation and
>     maximize the usefulness of an existing combinator now that the
>     constraints that forged it have changed to allow it to be slightly
>     more permissive?
>
>
> Madness is such strong language for this august list.
>
> May I speak on behalf of haskell newcomers for a time?
>
> Haskell places such an emphasis on uniformity and regularity. Functions
> with names that end with M once meant they were monadic variants of
> those that don't. That's no longer uniformly the case, because of the
> FAM restructuring.
>
> The names of functions matter.
>
> Anachronistic labels confuse.
>
> Leaving filterM with a type signature of Applicative cannot be the
> long-term solution.
>
> -- Kim-Ee
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>


--
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Generalize filterM to Applicative

Edward Kmett-2
I think this is the interpretation I think we're probably best left with.

I agree that names matter and that anachronistic labels confuse, but I think it is the lesser of evils to widen the definition of the 'M' suffix than it is to double up on almost all the names taken in the environment and force the entire community to go through a positively gigantic deprecation cycle.

-Edward

On Mon, Dec 29, 2014 at 1:31 PM, Andreas Abel <[hidden email]> wrote:
Or you can widen the interpretation of suffix ...M as "effectful", which could be a monadic or applicative effect.

On 29.12.2014 16:50, Kim-Ee Yeoh wrote:

On Mon, Dec 29, 2014 at 7:58 PM, Edward Kmett <[hidden email]
<mailto:[hidden email]>> wrote:

    Is it "madness" to want to avoid namespace proliferation and
    maximize the usefulness of an existing combinator now that the
    constraints that forged it have changed to allow it to be slightly
    more permissive?


Madness is such strong language for this august list.

May I speak on behalf of haskell newcomers for a time?

Haskell places such an emphasis on uniformity and regularity. Functions
with names that end with M once meant they were monadic variants of
those that don't. That's no longer uniformly the case, because of the
FAM restructuring.

The names of functions matter.

Anachronistic labels confuse.

Leaving filterM with a type signature of Applicative cannot be the
long-term solution.

-- Kim-Ee


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries



--
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Generalize filterM to Applicative

David Feuer
I realized just now that we can actually make the type a little bit
more general still, interpreting `filterM` for lists as being an
applicative filter *producing* lists:

filterM :: (Applicative f, Foldable t) => (a -> f Bool) -> t a -> f [a]



On Mon, Dec 29, 2014 at 3:17 PM, Edward Kmett <[hidden email]> wrote:

> I think this is the interpretation I think we're probably best left with.
>
> I agree that names matter and that anachronistic labels confuse, but I think
> it is the lesser of evils to widen the definition of the 'M' suffix than it
> is to double up on almost all the names taken in the environment and force
> the entire community to go through a positively gigantic deprecation cycle.
>
> -Edward
>
> On Mon, Dec 29, 2014 at 1:31 PM, Andreas Abel <[hidden email]>
> wrote:
>>
>> Or you can widen the interpretation of suffix ...M as "effectful", which
>> could be a monadic or applicative effect.
>>
>> On 29.12.2014 16:50, Kim-Ee Yeoh wrote:
>>>
>>>
>>> On Mon, Dec 29, 2014 at 7:58 PM, Edward Kmett <[hidden email]
>>> <mailto:[hidden email]>> wrote:
>>>
>>>     Is it "madness" to want to avoid namespace proliferation and
>>>     maximize the usefulness of an existing combinator now that the
>>>     constraints that forged it have changed to allow it to be slightly
>>>     more permissive?
>>>
>>>
>>> Madness is such strong language for this august list.
>>>
>>> May I speak on behalf of haskell newcomers for a time?
>>>
>>> Haskell places such an emphasis on uniformity and regularity. Functions
>>> with names that end with M once meant they were monadic variants of
>>> those that don't. That's no longer uniformly the case, because of the
>>> FAM restructuring.
>>>
>>> The names of functions matter.
>>>
>>> Anachronistic labels confuse.
>>>
>>> Leaving filterM with a type signature of Applicative cannot be the
>>> long-term solution.
>>>
>>> -- Kim-Ee
>>>
>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> [hidden email]
>>> http://www.haskell.org/mailman/listinfo/libraries
>>>
>>
>>
>> --
>> Andreas Abel  <><      Du bist der geliebte Mensch.
>>
>> Department of Computer Science and Engineering
>> Chalmers and Gothenburg University, Sweden
>>
>> [hidden email]
>> http://www2.tcs.ifi.lmu.de/~abel/
>
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Generalize filterM to Applicative

Mario Blažević
On 14-12-30 12:34 PM, David Feuer wrote:
> I realized just now that we can actually make the type a little bit
> more general still, interpreting `filterM` for lists as being an
> applicative filter *producing* lists:
>
> filterM :: (Applicative f, Foldable t) => (a -> f Bool) -> t a -> f [a]

        I'm +1 on the more limited generalization proposal, but not on this
one. I've been feeling for a while that we need a subclass of
Traversable to generalize functions like filter, mapMaybe, and partition
(potentially span, splitAt and others as well). If you call this missing
class Filterable, the properly-generalized signature would be

 > filterM :: (Applicative f, Filterable t) =>
 > (a -> f Bool) -> t a -> f (t a)



>
> On Mon, Dec 29, 2014 at 3:17 PM, Edward Kmett <[hidden email]> wrote:
>> I think this is the interpretation I think we're probably best left with.
>>
>> I agree that names matter and that anachronistic labels confuse, but I think
>> it is the lesser of evils to widen the definition of the 'M' suffix than it
>> is to double up on almost all the names taken in the environment and force
>> the entire community to go through a positively gigantic deprecation cycle.
>>
>> -Edward
>>
>> On Mon, Dec 29, 2014 at 1:31 PM, Andreas Abel <[hidden email]>
>> wrote:
>>>
>>> Or you can widen the interpretation of suffix ...M as "effectful", which
>>> could be a monadic or applicative effect.
>>>
>>> On 29.12.2014 16:50, Kim-Ee Yeoh wrote:
>>>>
>>>>
>>>> On Mon, Dec 29, 2014 at 7:58 PM, Edward Kmett <[hidden email]
>>>> <mailto:[hidden email]>> wrote:
>>>>
>>>>      Is it "madness" to want to avoid namespace proliferation and
>>>>      maximize the usefulness of an existing combinator now that the
>>>>      constraints that forged it have changed to allow it to be slightly
>>>>      more permissive?
>>>>
>>>>
>>>> Madness is such strong language for this august list.
>>>>
>>>> May I speak on behalf of haskell newcomers for a time?
>>>>
>>>> Haskell places such an emphasis on uniformity and regularity. Functions
>>>> with names that end with M once meant they were monadic variants of
>>>> those that don't. That's no longer uniformly the case, because of the
>>>> FAM restructuring.
>>>>
>>>> The names of functions matter.
>>>>
>>>> Anachronistic labels confuse.
>>>>
>>>> Leaving filterM with a type signature of Applicative cannot be the
>>>> long-term solution.
>>>>
>>>> -- Kim-Ee
>>>>
>>>>
>>>> _______________________________________________
>>>> Libraries mailing list
>>>> [hidden email]
>>>> http://www.haskell.org/mailman/listinfo/libraries
>>>>
>>>
>>>
>>> --
>>> Andreas Abel  <><      Du bist der geliebte Mensch.
>>>
>>> Department of Computer Science and Engineering
>>> Chalmers and Gothenburg University, Sweden
>>>
>>> [hidden email]
>>> http://www2.tcs.ifi.lmu.de/~abel/
>>
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/libraries
>>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>


--
Mario Blazevic
[hidden email]
Stilo International

This message, including any attachments, is for the sole use of the
intended recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure, copying, or
distribution is strictly prohibited. If you are not the intended
recipient(s) please contact the sender by reply email and destroy
all copies of the original message and any attachments.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Generalize filterM to Applicative

htebalaka
This post has NOT been accepted by the mailing list yet.
In reply to this post by David Feuer
That seems rather ad-hoc personally. I'd find something like `\f -> filterM f . toList` to be clearer.

But anyway, inconsistent names confuse, but my personal experience is duplicate functions have confused me more.
David Feuer wrote
I realized just now that we can actually make the type a little bit
more general still, interpreting `filterM` for lists as being an
applicative filter *producing* lists:

filterM :: (Applicative f, Foldable t) => (a -> f Bool) -> t a -> f [a]



On Mon, Dec 29, 2014 at 3:17 PM, Edward Kmett <[hidden email]> wrote:
> I think this is the interpretation I think we're probably best left with.
>
> I agree that names matter and that anachronistic labels confuse, but I think
> it is the lesser of evils to widen the definition of the 'M' suffix than it
> is to double up on almost all the names taken in the environment and force
> the entire community to go through a positively gigantic deprecation cycle.
>
> -Edward
>
> On Mon, Dec 29, 2014 at 1:31 PM, Andreas Abel <[hidden email]>
> wrote:
>>
>> Or you can widen the interpretation of suffix ...M as "effectful", which
>> could be a monadic or applicative effect.
>>
>> On 29.12.2014 16:50, Kim-Ee Yeoh wrote:
>>>
>>>
>>> On Mon, Dec 29, 2014 at 7:58 PM, Edward Kmett <[hidden email]
>>> <mailto:[hidden email]>> wrote:
>>>
>>>     Is it "madness" to want to avoid namespace proliferation and
>>>     maximize the usefulness of an existing combinator now that the
>>>     constraints that forged it have changed to allow it to be slightly
>>>     more permissive?
>>>
>>>
>>> Madness is such strong language for this august list.
>>>
>>> May I speak on behalf of haskell newcomers for a time?
>>>
>>> Haskell places such an emphasis on uniformity and regularity. Functions
>>> with names that end with M once meant they were monadic variants of
>>> those that don't. That's no longer uniformly the case, because of the
>>> FAM restructuring.
>>>
>>> The names of functions matter.
>>>
>>> Anachronistic labels confuse.
>>>
>>> Leaving filterM with a type signature of Applicative cannot be the
>>> long-term solution.
>>>
>>> -- Kim-Ee
>>>
>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> [hidden email]
>>> http://www.haskell.org/mailman/listinfo/libraries
>>>
>>
>>
>> --
>> Andreas Abel  <><      Du bist der geliebte Mensch.
>>
>> Department of Computer Science and Engineering
>> Chalmers and Gothenburg University, Sweden
>>
>> [hidden email]
>> http://www2.tcs.ifi.lmu.de/~abel/
>
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Generalize filterM to Applicative

M Farkas-Dyck
In reply to this post by Mario Blažević
On 05/01/2015 at 11:53:11 -0500, Mario Blažević wrote:

> On 14-12-30 12:34 PM, David Feuer wrote:
> >I realized just now that we can actually make the type a little bit
> >more general still, interpreting `filterM` for lists as being an
> >applicative filter *producing* lists:
> >
> >filterM :: (Applicative f, Foldable t) => (a -> f Bool) -> t a -> f [a]
>
> I'm +1 on the more limited generalization proposal, but not on this one.
> I've been feeling for a while that we need a subclass of Traversable to
> generalize functions like filter, mapMaybe, and partition (potentially span,
> splitAt and others as well). If you call this missing class Filterable, the
> properly-generalized signature would be
>
> > filterM :: (Applicative f, Filterable t) =>
> > (a -> f Bool) -> t a -> f (t a)

https://hackage.haskell.org/package/witherable

Interesting name choice...
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Generalize filterM to Applicative

M Farkas-Dyck
On 25/03/2015 at 15:06:47 -0500, M Farkas-Dyck wrote:
> https://hackage.haskell.org/package/witherable
>
> Interesting name choice...

This has superclass Traversable tho, which is not needed as

wither f xs = catMaybes <$> traverse f xs
filterA f = mapMaybeA (\ x -> (x <$) . guard <$> f x)
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries