[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[philosophy] Re: fixes to the grammar
> so, i've made some requested changes; specifically:
> - #$#END for multiline values is replaced by the #$#: message;
> added a short paragraph explicitly mentioning that this is
> sent after the complete value.
> - changed the references to 'multiline-value' (#$#*) lines
> to say 'continuation'.
I've reached the consensus-by-exhaustion point for multiline
messages, so I don't really care.
> - fixed three grammar bugs, one which permitted idents to be the
> empty string, one which forced quoting of colons, and one
> which was just plain weird.
I started writing a rant about how quoting colons was a good thing
(put down the qooc, guys) until I realized that what you meant by
this was that you no longer needed to write "\:" and could just write
":". That's fine with me; in fact it's a fix for something I mention
below.
After being out of touch for a week, I feel I might as well try to
summarize lingering doubts I have with statement of a general, fuzzy
desire of mine for this spec:
When possible, reuse common concept space from other languages; maybe
you can then reuse infrastructure too.
Boy, that's fuzzy. Let me illustrate.
By an *amazing* coincidence, our choice of "word" boundaries happens
to be compatible with the conventions (and readers!) of a lot of
languages. If you handed
from: "\"Jay A. Carlson\" <nop@nop.com>" to: "mcp development list
<mcp-dev@research.att.com>" subject: ranting
to MOO, Tcl, Scheme, /bin/sh, perl, M3's Sexp module etc, readers,
they'd all agree on how to tokenize it. This not only is a valid
implementation strategy (well, modulo some lisp typedness) but it
makes MCP's tokenization feel "intuitive" to a lot of people.
Given this tokenization, I think there are a few different plausible
ways to implement keyword/value pairs that feel "right" to most
people.
One obvious one is the "foo=bar baz" suggested by one of the MCP 2.0
specs; one conceptual disadvantage to this (and the similar "foo:bar
baz") is that you have to go mucking about inside strings *after* the
first cut lexing to get the values out.
The MCP 1.0 style we know and love of keyword: value is the other
major contender, and certainly is existing practice in lots of
languages. The mindset of "just like smalltalk et al" is what argues
against foo* and omitted values; it doesn't hurt that often you'll
have most of the keyword/value=>dictionary code lying around from
other projects.
(Come to think of it, another possible way of phrasing "keyword:
value" is "-keyword value" which is surely more familiar to those of
a /bin/sh and Tcl bent, but dammit, I'm a Smalltalk bigot. Yeah,
Smalltalk except all the values are strings. Yeah.)
OK, I'm running out of time. I have a Stars! turn to submit, and a
plane to catch. One last thought.
I'd like to see multiline bodies be phrased purely in terms of single
line messages, and multiline messages called out as a separate layer.
I think a good number of people are going to punt multiline messages
for their system and it seems silly to have two different BNFs if
multiline can just be another layer on top of the "core" MCP message
functionality.
Let's just hope I can get email working on my Pilot again so this
isn't a drive-by philosophy lecture.
Jay