Functional programming with GLib

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Functional programming with GLib

Dirk-Jan C. Binnema-2

Hi All,

A while back, I wrote some functions for functional-flavored programming
with GLib. It's fully documented[1], has tests, etc.

It would (for me at least) be useful to have some of these functions in
GLib-proper, but I suspect the GLib-maintainers are not /too/ eager to
accept contributions to GList... anyway, perhaps its useful for others.

As a simple example, suppose we want to calculate the sum of primes up
to 100 (a common task after all):

,----
| int    sum;
| GList *nums, *primes;
|
| nums   = gx_list_iota (100, 1, 1);
| primes = gx_list_filter (nums, (GXPred)gx_is_prime, NULL);
| sum    = gx_list_sum (primes); /* => 1060 */
|
| g_list_free (nums);
| g_list_free (primes);
`----

There's also folding, mapping etc. See a short article about this:
   http://www.djcbsoftware.nl/2015/10/04/functional-glists/
(2015?! time does fly). Am still developing it though.

Repo: https://github.com/djcb/gxlib
Docs: http://www.djcbsoftware.nl/code/gxlib/

Best wishes,
Dirk.

--
Dirk-Jan C. Binnema                  Helsinki, Finland
e:[hidden email]           w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Functional programming with GLib

Philip Withnall-2
Hey,

The general policy for GLib is that utility functions which are useful
(and used in) several projects are considered for being added to GLib.

To me, a functional programming approach using GLists is not something
which every project is going to use. Is there any harm in keeping it as
a separate library? There’s nothing stopping projects from linking to
GLib *and* GXLib. :-)

The command line parsing stuff you have looks a bit more widely
applicable. Were you considering merging those into GLib?

http://www.djcbsoftware.nl/code/gxlib/gxlib-Command-line-parsing.html

Anyway, nice work on GXLib. It looks well documented.

Philip

On Sun, 2017-04-23 at 21:46 +0300, Dirk-Jan C. Binnema wrote:

> Hi All,
>
> A while back, I wrote some functions for functional-flavored
> programming
> with GLib. It's fully documented[1], has tests, etc.
>
> It would (for me at least) be useful to have some of these functions
> in
> GLib-proper, but I suspect the GLib-maintainers are not /too/ eager
> to
> accept contributions to GList... anyway, perhaps its useful for
> others.
>
> As a simple example, suppose we want to calculate the sum of primes
> up
> to 100 (a common task after all):
>
> ,----
> > int    sum;
> > GList *nums, *primes;
> >
> > nums   = gx_list_iota (100, 1, 1);
> > primes = gx_list_filter (nums, (GXPred)gx_is_prime, NULL);
> > sum    = gx_list_sum (primes); /* => 1060 */
> >
> > g_list_free (nums);
> > g_list_free (primes);
>
> `----
>
> There's also folding, mapping etc. See a short article about this:
>    http://www.djcbsoftware.nl/2015/10/04/functional-glists/
> (2015?! time does fly). Am still developing it though.
>
> Repo: https://github.com/djcb/gxlib
> Docs: http://www.djcbsoftware.nl/code/gxlib/
>
> Best wishes,
> Dirk.
>
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Functional programming with GLib

Emmanuele Bassi
For command line parsing I'd actually favour a slightly bolder
approach of deprecating GOptionContext, and having something slightly
more modern — in terms of being bindable in other languages, and
well-integrated with API like GApplication.

For instance, something similar to [clap.rs][0].

Ciao,
 Emmanuele.

[0]: https://clap.rs/

On 27 April 2017 at 15:15, Philip Withnall <[hidden email]> wrote:

