Re: [MIT-Scheme-devel] Keywords
Date: Fri, 19 Mar 2010 12:03:35 -0700 From: Joe Marshall jmarsh...@alum.mit.edu The tokens `:yes' and `:no' don't need quoting or unquoting or any careful attention to what level of expansion they will be quoted at. They are just literal symbolic tokens that get no special treatment by the evaluator just because they are symbols. As I said before, one could do without keywords and just use symbols, and then you'd have to think a bit harder about which ones to quote and unquote at which level, but you could do it. It is just a convenience. But then, LET is simply a trivial convenience over using LAMBDA. When you're writing the macro you need to decide what its evaluation rules are. You can defer parts of that decision to some other operator by passing subforms of the input to an invocation of the other operator. Introducing self-evaluating symbols doesn't make the decision any easier or more convenient, however. It only makes certain uses of macros independent of that decision. I still don't buy it, and I'm afraid I got lost in your example -- there were about a dozen keywords involved, and it was not clear to me which ones needed to be self-evaluating objects and how that had anything to do with how much quoting and unquoting you needed to write in your macro. I agree that your macro looked hairy, but its hairiness was unrelated to the use of keywords with ECASE. ___ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
Re: [MIT-Scheme-devel] Keywords
From: Taylor R Campbell campb...@mumble.net Date: Tue, 16 Mar 2010 02:23:51 -0400 What advantage does a disjoint data type have over writing (foo 'bar: baz 'quux: zot)? [It] strikes me as needless complication to the language. I agreed with you for very many years, but a few years back I changed my mind. I'll try to show you why. Using keyword objects rather than (non-keyword) symbols as the arguments to keyword parameters makes sense in Common Lisp only because of its package system. It certainly arose that way. The package system started out as a hack to allow different unrelated Lisp applications to share the same image without interfering with each other. The problem is that symbols are heavily overloaded in old lisp systems. In the earliest lisp, a symbol had an associated `property list' which stored everything you needed to know about a symbol. This even included the symbol's `value' property and possibly its `subr' property (function cell). In this model, a symbol is actually a named set of mappings. The name itself had no ontological significance (it was stored as the 'pname' property), it was just a way of getting ahold of the mapping set. Two different systems would likely make different uses of the properties of a symbol, so trying to load two different systems into the same image wouldn't work. The root cause of this problem is very tricky to understand, and I'll get to it in a moment, but the `obvious' problem appears to be one of aliasing: both System `A' and System `B' refer to symbol `foo', but they aren't referring to the *same thing*. The obvious solution is to give each system a private symbol. Symbols were interned in the obarray, so a hack that allowed you to use multiple obarrays and switch between them was created. The `multiple obarray hack' was the precursor to the `package system'. Although the value and function cells of symbols are firmly entrenched, there has been a shift away from the practice of using property lists. When a symbol is used only as a key in a table, there is less need for collision avoidance. On the other hand, there is an immediate problem that the symbol 'foo' in package A is *not* the symbol 'foo' in package B, even though they look the same. The keyword package comes to the rescue. Keywords are good as `symbolic keys' because they *don't* have values, functions, or properties. You can use them freely without worrying about collisions. So keywords arose as a solution to a problem that was an unintended effect of a solution to an unrelated problem. - Earlier I mentioned that the root cause of the problem was tricky to understand. The cause isn't really one of aliasing unrelated symbols, the cause is a misunderstanding of naming. (Unfortunately, I haven't found a good authority on the issues of naming, so I'm going to fly by the seat of my pants here.) Abstractly, we want to be able to refer to objects by names. We do this by establishing a `context' where names are associated with values. The minimal requirement is that the `name' can be an arbitrary sort of thing (like the word foo) and that the `context' is what provides the mapping. We also desire that the mapping is relatively static unless told otherwise. We do this *all the time* in computer science. The root cause of `symbol collision' is that early lisps were confused. A `symbol' in these lisps is not a name at all, but a very complex sort of beast. At a very early phase in interpreting a program, a symbolic token (like what a user types) is mapped to a `symbol object' via the obarray. Further interaction with the symbol is mediated through the `property list'. A picture of this would sort of look like this: obarray plist symbolic token Symbol ---X Value ^ | Symbol So a symbol *itself* is really a function from another symbol to a value. This part of the picture: plist -X Value ^ | Symbol But that is a terrible idea. What you *want* is the *other* half of the picture: obarray symbolic token Symbol --- And the `symbolic token - Symbol' mapping via the obarray can be considered an implementation detail of the reader, we just want this part: Symbol which, when we later supply a context becomes context Symbol - Value The keyword package in Common Lisp accomplishes this by essentially erasing the components of a symbol that are causing the problems and using the remaining shell as a stand-in for the conceptual symbol. (This last step is beautiful kludge. The original idea of a symbol had all these bells and whistles, but if we plug these holes and
Re: [MIT-Scheme-devel] Keywords
On Tue, Mar 16, 2010 at 2:45 PM, Matt Birkholz m...@birkholz.chandler.az.us wrote: (make-sumpn :color: red) Sorry. Not the last one? ? Ok, I'll fix that. Fixed, sort of. I have removed the `both' option because I couldn't clearly describe what it was supposed to do. I have fixed the escaping of keywords to be just like SRFI-88 describes: In other words, in such implementations, |foo|: and foo: are the same keyword, and |foo:| is a symbol, not a keyword, and ||: is a keyword. 1 ]= (set! *keyword-style* 'suffix) ;Value: #f 1 ]= |foo|: ;Value 12: foo: 1 ]= (keyword? |foo|:) ;Value: #t 1 ]= (eq? foo: |foo|:) ;Value: #t 1 ]= |foo:| ;Unbound variable: foo: ;To continue, call RESTART with an option number: ; (RESTART 3) = Specify a value to use instead of foo:. ; (RESTART 2) = Define foo: to a given value. ; (RESTART 1) = Return to read-eval-print level 1. 2 error (restart 1) ;Abort! 1 ]= (symbol? '|foo:|) ;Value: #t 1 ]= (symbol? ||:) ;Value: #f 1 ]= (keyword? ||:) ;Value: #t 1 ]= (keyword? :color:) ;Value: #t 1 ]= (keyword-string :color:) ;Value 13: :color 1 ]= (transcript-off) I have also restricted the value of *keyword-style* to be either 'prefix, 'suffix, or #f. BTW: I'd like to keep this as an `internal' feature until I figure out the best way to control it. I don't mind if people want to play with it, but they should expect the `keyword-style' switch to change and some other details to change for a bit until I iron this out. No guarantees of stable behavior, but I'd love feedback from users. -- ~jrm ___ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
Re: [MIT-Scheme-devel] Keywords
What advantage does a disjoint data type have over writing (foo 'bar: baz 'quux: zot)? I know I am a relative newcomer to MIT Scheme and thus unqualified to make judgements such as this, but that strikes me as needless complication to the language and system, whose reader is already too complicated. As an aside, on the cosmetics you mentioned: [Trailing-colon keywords] just don't look anywhere near as good when the *values* are keywords, which they often are. (call-with-mumble option: default: name: none:) Using keyword objects rather than (non-keyword) symbols as the arguments to keyword parameters makes sense in Common Lisp only because of its package system. Fortunately Scheme is not afflicted by that mess. ___ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
Re: [MIT-Scheme-devel] Keywords
From: Taylor R Campbell campb...@mumble.net Date: Tue, 16 Mar 2010 02:23:51 -0400 What advantage does a disjoint data type have over writing (foo 'bar: baz 'quux: zot)? I know I am a relative newcomer to MIT Scheme and thus unqualified to make judgements such as this, but that strikes me as needless complication to the language and system, whose reader is already too complicated. I am just hoping this is for SRFI support, not something we would use in our own system... or is this NOT the Old School Scheme congregation? (Ummm... :-)? Can I write (make-sumpn 'color red) as well as (make-sumpn :color red) (make-sumpn color: red) and (make-sumpn :color: red) Sorry. Not the last one? ? ___ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
Re: [MIT-Scheme-devel] Keywords
From: Taylor R Campbell campb...@mumble.net Date: Tue, 16 Mar 2010 02:23:51 -0400 What advantage does a disjoint data type have over writing (foo 'bar: baz 'quux: zot)? I'm writing up a rationale. On Tue, Mar 16, 2010 at 2:45 PM, Matt Birkholz m...@birkholz.chandler.az.us wrote: I am just hoping this is for SRFI support, Not *solely* for SRFI support, but there's no reason to disavow credit. not something we would use in our own system... I don't think I'd impose this on anyone else. I have an interesting use-case in mind, but I'm not about to start adding them willy-nilly to the existing code base. or is this NOT the Old School Scheme congregation? (Ummm... :-)? I certainly consider myself part of the `Old School'. (Despite accusations!) Can I write (make-sumpn 'color red) as well as (make-sumpn :color red) (make-sumpn color: red) and (make-sumpn :color: red) Sorry. Not the last one? ? Ok, I'll fix that. -- ~jrm ___ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
Re: [MIT-Scheme-devel] Keywords
This should be a per-file option; it's a syntactic hack. Instead of having a global option, invent some kind of # syntax to say what the keyword syntax is. This is how case sensitivity should be handled as well, IMO. On Mon, Mar 15, 2010 at 3:00 PM, Joe Marshall jmarsh...@alum.mit.edu wrote: I've added `keyword' objects to MIT Scheme in a way that I hope keeps everyone happy. A keyword is a self-evaluating symbolic token, much like a symbol, but it never needs quoting because it can never mean anything but itself. The reading and printing of keywords is controlled by the variable *keyword-style*, which can be #f or one of these symbols: cl, dsssl, srfi-88, both If *keyword-style* is #F (the default), then there is no way to read keywords, and they are printed as #[keyword foo]. If *keyword-style* is 'cl, then tokens with a leading colon are considered keywords and keywords are printed with a leading colon. Symbols with a leading colon are printed with vertical-bar quotes and you can create symbols with leading colons by using vertical-bar quotes. If *keyword-style* is 'srfi-88, then tokens with a trailing colon are considered keywords and keywords are printed with a trailing colon. Symbols with a trailing colon are printed with vertical-bar quotes and you can create symbols with trailing colons by using vertical-bar quotes. 'dsssl is a synonym for 'srfi-88 If *keyword-style* is 'both, then either syntax is acceptable for reading, but the cl syntax will be used in printing. (Putting a colon on both ends would be weird, so don't.) The way quoting is currently implemented on symbols makes it hard to determine if the quotation occurs before or after the first character or the final character, so non-standard keywords like :|a weird keyword| end up being interpreted as symbols. rationale: I find these things to be very pragmatic for use in large, complex systems. I prefer the Common Lisp style with the leading colon because it is easier to see the keywords. The trailing colon syntax is cute, but the nifty examples that are shown, like this: (tcltk-frame relief: 'ridge borderwidth: 4 height: 50px width: 100px) just don't look anywhere near as good when the *values* are keywords, which they often are. (call-with-mumble option: default: name: none:) The PLT syntax of #:key is just plain stupid. -- ~jrm ___ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org http://lists.gnu.org/mailman/listinfo/mit-scheme-devel ___ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
Re: [MIT-Scheme-devel] Keywords
On Mon, Mar 15, 2010 at 3:14 PM, Chris Hanson c...@chris-hanson.org wrote: This should be a per-file option; it's a syntactic hack. Do we have a per-file marker mechanism? Instead of having a global option, invent some kind of # syntax to say what the keyword syntax is. This is how case sensitivity should be handled as well, IMO. The problem with handling case-sensitivity this way is that you want to close calls to READ over the sensitivity at the call site. (I found this out when PLT scheme switched to case-sensitive. I went and added the magic # syntax to my files and discovered that it didn't fix the problem. Calls to read were being case-sensitive. It occurred to me that if I'm writing insensitive code, I probably want READ to be insensitive, too. (or if it was legacy code, that I'd be expecting the old behavior). -- ~jrm ___ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
Re: [MIT-Scheme-devel] Keywords
In which case READ should be told what it is supposed to do, or the thing you're reading should also be marked. The syntax marker isn't a per-file marker, it's a marker of an input stream. READ should have defaults that it uses in the absence of any stream markers. And no, there isn't currently a standard mechanism for doing any of this. But there should be. Want to implement one? On Mon, Mar 15, 2010 at 4:13 PM, Joe Marshall jmarsh...@alum.mit.edu wrote: On Mon, Mar 15, 2010 at 3:14 PM, Chris Hanson c...@chris-hanson.org wrote: This should be a per-file option; it's a syntactic hack. Do we have a per-file marker mechanism? Instead of having a global option, invent some kind of # syntax to say what the keyword syntax is. This is how case sensitivity should be handled as well, IMO. The problem with handling case-sensitivity this way is that you want to close calls to READ over the sensitivity at the call site. (I found this out when PLT scheme switched to case-sensitive. I went and added the magic # syntax to my files and discovered that it didn't fix the problem. Calls to read were being case-sensitive. It occurred to me that if I'm writing insensitive code, I probably want READ to be insensitive, too. (or if it was legacy code, that I'd be expecting the old behavior). -- ~jrm ___ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
Re: [MIT-Scheme-devel] Keywords
On Mon, Mar 15, 2010 at 5:16 PM, Joe Marshall jmarsh...@alum.mit.edu wrote: On Mon, Mar 15, 2010 at 4:57 PM, Chris Hanson c...@chris-hanson.org wrote: In which case READ should be told what it is supposed to do, or the thing you're reading should also be marked. The syntax marker isn't a per-file marker, it's a marker of an input stream. READ should have defaults that it uses in the absence of any stream markers. Wouldn't it be considered metadata? Then an explicit marker would mean that you have in-band metadata (with all the wonderfulness that entails). And how would that wonderfulness affect this situation? What alternative would you propose? ___ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
