[plt-scheme] keywords (a backward-incompatible change)

My 2 bits on this....


I don't really care much about them, as I don't plan to use them, but if
"forced to use libraries that depend on keywords" means that they'll show up
in the API of the libs, I see this as a bad thing. Plus if people who have
not seen this discussion will have to insert #k- when writing R5RS code, and
the reason for the #k- is not obvious, that'd also be bad.

So at this point I'm againt it. I'm looking for the value though. If the
motive is to do something like:

> (send-mail From: "Dr. Watson <guest at grimpen.moor>"
> To: "Sherlock Homes <not-really at 221B-baker.street>"
> Subject: "First Report"
> Charset: "ISO-8859-1"
> Body: "Moor is gloomy. Heard strange noise, attached."
> Attachments: '((File: "howl.ogg")))


This could be done in R5RS like:

(send-mail `(From: ,"Dr. Watson <guest at grimpen.moor>")
`(To: ,"Sherlock Homes <not-really at 221B-baker.street>")
`(Subject: ,"First Report")
`(Charset: ,"ISO-8859-1")
`(Body: ,"Moor is gloomy. Heard strange noise, attached.")
`(Attachments: ,'((File: "howl.ogg"))))

And with a wrapper macro could become:

(send-mail [From: "Dr. Watson <guest at grimpen.moor>"]
[To: "Sherlock Homes <not-really at 221B-baker.street>"]
[Subject: "First Report"]
[Charset: "ISO-8859-1"]
[Body: "Moor is gloomy. Heard strange noise, attached."]
[Attachments: '((File: "howl.ogg"))])

So it seems that we've saved 2 charactors (the #\[ and #\]) for a keyword,
but technically we don't need the #\: anymore. So if we are looking for
keystroke savings there is some, but that can't be what this is all about.

Matt mentions standardization, which is a good thing, but we could just
write a notation style. I wonder if there's any kind of hint that could be
added as warning message to the interpreter/compiler...

Is there any need for keywords outside of pattern matching in syntactic
forms that i'm not seeing?

If it does happen, remember to change the drscheme parser to color the
keywords differntly to show that they are special, and not normal syntax.


Corey


On 10/1/05, Matthew Flatt <mflatt at cs.utah.edu> wrote:
>
> With version 299.403, we plan to add keywords to MzScheme. Keywords are
> self-quoting, symbol-like values that can be used for keyword-based
> optional arguments.
>
> For now, we've settled on colon-prefixed keywords --- which means that
> a symbol or identifier can't start with an unquoted colon:
>
> (keyword? :a) ; => #t
> (eq? :a ':a) ; => #t
> (keyword? ':a) ; => #t
> (keyword? 'a) ; => #f
> (keyword? ':|a b|) ; => #t
> (keyword? '|:a b|) ; => #f
> (keyword? :) ; => #t
>
> (symbol? :a) ; => #f
> (symbol? :) ; => #f
>
> (lambda (:x) 10) ; => syntax error: :x is not an identifier
>
>
> Pros:
>
> * Self-quoting keywords support keyword-based optional arguments with
> a relatively standard syntax.
>
> * Syntactic forms can also use keywords, and pattern matching "just
> works". Using keywords can help clarify when a syntactic form
> expects to match literals (e.g., the colon in a `compound-unit/sig'
> form) versus bindings (e.g., `quasiquote' in a `match' pattern).
>
> * Some people like the idea of keywords, and they'll put them to good
> use.
>
> Cons:
>
> * R5RS allows a colon at the beginning of a symbol/identifier, and
> some of our code uses identifiers that start with a colon. Adding
> keywords of this form is a significant backward-incompatible change.
>
> * Some people dislike the idea of keywords, and they'll be forced to
> use libraries that depend on keywords.
>
> To help port code, `#k-' can be used in front of an S-expression to
> disable keywords, just like `#ci' selects case-insensitive parsing. For
> example, if a module uses colon-prefixed identifiers/symbols and the
> module does not need keywords, then it can be prefixed with `#k-'.
> Naturally, `#k+' would enable keyword parsing, so `#k+:apple' is always
> the keyword `:apple'.
>
>
> Assuming that we add keywords to MzScheme, a MzLib library will quickly
> follow for defining procedures with keyword-based arguments. MzScheme's
> built-in `lambda' and `case-lambda' will not change.
>
>
> Among the people that I've polled so far, this plan has been relatively
> uncontroversial; discussion quickly turns to the best uses keywords,
> instead of whether they should exist or how they should be written. So
> I'm broadening the poll here...
>
> Opinions?
>
>
> Matthew
>
> For list-related administrative tasks:
> http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20051002/3b30a6c4/attachment.html>