> Hey,
>
> The general policy for GLib is that utility functions which are useful
> (and used in) several projects are considered for being added to GLib.
>
> To me, a functional programming approach using GLists is not something
> which every project is going to use. Is there any harm in keeping it as
> a separate library? There’s nothing stopping projects from linking to
> GLib *and* GXLib. :-)
>
> The command line parsing stuff you have looks a bit more widely
> applicable. Were you considering merging those into GLib?
>
> http://www.djcbsoftware.nl/code/gxlib/gxlib-Command-line-parsing.html
>
> Anyway, nice work on GXLib. It looks well documented.
>
> Philip
>
> On Sun, 2017-04-23 at 21:46 +0300, Dirk-Jan C. Binnema wrote:
>> Hi All,
>>
>> A while back, I wrote some functions for functional-flavored
>> programming
>> with GLib. It's fully documented[1], has tests, etc.
>>
>> It would (for me at least) be useful to have some of these functions
>> in
>> GLib-proper, but I suspect the GLib-maintainers are not /too/ eager
>> to
>> accept contributions to GList... anyway, perhaps its useful for
>> others.
>>
>> As a simple example, suppose we want to calculate the sum of primes
>> up
>> to 100 (a common task after all):
>>
>> ,----
>> > int    sum;
>> > GList *nums, *primes;
>> >
>> > nums   = gx_list_iota (100, 1, 1);
>> > primes = gx_list_filter (nums, (GXPred)gx_is_prime, NULL);
>> > sum    = gx_list_sum (primes); /* => 1060 */
>> >
>> > g_list_free (nums);
>> > g_list_free (primes);
>>
>> `----
>>
>> There's also folding, mapping etc. See a short article about this:
>>    http://www.djcbsoftware.nl/2015/10/04/functional-glists/
>> (2015?! time does fly). Am still developing it though.
>>
>> Repo: https://github.com/djcb/gxlib
>> Docs: http://www.djcbsoftware.nl/code/gxlib/
>>
>> Best wishes,
>> Dirk.
>>
>
> _______________________________________________
> gtk-devel-list mailing list
> [hidden email]
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>



--
https://www.bassi.io
[@] ebassi [@gmail.com]
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Functional programming with GLib

Philip Withnall-2
I was thinking about that, but then fell into the trap of worrying
about suggesting it because someone might expect me to implement it.

I agree though; a reworking of GOptionContext which integrates better
with GApplication, supports sub-commands and supports custom argument
formats more easily would be lovely. Drawing inspiration from python-
argparse would also be good.

Philip

On Thu, 2017-04-27 at 15:29 +0100, Emmanuele Bassi wrote:

> For command line parsing I'd actually favour a slightly bolder
> approach of deprecating GOptionContext, and having something slightly
> more modern — in terms of being bindable in other languages, and
> well-integrated with API like GApplication.
>
> For instance, something similar to [clap.rs][0].
>
> Ciao,
>  Emmanuele.
>
> [0]: https://clap.rs/
>
> On 27 April 2017 at 15:15, Philip Withnall <[hidden email]>
> wrote:
> > Hey,
> >
> > The general policy for GLib is that utility functions which are
> > useful
> > (and used in) several projects are considered for being added to
> > GLib.
> >
> > To me, a functional programming approach using GLists is not
> > something
> > which every project is going to use. Is there any harm in keeping
> > it as
> > a separate library? There’s nothing stopping projects from linking
> > to
> > GLib *and* GXLib. :-)
> >
> > The command line parsing stuff you have looks a bit more widely
> > applicable. Were you considering merging those into GLib?
> >
> > http://www.djcbsoftware.nl/code/gxlib/gxlib-Command-line-parsing.ht
> > ml
> >
> > Anyway, nice work on GXLib. It looks well documented.
> >
> > Philip
> >
> > On Sun, 2017-04-23 at 21:46 +0300, Dirk-Jan C. Binnema wrote:
> > > Hi All,
> > >
> > > A while back, I wrote some functions for functional-flavored
> > > programming
> > > with GLib. It's fully documented[1], has tests, etc.
> > >
> > > It would (for me at least) be useful to have some of these
> > > functions
> > > in
> > > GLib-proper, but I suspect the GLib-maintainers are not /too/
> > > eager
> > > to
> > > accept contributions to GList... anyway, perhaps its useful for
> > > others.
> > >
> > > As a simple example, suppose we want to calculate the sum of
> > > primes
> > > up
> > > to 100 (a common task after all):
> > >
> > > ,----
> > > > int    sum;
> > > > GList *nums, *primes;
> > > >
> > > > nums   = gx_list_iota (100, 1, 1);
> > > > primes = gx_list_filter (nums, (GXPred)gx_is_prime, NULL);
> > > > sum    = gx_list_sum (primes); /* => 1060 */
> > > >
> > > > g_list_free (nums);
> > > > g_list_free (primes);
> > >
> > > `----
> > >
> > > There's also folding, mapping etc. See a short article about
> > > this:
> > >    http://www.djcbsoftware.nl/2015/10/04/functional-glists/
> > > (2015?! time does fly). Am still developing it though.
> > >
> > > Repo: https://github.com/djcb/gxlib
> > > Docs: http://www.djcbsoftware.nl/code/gxlib/
> > >
> > > Best wishes,
> > > Dirk.
> > >
> >
> > _______________________________________________
> > gtk-devel-list mailing list
> > [hidden email]
> > https://mail.gnome.org/mailman/listinfo/gtk-devel-list
> >
>
>
>
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Functional programming with GLib

