Re: guile-user Digest, Vol 188, Issue 9

Re: guile-user Digest, Vol 188, Issue 9

[Zelphir Kaltstahl]

On 08.07.2018 18:00, guile-user-request@gnu.org wrote:
> ------------------------------
>
> Message: 3
> Date: Sun, 8 Jul 2018 08:44:22 -0700
> From: Matt Wette <matt.wette@gmail.com>
> To: guile-user@gnu.org
> Subject: Re: Parsing command line arguments, predicate error
> Message-ID: <e9c9c87b-389d-70d1-7afe-13a0b03e168d@gmail.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
>
>
> On 07/08/2018 04:49 AM, Zelphir Kaltstahl wrote:
>> Hi!
>>
>> I decided to take a look at how one can parse command line arguments in
>> Guile and was looking for something like argparse in Python. It seems
>> that (use-modules (ice-9 getopt-long)) does the job, except that I hit
>> one problem and don't know what the mistake I am making is. It seems to
>> be connected to the usage of `predicate` in my code.
> You probably want to use quasi-quote + unquote:
>  ? `((version ... (predicate ,string-exact-integer?))))
>
> I believe the module (srfi srfi-37), args-fold, is now recommended over 
> getopt-long.
>
> Matt

That solved the problem, thank you Matt!
I was so far quite fond of the way one specifies options with
getopt-long, but the quasi-quote unquote was not mentioned in the Guile
docs and feels unnatural. There seems to be no reason for it to force me
to do that, except that it does not work otherwise. I'll probably look
into how it is done with SRFI-37, because of this.

Apart from this issue, what are the reasons for SRFI-37 to be
recommended over getopt-long?

Re: guile-user Digest, Vol 188, Issue 9

[Matt Wette]

On 07/08/2018 10:00 AM, Zelphir Kaltstahl wrote:
> On 08.07.2018 18:00, guile-user-request@gnu.org wrote:
> Apart from this issue, what are the reasons for SRFI-37 to be
> recommended over getopt-long?
>

The reason I changed was that I wanted to handle multiple flagged 
arguments (e.g, "-x abc -x def").

Re: guile-user Digest, Vol 188, Issue 9

[Keith Wright]

Zelphir Kaltstahl <zelphirkaltstahl@gmail.com> writes:

>>> I decided to take a look at how one can parse command line arguments in
>>> Guile and was looking for something like argparse in Python. It seems
>>> that (use-modules (ice-9 getopt-long)) does the job, except that I hit
>>> one problem and don't know what the mistake I am making is. It seems to
>>> be connected to the usage of `predicate` in my code.
>>>
>>>;; ===== EXAMPLE START =====
>>>(define (string-exact-integer? str)
>>>  (exact-integer? (string->number str)))
>>>
>>>(define option-spec
>>>  '((version ... (predicate string-exact-integer?))))
>>>
>>> I am providing a function that takes the
>>> option's value as string and returns #t or #f.

>> From: Matt Wette <matt.wette@gmail.com>
>>
>> You probably want to use quasi-quote + unquote:
>>  ? `((version ... (predicate ,string-exact-integer?))))

Zelphir Kaltstahl <zelphirkaltstahl@gmail.com> writes:
>
> That solved the problem, thank you Matt!
> I was so far quite fond of the way one specifies options with
> getopt-long, but the quasi-quote unquote was not mentioned in the Guile
> docs and feels unnatural.

Actually my copy of the manual says:
  (predicate func)
    ...
     then getopt-long will apply func to the value,
     and throw an exception if it returns #f.

    func should be a procedure which accepts a string and
    returns a boolean value; you may need to use
    quasiquotes to get it intoa grammar.

So a warning about quasiquote _is_ mentioned in the Guile docs,
although it wouldn't hurt to put in an example to clarify just _how_
to "use quasiquote to get it into the grammmar."

> There seems to be no reason for it to force me
> to do that, except that it does not work otherwise.

When I first read that, I was exasperated.  What more reason
do you need to do it right?  It works that way and doesn't
work if you do it wrong.

Upon further reflection I realized that you are probably not
asking why right is better than wrong, but confused about
what quasiquote does.

The manual says:
  func should be a procedure

You said:
>>> I am providing a function that takes the
>>> option's value as string and returns #t or #f.

but that is _not_ what you were doing.  If the whole
list is quoted, then the occurrence of "string-exact-integer?"
in the list is a _symbol_.  It must be unquoted so
that it will be evaluated to a function (i.e. procedure).

It's like the difference between (+ 2 2) and ('+ 2 2).

The manual could use more explanation, but I believe
it is correct.

Hope this helps.

  -- Keith

Re: guile-user Digest, Vol 188, Issue 9

[Zelphir Kaltstahl]

