Re: [Chicken-users] Minor problem with args egg
> On May 13, 2015, at 11:55, Jim Ursetto wrote: > > #t does seem to make sense ... the existing behavior comes from the srfi-37 > implementation which sets the value to #f for #:none args. I could modify > the args egg to change #f to #t in this case; I don't think this would cause > any problems. Will think it over tonight. > In args 1.5.1, #:none options now return a value of #t instead of the srfi-37 default of #f, so they are effectively booleans. This would also set up the possibility for —no-xx options which set option ‘xx' to #f; naturally, that is not yet implemented. #:optional options will still return #f when an argument is not provided, since it is not nice to explicitly test against #t to distinguish between argument provided and not. Also, optional arguments should not be boolean in my opinion. An argument value of #f allows you to implement a default of “1" by placing this in the body: (set! arg (or arg “1”)) Jim ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Minor problem with args egg
On Wed, May 13, 2015 at 10:55 AM, Jim Ursetto wrote: > > #t does seem to make sense ... the existing behavior comes from the > srfi-37 implementation which sets the value to #f for #:none args. > Oh, yes, I see. I think #f would be reasonable if you were processing options with args-fold. Not so much if you want to use alist-ref - which, judging by your examples, is a practice you endorse. > I could modify the args egg to change #f to #t in this case; I don't think > this would cause any problems. Will think it over tonight. > Thanks for looking at it. Matt ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Minor problem with args egg
On Wed, May 13, 2015 at 4:52 AM, Peter Bex wrote: > On Wed, May 13, 2015 at 03:38:41AM -0600, Matt Gushee wrote: > > Anyway, it seems that if you specify an option with no arguments, e.g. > > > >(args:make-option (v version) #:none > > "Display compiled versions.") > > > > ... then when the user invokes the program with that option, you get: > > > >'((v . #f) (version . #f)) > > > > ... which means that alist-ref will not tell you whether the user passed > > that option, or it simply isn't present. I wonder if it wouldn't be > better > > for a no-arg option to produce a symbol, #:undefined perhaps? > > I would expect #t to be present if the user passed the option. This > allows for easy presence-checking, and it's similar to an option that > accepts "yes" or "no". > #t does seem to make sense ... the existing behavior comes from the srfi-37 implementation which sets the value to #f for #:none args. I could modify the args egg to change #f to #t in this case; I don't think this would cause any problems. Will think it over tonight. Jim ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Minor problem with args egg
On Wed, May 13, 2015 at 03:38:41AM -0600, Matt Gushee wrote: > Anyway, it seems that if you specify an option with no arguments, e.g. > >(args:make-option (v version) #:none > "Display compiled versions.") > > ... then when the user invokes the program with that option, you get: > >'((v . #f) (version . #f)) > > ... which means that alist-ref will not tell you whether the user passed > that option, or it simply isn't present. I wonder if it wouldn't be better > for a no-arg option to produce a symbol, #:undefined perhaps? I would expect #t to be present if the user passed the option. This allows for easy presence-checking, and it's similar to an option that accepts "yes" or "no". Cheers, Peter signature.asc Description: Digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Minor problem with args egg
Hello-- In the process of writing the command-line app that goes with the sass egg, I noticed an issue with the args egg. I don't know if this is necessarily a bug - maybe just an awkward feature. Anyway, it seems that if you specify an option with no arguments, e.g. (args:make-option (v version) #:none "Display compiled versions.") ... then when the user invokes the program with that option, you get: '((v . #f) (version . #f)) ... which means that alist-ref will not tell you whether the user passed that option, or it simply isn't present. I wonder if it wouldn't be better for a no-arg option to produce a symbol, #:undefined perhaps? -- Matt Gushee ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
