Re: About adding new egg "varg"
li lu via Chicken-users <[email protected]> Sat, 6 Dec 2025 16:43:28 +0000
| Newsgroups | gmane.lisp.scheme.chicken |
|---|---|
| Message-ID | <DS5PR14MB95808619CB400DB6F6B35082E8ECA4A@DS5PR14MB958086.namprd14.prod.outlook.com> |
Yes it was similar to DSSSL, but I think there are some differences between DSSSL and *varg*: - DSSSL define that parameters should keep particular type order: - required parameter(similar to `#:literal` in *varg*) - `#!optional` parameter(similar to `#:without-value` in *varg*) - `#!rest` parameter(similar to `#:literal` when set `#:enable-unknown` in *varg*) - `#!key` parameter(similar to `#:with-value` in *varg*) *varg* does not require parameters are in particular order, they are parsed by matching keywords between procedure definition and procedure call - DSSSL set `#!optional` parameters to `#f` if they are not bind to a default value and not presented in function call. Usually I hope it can be explicit set or not, but not `#f` or others. - In DSSSL, usually `#!optional` parameters cannot show its meaning in procedure calling, I have to move to procedure definition to get it. In *varg*, by defining meaningful keyword, I can know what this parameter is at the calling place, without searching other code Those are what I try to improve about parameter parsing in *varg* ________________________________ From: Mario Domenech Goulart <[email protected]> Sent: Saturday, December 6, 2025 6:08 PM To: li lu via Chicken-users <[email protected]> Cc: li lu <[email protected]> Subject: Re: About adding new egg "varg" Hi, On Sat, 6 Dec 2025 05:27:26 +0000 li lu via Chicken-users <[email protected]> wrote: > Thanks for advice, there are some explanation about the confusion: > > * About the platform > > * Actually the required egg varg was extracted from another project https://github.com/riku-ri/libyaml.ss. And > libyaml.ss build the C/C++ source by chicken-install using gcc/clang options. I’m not sure if win32/MinGW also work. > Anyway you’re right, varg.ss actually did not require the platform specified functions. So I remove it in the new > commit(did not release yet) > > * About the usage > > * I added another example including how to get values and print them > The new example is a little bit log so did not show it here > > * https://github.com/riku-ri/varg.ss/blob/main/docs/usage.md#examples > * https://riku-ri.github.io/varg.ss/docs/usage.html#examples > > * About the condition syntax > > * Personally I preffered cond than other condition syntax, because it can add multiple steps in a branch, without > wrapping additional let or begin > > Hope that these can clarify your confusion. Thanks for sharing your code and for the clarifications. Just to make sure we are not adding something that already exists natively in CHICKEN in a slightly different form: CHICKEN supports extended DSSSL style parameter lists, which seem to provide a similar functionality. It's not standard Scheme and is bit hidden in the manual: https://wiki.call-cc.org/man/5/Module%20scheme#procedures (scroll a bit down or look for "As an extension to R5RS, CHICKEN also supports "extended" DSSSL style parameter lists"). Using the cp case as an example: (define (cp from to #!key mode force) (pp `((force ,force) (mode ,mode) (from ,from) (to ,to)))) (cp "tmp/a" "tmp/b") ;; => ((force #f) (mode #f) (from "tmp/a") (to "tmp/b")) (cp "tmp/a" "tmp/b" force: #t) ;; => ((force #t) (mode #f) (from "tmp/a") (to "tmp/b")) (cp "tmp/a" "tmp/b" force: #t mode: #o777) ;; => ((force #t) (mode 511) (from "tmp/a") (to "tmp/b")) (cp "tmp/a" "tmp/b" mode: #o777) ;; => ((force #f) (mode 511) (from "tmp/a") (to "tmp/b")) All the best. Mario -- https://parenteses.org/mario