keyword arguments
Neil Van Dyke
loosely-defined strawperson...
* Keywords look like ":foo", "foo:", or "#:foo", depending on your dialect.
* The main use of keywords is to name "keyword arguments" in procedure
applications and syntax uses, such as for optional arguments or for clarity.
* "lambda" is extended to permit keyword arguments to be defined, each
of which argument may have a default value. The argument is optional
iff a default value was defined.
* The various syntax definition forms should permit syntax transformers
to be keyword-aware as well.
* Example:
(define f (lambda (a b c (:foo 42) :bar) foo))
(f 1 2 3 :foo 4 :bar 5) ==> 4
(f 1 2 3 :bar 5) ==> 42
(f 1 2 3) =error=> :bar keyword argument required
(f 1 2 3 :foo 4 :bar 5 :zoo 6) =error=> unrecognized keyword :zoo
* Note: If keywords are first-class values, and you want to pass a
keyword as an argument in an application in a position in which it might
be parsed as a keyword, you cannot put a keyword literal into the
application syntax directly.
* I probably wouldn't have keyword arguments in WG2, but their
implementation in WG2 would likely impose requirements on WG1.
John Cowan
> * Keywords look like ":foo", "foo:", or "#:foo", depending on your
> dialect.
Support isn't that widespread: only 8 out of the 22 implementations
I examined have keywords of any sort. Specifically (this is also in
KeywordSyntax on the wiki):
Gauche (and Common Lisp) support :foo.
Gambit, Kawa (and DSSSL) support foo:
Bigloo supports both foo: and :foo and treats them as the same
(in the sense of EQV?).
Scheme 7 supports both foo: and :foo and treats them as distinct
(in the sense of EQV?).
MZScheme, Guile support #:foo.
Chicken supports #:foo always, and also allows either foo: or :foo
depending on the setting of a parameter or a startup option.
MIT, Scheme48/scsh, SISC, Chez, SCM, Ikarus, Larceny, Mosh, Scheme 9,
SSCM, SXM, VSCM, Chibi don't support any of them.
Based on this sparse set of implementations and hopeless lexical-syntax
tangle, I'd be against supporting keywords in either WG1 or WG2.
> * I probably wouldn't have keyword arguments in WG2, but their
I assume s/WG2/WG1/ here.
--
There is no real going back. Though I John Cowan
may come to the Shire, it will not seem co...@ccil.org
the same; for I shall not be the same. http://www.ccil.org/~cowan
I am wounded with knife, sting, and tooth,
and a long burden. Where shall I find rest? --Frodo
Neil Van Dyke
> Support isn't that widespread: only 8 out of the 22 implementations
> I examined have keywords of any sort. Specifically (this is also in
> KeywordSyntax on the wiki):
>
> Gauche (and Common Lisp) support :foo.
>
> Gambit, Kawa (and DSSSL) support foo:
>
> Bigloo supports both foo: and :foo and treats them as the same
> (in the sense of EQV?).
>
> Scheme 7 supports both foo: and :foo and treats them as distinct
> (in the sense of EQV?).
>
> MZScheme, Guile support #:foo.
>
> Chicken supports #:foo always, and also allows either foo: or :foo
> depending on the setting of a parameter or a startup option.
>
> MIT, Scheme48/scsh, SISC, Chez, SCM, Ikarus, Larceny, Mosh, Scheme 9,
> SSCM, SXM, VSCM, Chibi don't support any of them.
>
> Based on this sparse set of implementations and hopeless lexical-syntax
> tangle, I'd be against supporting keywords in either WG1 or WG2.
>
What I see is that Schemes people use for real work tend to *have*
keywords. (Most of the Schemes that support keywords are among the most
popular Schemes for real work -- the target of WG2 -- including 3 of my
4 favorite implementations. Everyone has different ideas of which
Schemes are best for which purposes, and different awarenesses of who is
using what, of course.)
I'd like to see WG2 support keywords.
I'd like to see WG1 permit WG2 to use keywords, and perhaps support
their use in syntax definition forms, but not necessarily otherwise use
keywords.
I'd suggest supporting only one keyword read form, which is also the
print form.
I'd lean towards ":foo" keyword form, partly for historical reasons,
partly because it's not a bad choice. "foo:" form does look cooler when
used as a label followed by a value, but un-cooly misleading when it is
used for other purposes. (I have had to use "#:foo" a lot lately, and
it's unpleasant both to look at and to type, even though I do like that
it avoids seizing some of the R5RS symbol namespace.)
I imagine that *one way* most Schemes that already have keywords but
that use a different form than the WG keywords could migrate to WG
support would be: use WG keyword form as canonical for read and print,
and support their legacy keyword form as simply an alternative read form.
P.S., That list has at least one small mischaracterization. While Guile
canonically uses "#:foo", it can also support either ":foo" or "foo:" as
an alternative read format, selected through a runtime option.
http://www.gnu.org/software/guile/manual/html_node/Keyword-Read-Syntax.html
John Cowan
> What I see is that Schemes people use for real work tend to *have*
> keywords. (Most of the Schemes that support keywords are among the most
> popular Schemes for real work -- the target of WG2 -- including 3 of my
> 4 favorite implementations. Everyone has different ideas of which
> Schemes are best for which purposes, and different awarenesses of who is
> using what, of course.)
Indeed. What are your four favorites, and what ones do you think people
use for real work? I ask in order to gather information, not to rebut you.
> I'd like to see WG1 permit WG2 to use keywords, and perhaps support
> their use in syntax definition forms, but not necessarily otherwise use
> keywords.
I should think that the important thing about keywords from a WG1 viewpoint
is the reservation of their lexical space and the fact that they self-evaluate.
> I'd suggest supporting only one keyword read form, which is also the
> print form.
Fair enough, but which?
> I'd lean towards ":foo" keyword form, partly for historical reasons,
> partly because it's not a bad choice. "foo:" form does look cooler when
> used as a label followed by a value, but un-cooly misleading when it is
> used for other purposes. (I have had to use "#:foo" a lot lately, and
> it's unpleasant both to look at and to type, even though I do like that
> it avoids seizing some of the R5RS symbol namespace.)
Choosing :foo makes Gauche, Bigloo, Scheme 7 compliant out of the box, and
Chicken compliant with an option.
Choosing foo: makes Gambit, Chicken, Bigloo, Kawa, Scheme 7 compliant out
of the box (the default setting of Chicken's paramater is "suffix"), and
Guile compliant with an option.
Choosing #:foo makes PLT, Chicken, Guile compliant out of the box.
If we discount Scheme 7 as a very limited-use implementation, having only
2-4 implementations in compliance with *any* of these choices doesn't
look like an overwhelmingly popular feature to me.
--
Time alone is real John Cowan <co...@ccil.org>
the rest imaginary
like a quaternion --phma http://www.ccil.org/~cowan
what-a-guy
> Choosing :foo makes Gauche, Bigloo, Scheme 7 compliant out of the box, and
> Chicken compliant with an option.
>
> Choosing foo: makes Gambit, Chicken, Bigloo, Kawa, Scheme 7 compliant out
> of the box (the default setting of Chicken's paramater is "suffix"), and
> Guile compliant with an option.
>
> Choosing #:foo makes PLT, Chicken, Guile compliant out of the box.
As you mentioned previously, Bigloo allows both :foo and foo:.
Also "(f 1 2 3) =error=> :bar keyword argument required " would not be
true for Bigloo, which gives :bar the value #f since no default was
given.
I'd support a standard for keywords, and :foo looks good to me.
John Cowan
> As you mentioned previously, Bigloo allows both :foo and foo:.
Bigloo appears in both of the out-of-the-box lists.
> Also "(f 1 2 3) =error=> :bar keyword argument required " would not be
> true for Bigloo, which gives :bar the value #f since no default was
> given.
I haven't looked at who uses keywords and how, just at support and syntax.
--
John Cowan <co...@ccil.org> http://www.ccil.org/~cowan
One time I called in to the central system and started working on a big
thick 'sed' and 'awk' heavy duty data bashing script. One of the geologists
came by, looked over my shoulder and said 'Oh, that happens to me too.
Try hanging up and phoning in again.' --Beverly Erlebacher
Neil Van Dyke
> Choosing :foo makes Gauche, Bigloo, Scheme 7 compliant out of the box, and
> Chicken compliant with an option.
>
> Choosing foo: makes Gambit, Chicken, Bigloo, Kawa, Scheme 7 compliant out
> of the box (the default setting of Chicken's paramater is "suffix"), and
> Guile compliant with an option.
>
> Choosing #:foo makes PLT, Chicken, Guile compliant out of the box.
>
> If we discount Scheme 7 as a very limited-use implementation, having only
> 2-4 implementations in compliance with *any* of these choices doesn't
> look like an overwhelmingly popular feature to me.
>
made the effort to implement a keywords feature.
That most of those Schemes implement the keyword feature in slightly
different ways doesn't make the keyword feature unpopular. Again, I
read this list as the implementing of keywords being very popular among
popular Schemes.
Whether keywords are popular among users, this list does not say. I
will, however, point to the diversity of implementations as evidence
that most of the Scheme implementors were not simply picking up a SRFI
so that they could check off compliance.
I think it is the place of WG2 or WG1 to get past these slightly
different ways of doing keywords, and provide a standard keyword feature
that all Schemes have the option of moving to.
I propose that WG2 take on supporting a keyword arguments feature, and
WG2 make requests to WG1 to provide any necessary accommodations.
what-a-guy
> You've listed a bunch of some of the most popular Schemes as all having
> made the effort to implement a keywords feature.
>
> That most of those Schemes implement the keyword feature in slightly
> different ways doesn't make the keyword feature unpopular. Again, I
> read this list as the implementing of keywords being very popular among
> popular Schemes.
>
> Whether keywords are popular among users, this list does not say. I
> will, however, point to the diversity of implementations as evidence
> that most of the Scheme implementors were not simply picking up a SRFI
> so that they could check off compliance.
>
> I think it is the place of WG2 or WG1 to get past these slightly
> different ways of doing keywords, and provide a standard keyword feature
> that all Schemes have the option of moving to.
>
> I propose that WG2 take on supporting a keyword arguments feature, and
> WG2 make requests to WG1 to provide any necessary accommodations.
John Cowan
> Whether keywords are popular among users, this list does not say. I
> will, however, point to the diversity of implementations as evidence
> that most of the Scheme implementors were not simply picking up a SRFI
> so that they could check off compliance.
Particularly since SRFI 88 does not have a portable implementation worth
mentioning: it changes both the lexical syntax and the evaluator.
--
Is a chair finely made tragic or comic? Is the John Cowan
portrait of Mona Lisa good if I desire to see co...@ccil.org
it? Is the bust of Sir Philip Crampton lyrical, http://ccil.org/~cowan
epical or dramatic? If a man hacking in fury
at a block of wood make there an image of a cow,
is that image a work of art? If not, why not? --Stephen Dedalus
John Cowan
> WG1, do we have a mechanism to make such quick decisions?
A deliberative assembly may pass any motions it wants to by a majority
of the legal votes cast, unless its bylaws or standing rules say otherwise.
The usual procedure is to set a time by which votes must be in.
The chair may overrule me on this -- in which case his action is subject to
appeal on the motion of any member, likewise settled by a majority vote.
John Cowan, parliamentarian
--
John Cowan co...@ccil.org http://www.ccil.org/~cowan
Most people are much more ignorant about language than they are about
[other subjects], but they reckon that because they can talk and read and
write, their opinions about talking and reading and writing are as well
informed as anybody's. And since I have DNA, I'm entitled to carry on at
length about genetics without bothering to learn anything about it. Not.
--Mark Liberman
Alex Shinn
>> I propose that WG2 take on supporting a keyword arguments feature, and
>> WG2 make requests to WG1 to provide any necessary accommodations.
>
> I counterpropose that WG1 reach a quick decision to ask WG2 not to choose a
> keyword notation that restricts symbol space, e.g., they could choose #:foo.
> This would be in the nature of an amendment to the (notional) motion to
> have keywords, i.e., we would not have to express an opinion about whether
> WG2 should have keywords at all, just about what notations they shouldn't
> choose.
We don't actually need to make any such request, since the
WG2 charter requires that any valid WG1 program be a valid
WG2 program. If :foo and foo: are symbols in WG1, they must
be symbols in WG2.
Of course, this could still work if WG2 keywords were in
fact symbols, and thus usable as identifiers. But in
addition to syntactic differences, implementations seem to
disagree greatly on the actual semantics of keywords.
In both Chicken and Kawa, keywords are semantically a
special type of self-quoting symbol. symbol? returns #t for
them, and you can bind values to them with define (but then
not be able to access those values directly).
In the other implementations, keywords are fully disjoint
from symbols.
In PLT unquoted keywords are not first-class:
> (list #:foo)
stdin::0: application: missing argument expression after keyword at: #:foo in: (#%app list #:foo)
> (list #:foo #t)
list: does not accept keyword arguments; arguments were: #:foo #t
You need to quote them:
> (list '#:foo)
(#:foo)
These semantic differences seem much more problematic than
any syntactic concerns.
--
Alex
Neil Van Dyke
Brian Harvey <b...@cs.berkeley.edu> writes:I propose that WG2 take on supporting a keyword arguments feature, and WG2 make requests to WG1 to provide any necessary accommodations.I counterpropose that WG1 reach a quick decision to ask WG2 not to choose a keyword notation that restricts symbol space,
We don't actually need to make any such request, since the WG2 charter requires that any valid WG1 program be a valid WG2 program. If :foo and foo: are symbols in WG1, they must be symbols in WG2.
I agree that WG1 is not required to make such a pre-emptive decision, since the onus for compatibility is on WG2, and WG2 has not made the request.
If WG2 does request that WG1, say, permit or require ":foo" be read as a keyword rather than as a symbol, WG1 may decide to respond "Sorry, no."
In PLT unquoted keywords are not first-class:
Alex Shinn
> I think it is the place of WG2 or WG1 to get past these slightly
> different ways of doing keywords, and provide a standard keyword
> feature that all Schemes have the option of moving to.
We should not confuse the concept of named argument APIs
with a new disjoint keyword type. I agree that in certain
cases a named argument API can be easier to use than the
alternatives of positional arguments or composition. I
disagree that we need a new type - symbols work just fine.
If you consider 'foo: it provides the best of both worlds in
the typical arguments of prefix vs suffix. The actual
prefix _does_ indicate the type of the literal (symbol) - a
typical argument on the pro-prefix side. The suffix, on the
other hand, fits more naturally with natural language use,
and also hints at the semantics of the identifier (a named
parameter), paralleling the other punctuation suffixes ! and
?.
It's also the same length as the only likely alternative
#:foo and doesn't require any new procedural keyword API.
--
Alex
Neil Van Dyke
> We should not confuse the concept of named argument APIs with a new disjoint keyword type.
Agreed. I retract the implication that a disjoint keyword type is
necessarily required, although we might decide it is appropriate.
> I agree that in certain cases a named argument API can be easier to use than the alternatives of positional arguments or composition. I disagree that we need a new type - symbols work just fine.
>
So that we are all talking about the same things, I think we need clear
definitions of how named arguments would work when the names are given
in syntax, and how they would work with the "apply" procedure.
We could conceivably start by defining named arguments only in terms of
"apply". If we did that, I would suggest considering the implications
for ambiguity (e.g., by requiring named arguments to follow only a fixed
number of positional arguments, and to be name-single-value pairs).
> If you consider 'foo: it provides the best of both worlds in the typical arguments of prefix vs suffix. The actual prefix _does_ indicate the type of the literal (symbol) - a typical argument on the pro-prefix side. The suffix, on the other hand, fits more naturally with natural language use, and also hints at the semantics of the identifier (a named parameter), paralleling the other punctuation suffixes ! and ?.
I'm sympathetic to this argument, but I'd personally tend to defer this
until we determined the nature and syntax of named arguments. (For one
example, we might *conceivably* find that we self-evaluating keyword
objects or magical self-quoting symbols, and that might conceivably have
implications for the appearance of the argument names.)
Aaron W. Hsu
wrote:
> What I see is that Schemes people use for real work tend to *have*
> keywords.
Chez does not have them explicitly, but I would say that it does *enable*
them. In fact, I'll go so far as to say any R6RS implementation enables
keywords.
> I'd like to see WG2 support keywords.
I'm certainly not opposed to them provided that they do not do so in an
overly complicated way. Most particularly, I am against adding a new
reader syntax to support them, and I'm also against eliminating the symbol
space, which would have ramifications for WG1. More specifcally, there is
no reason to eliminate the symbol space so drastically when you really
only need to restrict it in select cases, which can be done with bindings.
Additionally, there's no need for a reader syntax, which ends up being a
little ugly, when the real reason, IMO, that you want a reader syntax is
disjointness from symbols, which records give you.
> I'd like to see WG1 permit WG2 to use keywords, and perhaps support
> their use in syntax definition forms, but not necessarily otherwise use
> keywords.
In a sample of keywords that I have given on
<http://trac.sacrideo.us/wg/wiki/KeywordArgumentsArcfide>, you can see
that WG1 can support keywords by pretty much doing nothing special.
Records with opaqueness and a module system suffice. The code is just an
example of how things might work, it does almost no error checking and
very little to support nice things, but it demonstrates the point.
This is similar to the idea of auxilary keywords in R6RS.
> I'd suggest supporting only one keyword read form, which is also the
> print form.
I think we needn't bother worrying about a read form or write form at all
specifically for keywords.
> I'd lean towards ":foo" keyword form, partly for historical reasons,
> partly because it's not a bad choice. "foo:" form does look cooler when
> used as a label followed by a value, but un-cooly misleading when it is
> used for other purposes. (I have had to use "#:foo" a lot lately, and
> it's unpleasant both to look at and to type, even though I do like that
> it avoids seizing some of the R5RS symbol namespace.)
In the above proposal, you can choose the convention you want in a
portable way and you don't seize more of the symbol space than you use.
Aaron W. Hsu
--
A professor is one who talks in someone else's sleep.