On 09.07.2018 05:42, Keith Wright wrote:
> Actually my copy of the manual says:
>   (predicate func)
>     ...
>      then getopt-long will apply func to the value,
>      and throw an exception if it returns #f.
>
>     func should be a procedure which accepts a string and
>     returns a boolean value; you may need to use
>     quasiquotes to get it intoa grammar.
>
> So a warning about quasiquote _is_ mentioned in the Guile docs,
> although it wouldn't hurt to put in an example to clarify just _how_
> to "use quasiquote to get it into the grammmar."
>
>> There seems to be no reason for it to force me
>> to do that, except that it does not work otherwise.
> When I first read that, I was exasperated.  What more reason
> do you need to do it right?  It works that way and doesn't
> work if you do it wrong.
>
> Upon further reflection I realized that you are probably not
> asking why right is better than wrong, but confused about
> what quasiquote does.
>
> The manual says:
>   func should be a procedure
>
> You said:
>>>> I am providing a function that takes the
>>>> option's value as string and returns #t or #f.
> but that is _not_ what you were doing.  If the whole
> list is quoted, then the occurrence of "string-exact-integer?"
> in the list is a _symbol_.  It must be unquoted so
> that it will be evaluated to a function (i.e. procedure).
>
> It's like the difference between (+ 2 2) and ('+ 2 2).
>
> The manual could use more explanation, but I believe
> it is correct.
>
> Hope this helps.
>
>   -- Keith

Haha, yes, I was talking about my confusion with the quasiquote :D Maybe
I should have put that a little clearer.

About the phrase in the docs: That's interesting. I was thinking when I
read your reply: "Wha...? How could I overlook that? I read multiple
times!" and it turns out, that we have different versions of the same docs!

For me it reads:

> Finally, the |predicate| property can be used to constrain the
possible values of an option. If used, the |predicate| property should
be set to a procedure that takes one argument — the proposed option
value as a string — and returns either |#t| or |#f| according as the
proposed value is or is not acceptable. If the predicate procedure
returns |#f|, |getopt-long| will signal an error.

on
https://www.gnu.org/software/guile/manual/html_node/Option-Specification.html#Option-Specification

Am I reading an old version or a different page?

Anyway, now that you explain it like this, I suddenly understand why it
was wrong not to use quasiquote + unquote. In my code it was used as a
symbol, because of the quote. Unquoting would then do what I thought I
was doing. However, it still seems like it could be able to figure out
what predicate I am specifying from that symbol, couldn't it? Something
like "find the function for this symbol"? But then again I specified a
lambda before I tried a named function/predicate and then it could not
have gotten, that I guess.
I might also try to use (list …), if it is possible to avoid quote and
with that non-evaluation. But I guess it is not, because of other
undefined things in the specification of the options.

Thanks for helping me getting rid of the confusion!

~ Zelphir

Re: guile-user Digest, Vol 188, Issue 9

[Alex Sassmannshausen]

Hi Zelphir,