Dirk-Jan C. Binnema-2
In reply to this post by Philip Withnall-2
Hi Philip,

On Thursday Apr 27 2017, Philip Withnall wrote:

> Hey,
>
> The general policy for GLib is that utility functions which are useful
> (and used in) several projects are considered for being added to GLib.
>
> To me, a functional programming approach using GLists is not something
> which every project is going to use. Is there any harm in keeping it as
> a separate library? There’s nothing stopping projects from linking to
> GLib *and* GXLib. :-)

> The command line parsing stuff you have looks a bit more widely
> applicable. Were you considering merging those into GLib?
>
> http://www.djcbsoftware.nl/code/gxlib/gxlib-Command-line-parsing.html
>
> Anyway, nice work on GXLib. It looks well documented.

Thanks! Yeah, the functional approach may not be for everyone, though of
course one could argue that that didn't stop C++, Rust etc., but true,
there's value in keeping GLib lean.

The command-line stuff is an attempt to trick the GLib option-parser
into working with sub-commands, and it's been quite a time-saver for
some of my projects. Still, it is a bit clumsy in places, since it the
GLib option parser doesn't expose some of the details that would be
useful.

But as Emmanuele mentions, perhaps some bigger/braver effort would be
better.

Anyway, I'll keep GXLib around for my own projects and for whomever. In
fact, I'd happily take contributions for "GLibberish" code that doesn't
quite fit into GLib.

Kind regards,
Dirk.

--
Dirk-Jan C. Binnema                  Helsinki, Finland
e:[hidden email]           w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Functional programming with GLib

Matthias Clasen-2
In reply to this post by Emmanuele Bassi


On Thu, Apr 27, 2017 at 10:29 AM, Emmanuele Bassi <[hidden email]> wrote:
For command line parsing I'd actually favour a slightly bolder
approach of deprecating GOptionContext, and having something slightly
more modern — in terms of being bindable in other languages, and
well-integrated with API like GApplication.


What is lacking in the current incarnation of commandline option support in GApplication?

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Functional programming with GLib

Emmanuele Bassi
On 2 May 2017 at 00:09, Matthias Clasen <[hidden email]> wrote:

> On Thu, Apr 27, 2017 at 10:29 AM, Emmanuele Bassi <[hidden email]> wrote:
>>
>> For command line parsing I'd actually favour a slightly bolder
>> approach of deprecating GOptionContext, and having something slightly
>> more modern — in terms of being bindable in other languages, and
>> well-integrated with API like GApplication.
>>
>
> What is lacking in the current incarnation of commandline option support in
> GApplication?

In general, a nicer API that does not rely on
GOptionEntry/GOptionGroup, which are barely introspectable, or that
does not rely on calling g_application_add_main_option() for every
single option in order to avoid the memory management weirdness of
GOptionEntry.

The other issue is that the command line options are accessible using
the GVariant API as a dictionary, which requires additional
translation into application data structures; you need to use
g_variant_dict_lookup(), which is not the nicest API in the world;
high level languages may be able to unpack the GVariantDict, but I'm
not entirely sure if that's actually the case.

Adding command line parsing in JavaScript based on the GLib API (since
JS does not have a "native" module to do that, like Python's
ArgParser) is usually pretty rough; I'd like to see something better
in that area.

Ciao,
 Emmanuele.

--
https://www.bassi.io
[@] ebassi [@gmail.com]
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Functional programming with GLib

Tristan Van Berkom-3
In reply to this post by Matthias Clasen-2
On Mon, 2017-05-01 at 19:09 -0400, Matthias Clasen wrote:

>
>
> On Thu, Apr 27, 2017 at 10:29 AM, Emmanuele Bassi <[hidden email]>
> wrote:
> > For command line parsing I'd actually favour a slightly bolder
> > approach of deprecating GOptionContext, and having something
> > slightly
> > more modern — in terms of being bindable in other languages, and
> > well-integrated with API like GApplication.
> >
>
> What is lacking in the current incarnation of commandline option
> support in GApplication? 

Since this was raised here and I've currently been working with
python's click library and trying to make some enhancements there, just
thought I'd throw some things out there.

Some things that I'm finding important for CLI apps:

A.) Automatic generation of man pages and similar documentation,
    especially generating separate man pages for each separate sub
    command.

    I'm not even sure, do we have this already ?

