Le dim. 21 juil. 2019 à 23:12, Lassi Kortela <xxxxxx@lassi.io> a écrit :
>
> >     But are the different keyword _objects_ incompatible with each other?
> >
> > I suppose it would work, but it means that the calling code wouldn't be
> > portable, of course.
>
> That's true. But it's quite difficult to maintain complex programs
> without keyword arguments since it's almost impossible to plan years
> ahead what arguments are needed in some procedures. Therefore it would
> really help the community to have keywords figured out.
>
> This could make another case for that #!(srfi 88) facility discussed
> some time ago on this list to enable or disable the syntax extensions
> from particular SRFIs. (Or John's preference without parens, #!srfi 88)
> For example, if a source file uses SRFI 88 style keywords it could have
> #!(srfi 88) at the start. If it used Common Lisp style keywords, it
> could have #!cl-keywords or something (haven't thought about this).
>
> This would enable each source file, plus the REPL, to separately choose
> its own keyword syntax. One implementation could support all of them
> this way. Would there be problems with this approach?

I never use keyword argument in Scheme. In Python I use them for documentation
purpose, but good naming can avoid that problem. FWIW, Guile has them in a
convoluted way (you can reference arguments in other arguments and their are
bound at call time) and I find it... disturbing. At some point Python
arguments will
be Turing Complete for sure.

FWIW, the worst thing in keyword arguments in Python is the **kwargs which
is equivalent to Guile #:allow-other-keys. Yes Guile use #:keyword for keywords
another thing that is disturbing. People end up abusing **kwargs and pass around
all the keys and only pick what they want / need when they need it. It somewhat
like an evaluator environment at the user level. It is horrible and
harm readability,
hurt mainteance (see Flask for instance).

I think adding keyword, will make procedure signature much more difficult.

The solution to use alist or case-lambda is enough complication.

What I was thinking about this topic, is not introduce another datum
like :keyword
or #:keyword but instead create some argument parser procedure like used
for command line arguments. This is backward compatible and build upon existing
knowledge.

E.g.

(define (my-procedure . args)
  (receive (parse-args '--wal? '--in-memory?)
    (wal? in-memory?) ....)))

I don't know what are plist.

--
Amirouche ~ amz3 ~ https://hyper.dev