[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