B.) Built-in support for bash completions, allowing optional overrides
    for the application to implement custom completion suggestions
    for selected options/arguments.


This is all probably possible without completely replacing the API with
a new one, though.

Cheers,
    -Tristan

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Functional programming with GLib

Matthias Clasen-2
On Tue, May 9, 2017 at 4:59 AM, Tristan Van Berkom <[hidden email]> wrote:

Some things that I'm finding important for CLI apps:

A.) Automatic generation of man pages and similar documentation,
    especially generating separate man pages for each separate sub
    command.

    I'm not even sure, do we have this already ?

I fail to see the value of a man page that just repeats what --help already tells me.  Why is this useful ?


B.) Built-in support for bash completions, allowing optional overrides
    for the application to implement custom completion suggestions
    for selected options/arguments.

This on the other hand, is very useful. But hard to do in a way that is generic enough for all possible styles of
commandline interface that people have built with GOption. Do you have a suggestion for this ?

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Functional programming with GLib

Stefan Sauer-4
In reply to this post by Tristan Van Berkom-3
Am 09.05.2017 um 10:59 schrieb Tristan Van Berkom:

> On Mon, 2017-05-01 at 19:09 -0400, Matthias Clasen wrote:
>>
>>
>> On Thu, Apr 27, 2017 at 10:29 AM, Emmanuele Bassi <[hidden email]>
>> wrote:
>>> For command line parsing I'd actually favour a slightly bolder
>>> approach of deprecating GOptionContext, and having something
>>> slightly
>>> more modern — in terms of being bindable in other languages, and
>>> well-integrated with API like GApplication.
>>>
>>
>> What is lacking in the current incarnation of commandline option
>> support in GApplication?
>
> Since this was raised here and I've currently been working with
> python's click library and trying to make some enhancements there, just
> thought I'd throw some things out there.
>
> Some things that I'm finding important for CLI apps:
>
> A.) Automatic generation of man pages and similar documentation,
>     especially generating separate man pages for each separate sub
>     command.
>
>     I'm not even sure, do we have this already ?

You can document your man page using gtkdoc (with a PROGRAM section). More
introspection would be nice though.

>
> B.) Built-in support for bash completions, allowing optional overrides
>     for the application to implement custom completion suggestions
>     for selected options/arguments.
>
>
> This is all probably possible without completely replacing the API with
> a new one, though.
>
> Cheers,
>     -Tristan
>
> _______________________________________________
> gtk-devel-list mailing list
> [hidden email]
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Functional programming with GLib

Joël Krähemann-3
In reply to this post by Dirk-Jan C. Binnema-2
Hi

Why not doing a different approach? Provide serialization to your list
and pass it to AgsFunction?

I would love to see something alike in GSequencer. Thus I did a boxed
type AgsComplex.
The mention object above shall be able to solve mathematical equations.

Note I is not implemented for now. But feel free to provide solver strategies ;)
The goal is to let the user describe its synth by a formula.

nongnu.org/gsequencer

Bests,
Joël


On Sun, Apr 23, 2017 at 8:46 PM, Dirk-Jan C. Binnema
<[hidden email]> wrote:

>
> Hi All,
>
> A while back, I wrote some functions for functional-flavored programming
> with GLib. It's fully documented[1], has tests, etc.
>
> It would (for me at least) be useful to have some of these functions in
> GLib-proper, but I suspect the GLib-maintainers are not /too/ eager to
> accept contributions to GList... anyway, perhaps its useful for others.
>
> As a simple example, suppose we want to calculate the sum of primes up
> to 100 (a common task after all):
>
> ,----
> | int    sum;
> | GList *nums, *primes;
> |
> | nums   = gx_list_iota (100, 1, 1);
> | primes = gx_list_filter (nums, (GXPred)gx_is_prime, NULL);
> | sum    = gx_list_sum (primes); /* => 1060 */
> |
> | g_list_free (nums);
> | g_list_free (primes);
> `----
>
> There's also folding, mapping etc. See a short article about this:
>    http://www.djcbsoftware.nl/2015/10/04/functional-glists/
> (2015?! time does fly). Am still developing it though.
>
> Repo: https://github.com/djcb/gxlib
> Docs: http://www.djcbsoftware.nl/code/gxlib/
>
> Best wishes,
> Dirk.
>
> --
> Dirk-Jan C. Binnema                  Helsinki, Finland
> e:[hidden email]           w:www.djcbsoftware.nl
> pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C
> _______________________________________________
> gtk-devel-list mailing list
> [hidden email]
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Loading...