Re: bug#10522: Patch: Improve optional variable and keyword notation in manual

Re: bug#10522: Patch: Improve optional variable and keyword notation in manual

[Andy Wingo]

Hi Bake,

This patch looks great.  I do have a couple of comments before
applying.  It would probably be useful to have input from others as
well, so I'm copying guile-devel.

On Mon 16 Jan 2012 20:46, Bake Timmons <b3timmons@speedymail.org> writes:
> -@deffn {Scheme Procedure} resolve-module name [autoload=#t] [version=#f] [#:ensure=#t]
> +@deffn {Scheme Procedure} resolve-module name [autoload=#t [version=#f]] @
> +                          [#:ensure ensure=#t]

Nesting the optional arguments in brackets can get a bit ugly.  It is
precise but verbose.  But I suppose we should not encourage interfaces
with many optional arguments, so perhaps it is a moot point.

Also, it seems pedantic to repeat the keyword arguments (once as
keyword, once as identifier).  Surely #:foo=bar is unambiguous?

Anyway, I'm interested what others think about changes like this.

Cheers,

Andy
-- 
http://wingolog.org/

Re: bug#10522: Patch: Improve optional variable and keyword notation in manual

[Ludovic Courtès]

Hello!  :-)

Andy Wingo <wingo@pobox.com> skribis:

> On Mon 16 Jan 2012 20:46, Bake Timmons <b3timmons@speedymail.org> writes:
>> -@deffn {Scheme Procedure} resolve-module name [autoload=#t] [version=#f] [#:ensure=#t]
>> +@deffn {Scheme Procedure} resolve-module name [autoload=#t [version=#f]] @
>> +                          [#:ensure ensure=#t]
>
> Nesting the optional arguments in brackets can get a bit ugly.  It is
> precise but verbose.  But I suppose we should not encourage interfaces
> with many optional arguments, so perhaps it is a moot point.

Indeed.

> Also, it seems pedantic to repeat the keyword arguments (once as
> keyword, once as identifier).  Surely #:foo=bar is unambiguous?

That’s what I would think.

Perhaps the people behind bug-texinfo@gnu.org have something to say
about this kind of thing, since there are other Lispy packages out there
with similar features?

Thanks,
Ludo’.

Re: bug#10522: Patch: Improve optional variable and keyword notation in manual

[Ian Price]

Andy Wingo <wingo@pobox.com> writes:

> Also, it seems pedantic to repeat the keyword arguments (once as
> keyword, once as identifier).  Surely #:foo=bar is unambiguous?

Since guile use the same name for both the keyword and identifier, I'd
say so.

-- 
Ian Price

"Programming is like pinball. The reward for doing it well is
the opportunity to do it again" - from "The Wizardy Compiled"

bug#10522: Patch: Improve optional variable and keyword notation in manual

[Bake Timmons]

Andy Wingo <wingo@pobox.com> writes:

> On Mon 16 Jan 2012 20:46, Bake Timmons <b3timmons@speedymail.org> writes:
>> -@deffn {Scheme Procedure} resolve-module name [autoload=#t]
>> [version=#f] [#:ensure=#t]
>> +@deffn {Scheme Procedure} resolve-module name [autoload=#t [version=#f]] @
>> +                          [#:ensure ensure=#t]
>
> Nesting the optional arguments in brackets can get a bit ugly.  It is
> precise but verbose.  But I suppose we should not encourage interfaces
> with many optional arguments, so perhaps it is a moot point.
>
> Also, it seems pedantic to repeat the keyword arguments (once as
> keyword, once as identifier).  Surely #:foo=bar is unambiguous?
>
> Anyway, I'm interested what others think about changes like this.
>
> Cheers,
>
> Andy

I agree about the verbosity and did not feel strongly about those
changes, so I am OK with reverting them.  BTW, this verbose convention
already existed in the manual.  E.g.,

  ref/api-debug.texi: [#:on-error on-error='debug] [#:post-error post-error='catch] @
  ref/api-debug.texi: [#:pass-keys pass-keys='(quit)] [#:trap-handler trap-handler='debug]

My motivation was to avoid confusing novices unfamiliar with using
keywords, but there are other ways to help them here besides inflicting
ugliness. %^)

Cheers,
Bake

Re: bug#10522: Patch: Improve optional variable and keyword notation in manual

[Andy Wingo]

Hi Bake,

On Fri 03 Feb 2012 14:28, Andy Wingo <wingo@pobox.com> writes:

> Hi Bake,
>
> This patch looks great.  I do have a couple of comments before
> applying.  It would probably be useful to have input from others as
> well, so I'm copying guile-devel.
>
> On Mon 16 Jan 2012 20:46, Bake Timmons <b3timmons@speedymail.org> writes:
>> -@deffn {Scheme Procedure} resolve-module name [autoload=#t] [version=#f] [#:ensure=#t]
>> +@deffn {Scheme Procedure} resolve-module name [autoload=#t [version=#f]] @
>> +                          [#:ensure ensure=#t]
>
> Nesting the optional arguments in brackets can get a bit ugly.  It is
> precise but verbose.  But I suppose we should not encourage interfaces
> with many optional arguments, so perhaps it is a moot point.
>
> Also, it seems pedantic to repeat the keyword arguments (once as
> keyword, once as identifier).  Surely #:foo=bar is unambiguous?

A year later, I pushed a version of your patch that doesn't nest
optional arguments or duplicate the keyword argument names, but it does
apply the other changes (and it makes keyword argument notation more
consistent).  Thanks for the patch, and looking forward to more of them
:)

Andy
-- 
http://wingolog.org/

Re: bug#10522: Patch: Improve optional variable and keyword notation in manual

[Daniel Hartwig]

On 3 March 2013 03:36, Andy Wingo <wingo@pobox.com> wrote:
> Hi Bake,
>
> On Fri 03 Feb 2012 14:28, Andy Wingo <wingo@pobox.com> writes:
>
>> Hi Bake,
>>
>> This patch looks great.  I do have a couple of comments before
>> applying.  It would probably be useful to have input from others as
>> well, so I'm copying guile-devel.
>>
>> On Mon 16 Jan 2012 20:46, Bake Timmons <b3timmons@speedymail.org> writes:
>>> -@deffn {Scheme Procedure} resolve-module name [autoload=#t] [version=#f] [#:ensure=#t]
>>> +@deffn {Scheme Procedure} resolve-module name [autoload=#t [version=#f]] @
>>> +                          [#:ensure ensure=#t]
>>
>> Nesting the optional arguments in brackets can get a bit ugly.  It is
>> precise but verbose.  But I suppose we should not encourage interfaces
>> with many optional arguments, so perhaps it is a moot point.
>>
>> Also, it seems pedantic to repeat the keyword arguments (once as
>> keyword, once as identifier).  Surely #:foo=bar is unambiguous?
>
> A year later, I pushed a version of your patch that doesn't nest
> optional arguments or duplicate the keyword argument names, but it does
> apply the other changes (and it makes keyword argument notation more
> consistent).  Thanks for the patch, and looking forward to more of them
> :)

Can I ask whether it is preferred to use, e.g. @code{#f}, for the
default values, as some places seem to and others don't.  This patch
is not using @code, but then, neither does it touch any doc. that was
previously.

Re: bug#10522: Patch: Improve optional variable and keyword notation in manual

[Andy Wingo]

On Sun 03 Mar 2013 02:07, Daniel Hartwig <mandyke@gmail.com> writes:

> Can I ask whether it is preferred to use, e.g. @code{#f}, for the
> default values, as some places seem to and others don't.  This patch
> is not using @code, but then, neither does it touch any doc. that was
> previously.

Good question.  Do you have an opinion?

Re: bug#10522: Patch: Improve optional variable and keyword notation in manual

[Daniel Hartwig]

On 3 March 2013 17:45, Andy Wingo <wingo@pobox.com> wrote:
> On Sun 03 Mar 2013 02:07, Daniel Hartwig <mandyke@gmail.com> writes:
>
>> Can I ask whether it is preferred to use, e.g. @code{#f}, for the
>> default values, as some places seem to and others don't.  This patch
>> is not using @code, but then, neither does it touch any doc. that was
>> previously.
>
> Good question.  Do you have an opinion?

I suppose that the context of @deffn is somewhat similar to @code, so
the nesting may be considered redundant.  However, when I look at
cases where non-atomic expressions are used, such as #:lang in:

 -- Scheme Procedure: eval-string string [#:module=#f] [#:file=#f]
          [#:line=#f] [#:column=#f] [#:lang=(current-language)]
          [#:compile?=#f]

we see that there is some potential confusion between the close,
unescaped (as with @code, ‘’) nesting of the parens/brackets.
Further, usage of ‘=’ like that is not valid Scheme code, so the
contexts are actually more distinct than the ealier supposition.

This leads me to have a _slight_ preference for using @code, as being
more technically correct.  Though cases such as the above are in the
minority.

Re: bug#10522: Patch: Improve optional variable and keyword notation in manual

[Daniel Hartwig]

On 9 March 2013 09:58, Daniel Hartwig <mandyke@gmail.com> wrote:
> On 3 March 2013 17:45, Andy Wingo <wingo@pobox.com> wrote:
>> On Sun 03 Mar 2013 02:07, Daniel Hartwig <mandyke@gmail.com> writes:
>>
>>> Can I ask whether it is preferred to use, e.g. @code{#f}, for the
>>> default values, as some places seem to and others don't.  This patch
>>> is not using @code, but then, neither does it touch any doc. that was
>>> previously.
>>
>> Good question.  Do you have an opinion?
>
> I suppose that the context of @deffn is somewhat similar to @code, so
> the nesting may be considered redundant.  However, when I look at
> cases where non-atomic expressions are used, such as #:lang in:
>
>  -- Scheme Procedure: eval-string string [#:module=#f] [#:file=#f]
>           [#:line=#f] [#:column=#f] [#:lang=(current-language)]
>           [#:compile?=#f]
>
> we see that there is some potential confusion between the close,
> unescaped (as with @code, ‘’) nesting of the parens/brackets.
> Further, usage of ‘=’ like that is not valid Scheme code, so the
> contexts are actually more distinct than the ealier supposition.
>
> This leads me to have a _slight_ preference for using @code, as being
> more technically correct.  Though cases such as the above are in the
> minority.

So I should also mention that omitting @code seems a bit more readable
in the resulting documentation.  At least we can clean up where some
values (symbols, empty lists) appear prefixed with unnecessary '.

Re: bug#10522: Patch: Improve optional variable and keyword notation in manual

[Andy Wingo]

On Sat 09 Mar 2013 02:58, Daniel Hartwig <mandyke@gmail.com> writes:

>  -- Scheme Procedure: eval-string string [#:module=#f] [#:file=#f]
>           [#:line=#f] [#:column=#f] [#:lang=(current-language)]
>           [#:compile?=#f]
>
> we see that there is some potential confusion between the close,
> unescaped (as with @code, ‘’) nesting of the parens/brackets.

Should we remove the brackets entirely? i.e

 -- Scheme Procedure: eval-string string #:module=#f #:file=#f
          #:line=#f #:column=#f #:lang=(current-language)
          #:compile?=#f

Or with @code{}:

 -- Scheme Procedure: eval-string string #:module=‘#f’ #:file=‘#f’
          #:line=‘#f’ #:column=‘#f’ #:lang=‘(current-language)’
          #:compile?=‘#f’

Dunno, just throwing more ideas out there...

Andy
-- 
http://wingolog.org/

Re: bug#10522: Patch: Improve optional variable and keyword notation in manual

[Daniel Hartwig]

On 9 March 2013 16:25, Andy Wingo <wingo@pobox.com> wrote:
> Should we remove the brackets entirely? i.e

I would not.  The brackets are fairly standard for optional arguments.