Just as a heads up — this is perhaps a little tangential.  I created the
guile-config package
(https://gitlab.com/a-sassmannshausen/guile-config), which builds on
getopt-long to provide a (IMHO) richer and more sustainable approach to
managing commandline options for a program.

Just figured you might be interested to have a look, as you were curious
about the subject matter.

HTH,

Alex

Zelphir Kaltstahl writes:

> On 08.07.2018 18:00, guile-user-request@gnu.org wrote:
>> ------------------------------
>>
>> Message: 3
>> Date: Sun, 8 Jul 2018 08:44:22 -0700
>> From: Matt Wette <matt.wette@gmail.com>
>> To: guile-user@gnu.org
>> Subject: Re: Parsing command line arguments, predicate error
>> Message-ID: <e9c9c87b-389d-70d1-7afe-13a0b03e168d@gmail.com>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>>
>>
>>
>> On 07/08/2018 04:49 AM, Zelphir Kaltstahl wrote:
>>> Hi!
>>>
>>> I decided to take a look at how one can parse command line arguments in
>>> Guile and was looking for something like argparse in Python. It seems
>>> that (use-modules (ice-9 getopt-long)) does the job, except that I hit
>>> one problem and don't know what the mistake I am making is. It seems to
>>> be connected to the usage of `predicate` in my code.
>> You probably want to use quasi-quote + unquote:
>>  ? `((version ... (predicate ,string-exact-integer?))))
>>
>> I believe the module (srfi srfi-37), args-fold, is now recommended over 
>> getopt-long.
>>
>> Matt
>
> That solved the problem, thank you Matt!
> I was so far quite fond of the way one specifies options with
> getopt-long, but the quasi-quote unquote was not mentioned in the Guile
> docs and feels unnatural. There seems to be no reason for it to force me
> to do that, except that it does not work otherwise. I'll probably look
> into how it is done with SRFI-37, because of this.
>
> Apart from this issue, what are the reasons for SRFI-37 to be
> recommended over getopt-long?

Re: Guile Config

[Zelphir Kaltstahl]

On 10.07.2018 11:50, Alex Sassmannshausen wrote:
> Hi Zelphir,
>
> Just as a heads up — this is perhaps a little tangential.  I created the
> guile-config package
> (https://gitlab.com/a-sassmannshausen/guile-config), which builds on
> getopt-long to provide a (IMHO) richer and more sustainable approach to
> managing commandline options for a program.
>
> Just figured you might be interested to have a look, as you were curious
> about the subject matter.
>
> HTH,
>
> Alex

Hi Alex,

I took a short look and Guile config seems to do much more than only
parsing command line arguments. It seems to be a more general thing for
configuring any kind of program and different kinds of configurations?

I think examples in the readme file for a few things one can do with it
would be cool. Could you provide some basic example for command line
arguments with Guile Config? (I am often guilty of not writing any
readme for my own projects ^^', but I pledge improvement!)
The ASCII art diagram is nice for getting an overview and I am sure it
all makes sense when one looks a bit closer and maybe looks into some of
the code as well. I could not understand, why this tool would itself
write configuration files after reading configuration files one provides
for it, nor what a codex really is, except that it is some kind of struct.
Maybe this all has to do with Guix? Do I need Guix for Guile Config or
is it intended to be used together with that? I've only once tried to
install the Guix OS thingy (Guix SD?). It did not boot from USB. I could
not install it on my machine and I could not find a working tutorial on
how to install it. Since then I've not tried again, so I have no
experience with Guix or the OS at all.

I am still learning about the "Guile ways" of doing basic things
(cooking recipe learning style, I guess :D). The two examples I've
created with getopt-long and SRFI 37 are in my examples repository
(https://gitlab.com/zelphir-kaltstahl-projects/guile-scheme-tutorials-and-examples/tree/dev/command-line-arguments).
With the SRFI 37 example I am not sure if the global options hash table
is a good idea, as I usually try to keep as little global state as
possible. I am trying to figure out all the basic things, so that if
some programming problem comes up, I could say "Oh, lets do that in
Guile Scheme.", just as easily, as I could do it with for example
Python. When I think of something I do in Python and then think: "But
how would I do it in Guile Scheme?", I feel an urge to be able to.
Knowing the basics will let me get to the meat of the problem, instead
of on-the-fly having to improvise many things to get there. If anyone
wants to, they can use it as tutorials or templates or whatever,
although I am too lazy currently to make proper tutorials out of things.
I try to keep the examples easy to understand for my own good too though.

Thanks for the hint Alex, great to see the Guile ecosystem growing! I
often see new release announcements on this mailing list and every piece
of new tooling or libraries makes it a bit better. Previously having
practiced some with Racket, I am used to suddenly discovering some
library that unexpectedly already does what I want in an elegant way. I
think it would be cool if Guile gets to the same level + more
discoverable. Especially with stuff like fibers (which is still on my
learning list) under its belt, it is very powerful. Guile Hall also
seems to be going in the direction of creating something that can be
used with package managers or a Guile packages specific manager (?).

Regards,
Zelphir

Re: Guile Config

[Alex Sassmannshausen]

Heya,

Zelphir Kaltstahl writes:

> On 10.07.2018 11:50, Alex Sassmannshausen wrote:
>> Hi Zelphir,
>>
>> Just as a heads up — this is perhaps a little tangential.  I created the
>> guile-config package
>> (https://gitlab.com/a-sassmannshausen/guile-config), which builds on
>> getopt-long to provide a (IMHO) richer and more sustainable approach to
>> managing commandline options for a program.
>>
>> Just figured you might be interested to have a look, as you were curious
>> about the subject matter.
>>
>> HTH,
>>
>> Alex
>
> Hi Alex,
>
> I took a short look and Guile config seems to do much more than only
> parsing command line arguments. It seems to be a more general thing for
> configuring any kind of program and different kinds of configurations?

Yes, you're right. It tries to automate some aspects of command-line
parsing (adding --help,version,usage automatically, generate short
versions of options).

Then it adds another layer on that commandline parsing interface that is
to do with "persistent commandline arguments", i.e. arguments that can
be set in configuration files.

The library supports configuration files that should be automatically
created (eager) or that can be created explicitly down the line.  It
also supports a hierarchy of configuration files (e.g. first, check the
config file in ~/, then check one in the current directory).

It also implements a clean interface for managing "sub-commands", so you
can define a whole tree of related commands, with the option of
inheriting commandline arguments, and configuration file settings
through that tree of sub-commands (e.g. guix, guix system, guix system
rebuild, would be a command, with 2 subcommands.  The latter may want to
inherit common options from guix system).

Also it implements the notion of a "handler", which can be provided to
parse commandline strings into data types you actually want to use in
your program.  It separates input parsing from your actual program,
which I *really* like.

> I think examples in the readme file for a few things one can do with it
> would be cool. Could you provide some basic example for command line
> arguments with Guile Config? (I am often guilty of not writing any
> readme for my own projects ^^', but I pledge improvement!)

Hah! yeah, that's definitely a weakness of mine too.  The repo contains
a .texi manual, which is pretty comprehensive, but the manual isn't yet
published anywhere… maybe I should look into that.

The repo also contains an example directory, that might help you?

> The ASCII art diagram is nice for getting an overview and I am sure it
> all makes sense when one looks a bit closer and maybe looks into some of
> the code as well. I could not understand, why this tool would itself
> write configuration files after reading configuration files one provides
> for it,

The idea here is that the program writes configuration files if they do
not exist yet, so the user can tweak them, rather than having to write
them from scratch.  Also, just to avoid confusion, the meaning of
configuration here means passing in values to tweak a programs settings
when invoking it, not, like, compilation configuration or some such.


> nor what a codex really is, except that it is some kind of struct.

Yeah, this is really just an implementation detail.  I should probably
hide that.

> Maybe this all has to do with Guix? Do I need Guix for Guile Config or
> is it intended to be used together with that?

You shouldn't need Guix — you should just be able to clone the repo and
update your GUILE_LOAD_PATH, or do the usual autoreconf -vif &&
./configure && make dance if you prefer (I shudder writing that,
personally ;-) )


> I've only once tried to install the Guix OS thingy (Guix SD?). It did
> not boot from USB. I could not install it on my machine and I could
> not find a working tutorial on how to install it. Since then I've not
> tried again, so I have no experience with Guix or the OS at all.

Ah, that's a pity — if it was a while ago, things have dramatically
improved now.  I believe the manual has fairly good instructions for
doing the binary installation of Guix the package manager.

> I am still learning about the "Guile ways" of doing basic things
> (cooking recipe learning style, I guess :D). The two examples I've
> created with getopt-long and SRFI 37 are in my examples repository
> (https://gitlab.com/zelphir-kaltstahl-projects/guile-scheme-tutorials-and-examples/tree/dev/command-line-arguments).
> With the SRFI 37 example I am not sure if the global options hash table
> is a good idea, as I usually try to keep as little global state as
> possible.

Agreed.  You could pass around the resulting configuration object
instead of storing it in a global var if you prefer.  That tends to be
what I do.

> I am trying to figure out all the basic things, so that if some
> programming problem comes up, I could say "Oh, lets do that in Guile
> Scheme.", just as easily, as I could do it with for example
> Python. When I think of something I do in Python and then think: "But
> how would I do it in Guile Scheme?", I feel an urge to be able to.
> Knowing the basics will let me get to the meat of the problem, instead
> of on-the-fly having to improvise many things to get there. If anyone
> wants to, they can use it as tutorials or templates or whatever,
> although I am too lazy currently to make proper tutorials out of
> things.  I try to keep the examples easy to understand for my own good
> too though.

Yeah, I think this is super valuable! Please continue doing this :-)

> Thanks for the hint Alex, great to see the Guile ecosystem growing! I
> often see new release announcements on this mailing list and every piece
> of new tooling or libraries makes it a bit better. Previously having
> practiced some with Racket, I am used to suddenly discovering some
> library that unexpectedly already does what I want in an elegant way. I
> think it would be cool if Guile gets to the same level + more
> discoverable. Especially with stuff like fibers (which is still on my
> learning list) under its belt, it is very powerful. Guile Hall also
> seems to be going in the direction of creating something that can be
> used with package managers or a Guile packages specific manager (?).

Yeah, there seems to be momentum with Guile (and Guix) atm.  Would be
great to see it keep up :-D

Alex

>
> Regards,
> Zelphir

Re: Guile Config

[Zelphir Kaltstahl]

On 11.07.2018 15:33, Alex Sassmannshausen wrote:
>> I am still learning about the "Guile ways" of doing basic things
>> (cooking recipe learning style, I guess :D). The two examples I've
>> created with getopt-long and SRFI 37 are in my examples repository
>> (https://gitlab.com/zelphir-kaltstahl-projects/guile-scheme-tutorials-and-examples/tree/dev/command-line-arguments).
>> With the SRFI 37 example I am not sure if the global options hash table
>> is a good idea, as I usually try to keep as little global state as
>> possible.
> Agreed.  You could pass around the resulting configuration object
> instead of storing it in a global var if you prefer.  That tends to be
> what I do.
>

I am not quite sure I understand correctly. Do you mean that I can
create it globally as I do now, but then simply use it as a parameter
for my main or whatever my entry point procedure is called? (That should
be pass by value, right?)