Re: [scheme-reports-wg2] keyword arguments
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
Brian Harvey
> 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.)
+1 to #:foo if we have to have keywords at all, in either WG. If WG2 picks
one of the other forms, that will put pressure on WG1 to /allow/
implementations to restrict symbol space for compatibility with WG2, and
I hate having to stand on my head to turn :foo back into a symbol (by
rebinding SYMBOL? among other things) in order to get my "Logo interpreter
in Scheme" programming project for Chapter 4 to work in STk.
My preference would be to do without this non-jewel-like feature in either
WG, instead finding ways to accomplish the purposes of keywords using plain
old symbols.
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
John Cowan
> > 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):
>
> The list omits SRFI-88, which addresses this problem.
The only other implementation supporting SRFI 88 is STklos, which is not
one of the implementations I test on. So I have added STklos to those
which support foo: style.
--
John Cowan
co...@ccil.org
I am a member of a civilization. --David Brin
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.
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
Brian Harvey
> 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.
WG1, do we have a mechanism to make such quick decisions?
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
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.)
Brian Harvey
> WG2 charter requires that any valid WG1 program be a valid
> WG2 program.
Yes, but...
>> WG2 make requests to WG1 to provide any necessary accommodations.
I am trying to nip this in the bud, by influencing WG2 away from any
such requests. I can easily envision a situation (akin, imho, to Aaron's
proposal about case folding) in which we are asked to be agnostic about
the symbolhood of foo: and/or :foo, but rather to require some mode,
settable by a parameter no doubt, that's R5 compatible.
I'm against modes. Absent /very/ compelling WG1ish reasons to the contrary,
I want every legal R5 interaction to be a legal WG1 interaction with the
same meaning, without adding flags and worrying about the scope of the flags.
(Flags aren't jewel-like.)
Brian Harvey
+1. In WG2.
Neil Van Dyke
> I am trying to nip this in the bud, by influencing WG2 away from any such requests.
This is possible due to stuffing the two working groups into the same
room: before WG2 has had a chance to work out a design and rationale,
WG1 would be pre-empting lines of thought. This might be a bug or a
feature.
> I want every legal R5 interaction to be a legal WG1 interaction with the same meaning, without adding flags and worrying about the scope of the flags.
I think that flags like you mention are headaches in general, and would
be especially distasteful in the WG1 language.
Alaric Snell-Pym
:
> Based on this sparse set of implementations and hopeless lexical-syntax
> tangle, I'd be against supporting keywords in either WG1 or WG2.
+1. They're useful, but never in a show-stopping way. I'm not sure if
many or any implementations implement them more efficiently than just
passing an alist.
However, if we do standardise them, then I'd be tempted to suggest we
standardise that :foo, foo: and #:foo are all equivalent and identical,
to minimise the breakage of existing code (sorry, Scheme 7 ;-)
ABS
--
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/
Alaric Snell-Pym
> (Flags aren't jewel-like.)
+1
Neil Van Dyke
> However, if we do standardise them, then I'd be tempted to suggest we
> standardise that :foo, foo: and #:foo are all equivalent and
> identical, to minimise the breakage of existing code (sorry, Scheme 7 ;-)
I suggest we standardize one format only. Various Schemes implementing
WG1/WG2 keywords might choose to provide backward-compatibility for
their own legacy keywords in various ways. Common Lisp people would
laugh at us if we bloat the Scheme spec with supporting three different
keyword formats for legacy compatibility alone.
Alaric Snell-Pym
Yeah, my rationale isn't so much legacy compatability; that arises as a
natural consequence of just allowing synonymous use on the grounds that
it's a stylistic choice, like whitespace (or case? :-). Something like
"A symbol's a symbol unless it has some colons somewhere in it, in which
case it's a keyword whose name is the name without the colons" - and
some special case for #: perhaps.
Brian Harvey
> standardise that :foo, foo: and #:foo are all equivalent and identical,
> to minimise the breakage of existing code (sorry, Scheme 7 ;-)
An emphatic -1. Even in WG2, our charter is not to produce Common Scheme.
If we are going to take some mechanical accumulation over all existing
implementations, then the accumulation function should be intersection,
not union!
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.
David Rush
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.
GPG Public key at http://cyber-rush.org/drr/gpg-public-key.txt
David Rush
Brian Harvey wrote at 03/18/2010 11:03 PM:This is possible due to stuffing the two working groups into the same room: before WG2 has had a chance to work out a design and rationale, WG1 would be pre-empting lines of thought. This might be a bug or a feature.
I am trying to nip this in the bud, by influencing WG2 away from any such requests.
Aaron W. Hsu
>
> > 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.
>
> That's a cute trick :) Next!
Could you clarify what you intend to mean by this statement? Do you
approve or disapprove of the above strategy? If you disapprove,
what technical grounds do you have for disapproving?
The main points of that page are:
1) To discourage the idea of restricting the symbol space to
eliminate a large range of symbols for a specialized purpose.
without need.
2) To discourage the use of excessive reader syntax extensions.
3) To encourage a less complicated and imposing approach to keywords.
Aaron W. Hsu
David Rush
> On 20 March 2010 04:21, Aaron W. Hsu <arc...@sacrideo.us> wrote:Could you clarify what you intend to mean by this statement?
>
> > 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.
>
> That's a cute trick :) Next!
Do you approve or disapprove of the above strategy?
Code Poet.
Alaric Snell-Pym
> The main points of that page are:
>
> 1) To discourage the idea of restricting the symbol space to
> eliminate a large range of symbols for a specialized purpose.
> without need.
> 2) To discourage the use of excessive reader syntax extensions.
> 3) To encourage a less complicated and imposing approach to keywords.
Peter Bex (via IRC) pointed out one downside of this approach, though -
you would need to export all the keyword symbols from a library, and
import them where needed, which could get tedious.
John Cowan
> Peter Bex (via IRC) pointed out one downside of this approach, though -
> you would need to export all the keyword symbols from a library, and
> import them where needed, which could get tedious.
I thought of that, but I decided that it's actually a virtue: the keywords
recognized by a procedure are part of its interface, and really *should*
be explicitly exported. For that matter, it becomes possible to export
only a subset of them, allowing internal module-local keywords vs. public
keywords. The logic is the same as for syntactically defined records:
you have to export the constructor(s), predicate, accessors, and mutators
individually -- you can't just "export the record" -- but by the same
token you don't have to export all of them.
In addition, KEYWORD=? has an indirection in it which makes it slightly
slower than EQ?. This is necessary because every time you write
DEFINE/OPTIONAL with the same set of keywords, the keyword variables
are rebound to new keyword objects which are not EQ? to the ones defined
before -- but they are KEYWORD=?, so all is well.
--
The Unicode Standard does not encode John Cowan
idiosyncratic, personal, novel, or private http://www.ccil.org/~cowan
use characters, nor does it encode logos
or graphics. co...@ccil.org
Arthur A. Gleckler
> I thought of that, but I decided that it's actually a
> virtue: the keywords recognized by a procedure are part of
> its interface, and really *should* be explicitly
> exported. For that matter, it becomes possible to export
> only a subset of them, allowing internal module-local
> keywords vs. public keywords. The logic is the same as
> for syntactically defined records: you have to export the
> constructor(s), predicate, accessors, and mutators
> individually -- you can't just "export the record" -- but
> by the same token you don't have to export all of them.
Still, if we go this way, it would be nice if the module
system made it easy to export a procedure and all its
keywords as a group. But how would the module system even
name them if keywords of the same name are distinct across
procedures?
John Cowan
> Still, if we go this way, it would be nice if the module
> system made it easy to export a procedure and all its
> keywords as a group.
The whole point of this idea is to make keywords Just Work in R5RS,
without needing any special magic.
> But how would the module system even name them if keywords of the same
> name are distinct across procedures?
They are distinct in the sense of EQ?, but the same in the sense of
KEYWORD=?, and the latter is what counts. However, it *is* a problem
for module systems which insist on making imported identifiers immutable.
--
John Cowan co...@ccil.org http://ccil.org/~cowan
"The exception proves the rule." Dimbulbs think: "Your counterexample proves
my theory." Latin students think "'Probat' means 'tests': the exception puts
the rule to the proof." But legal historians know it means "Evidence for an
exception is evidence of the existence of a rule in cases not excepted from."
Aaron W. Hsu
> > I thought of that, but I decided that it's actually a
> > virtue: the keywords recognized by a procedure are part of
> > its interface, and really *should* be explicitly
> > exported. �For that matter, it becomes possible to export
> > only a subset of them, allowing internal module-local
> > keywords vs. public keywords. �The logic is the same as
> > for syntactically defined records: you have to export the
> > constructor(s), predicate, accessors, and mutators
> > individually -- you can't just "export the record" -- but
> > by the same token you don't have to export all of them.
I think it would be good to point out that we don't have to go in
quite the way I suggested. Firstly, the indirection in 'keyword=?'
breaks the close relation this model has to auxilary keywords for
macros. Another option is to actually use object identify with
direct 'eq?' instead of a symbolic equality of an internal name.
You could actually simulate this using something like 'gensym',
though.
> Still, if we go this way, it would be nice if the module
> system made it easy to export a procedure and all its
> keywords as a group. But how would the module system even
> name them if keywords of the same name are distinct across
> procedures?
You'll note that in my module proposal, I suggest that we provide
at least 'co-export' and 'indirect-export', which provide for this
behavior. At the moment, keywords are not necessarily distinct
across procedures, since you can create two procedure keywords of
the same internal name and they can be used interchangeably. I don't
know if this is a good thing or not, yet.
All in all, I suggest that this be a good reason to motivate
the 'co-export' form, rather than something we should standardize
in Working Group 1. I think it's better to standardize this in
working group 2, but allow for this sort of flexibility through
'co-export' in working group 1.
Aaron W. Hsu
John Cowan
> Another option is to actually use object identify with direct
> 'eq?' instead of a symbolic equality of an internal name. You could
> actually simulate this using something like 'gensym',
The trouble there is that if multiple modules define the same keyword,
who gets to create the unique object? In existing keyword systems,
all keyword objects are in effect pre-created by the implementation,
because my foo: (or :foo) is always EQ? to yours.
> At the moment, keywords are not necessarily distinct across procedures,
> since you can create two procedure keywords of the same internal name
> and they can be used interchangeably.
If you define your procedures with DEFINE/OPTION, they are *always*
distinct (in the sense of EQ?) between two different procedures.
--
As you read this, I don't want you to feel John Cowan
sorry for me, because, I believe everyone co...@ccil.org
will die someday. http://www.ccil.org/~cowan
--From a Nigerian-type scam spam
Aaron W. Hsu
>
> > Another option is to actually use object identify with direct
> > 'eq?' instead of a symbolic equality of an internal name. You could
> > actually simulate this using something like 'gensym',
>
> The trouble there is that if multiple modules define the same keyword,
> who gets to create the unique object? In existing keyword systems,
> all keyword objects are in effect pre-created by the implementation,
> because my foo: (or :foo) is always EQ? to yours.
We could do this like Auxilary keywords and make them be defined
separately, but this makes things a little less convenient for things
like anonymous procedures that take optional arguments. Whether we
want to support such a thing or not is debatable.
Currently, I have keyword=? defined such that it doesn't check the
EQ?-ness of the identifiers, but of their internal names. If two
procedures define the same keywords, but under different names,
even if they are separate objects, and not EQ?, they may still be
KEYWORD=?. I don't know if this is a good idea or not.
> > At the moment, keywords are not necessarily distinct across procedures,
> > since you can create two procedure keywords of the same internal name
> > and they can be used interchangeably.
>
> If you define your procedures with DEFINE/OPTION, they are *always*
> distinct (in the sense of EQ?) between two different procedures.
Why? At the moment if you define two different procedures, and you
use the same keyword names, you'll end up with unique keyword
objects, but those objects will be interchangeable. Actually, unless
you take pains to ensure that the names really are wrapped differently,
then there will be a definition collision rather than just having
unique keywords. This is the same issue you can have with auxilary
keywords in macros.
Aaron W. Hsu
Aaron W. Hsu
> for module systems which insist on making imported identifiers immutable.
How is it a problem?
Aaron W. Hsu
John Cowan
> We could do this like Auxilary keywords and make them be defined
> separately, but this makes things a little less convenient for things
> like anonymous procedures that take optional arguments. Whether we
> want to support such a thing or not is debatable.
Anonymous keyword procedures? Very useful. Right up there with local
generic functions in CL.
> Currently, I have keyword=? defined such that it doesn't check the
> EQ?-ness of the identifiers, but of their internal names.
[snip]
> > If you define your procedures with DEFINE/OPTION, they are *always*
> > distinct (in the sense of EQ?) between two different procedures.
>
> Why? At the moment if you define two different procedures, and you
> use the same keyword names, you'll end up with unique keyword
> objects, but those objects will be interchangeable.
That's what I said: distinct objects, but interchangeable because they
are KEYWORD=?.
--
I don't know half of you half as well John Cowan
as I should like, and I like less than half co...@ccil.org
of you half as well as you deserve. http://www.ccil.org/~cowan
--Bilbo
John Cowan
> > However, it *is* a problem
> > for module systems which insist on making imported identifiers immutable.
>
> How is it a problem?
Because if I import a keyword like :test from two different modules, it
has two different definitions. In a system where imports can override
previous imports, this isn't an issue; but if they cannot, as in R6RS,
the user must carefully exclude one set or the other. Messy.
--
Business before pleasure, if not too bloomering long before.
--Nicholas van Rijn
John Cowan <co...@ccil.org>
http://www.ccil.org/~cowan
Aaron W. Hsu
> are KEYWORD=?.
Ah, sorry, I misunderstood. What I am also thinking about is changing
this to use enumerations instead of record types, and to use identifier
syntax instead of keyword=?. These identifier's would generate symbols
for use, and they would or could be checked against their enumeration
worlds. On the other hand, this has the problem of not quite having the
type disjointness that I want.
Aaron W. Hsu
Aaron W. Hsu
>
> > > However, it *is* a problem
> > > for module systems which insist on making imported identifiers immutable.
> >
> > How is it a problem?
>
> Because if I import a keyword like :test from two different modules, it
> has two different definitions. In a system where imports can override
> previous imports, this isn't an issue; but if they cannot, as in R6RS,
> the user must carefully exclude one set or the other. Messy.
Renaming and prefixing alleviates this problem to a large extent.
Nonetheless, I think that the design needs some tweaking to make it
really usable.
Aaron W. Hsu
Alex Shinn
> Arthur A. Gleckler scripsit:
>
>> Still, if we go this way, it would be nice if the module
>> system made it easy to export a procedure and all its
>> keywords as a group.
>
> The whole point of this idea is to make keywords Just Work in R5RS,
> without needing any special magic.
Don't forget that symbols Just Work in R5RS without needing
any special magic.
--
Alex