[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

simple ?= 1-line multiline, redux

several times on this list we went over the question:  should a
single-line multiline argument be considered equivalent to a simple
argument?  for example:

  #$#x-foo 12345 bar: quux

  #$#x-foo 12345 bar*: "" _data-tag: 5
  #$#* 5 bar: quux

some of us (including me) argued that these should be considered
different; our MOO implementation represents the first value as "quux"
and the second as {"quux"}.  others argued that they should be
considered identical; a MOO implementation obeying this guideline
might represent both values as {"quux"}.

it was suggested by a few people but i think never quite spelled out
or agreed upon on the list that we could allow both interpretations to
coexist peacefully if we ensured that the difference never actually
_mattered_, and that this could be done if we declared that the same
message couldn't accept both types of argument.  if the x-foo protocol
declares that 'bar' is a simple argument, then there is no ambiguity
in interpreting the type of the argument, no matter which strategy is

(it's not sufficient to formalize this concept based on the concept of
"the same message".  for example, the mcp-cord message takes variable
arguments depending on the cord type and the message argument.  it
wouldn't be appropriate to specify in the definition of mcp-cord which
arguments are to be multiline and which are to be simple.)

another approach is to insist that bar: and bar*: do not specify the
same argument with different _types_, but that they are actually
separate arguments.  if this is true, then a message could
theoretically have both a bar and a bar* argument with separate

unfortunately, i don't think any of these positions is made clear in
the spec.  if it is, can anyone point it out to me?

given this ambiguity and the possible of multiple implementation
strategies, i think the best solution is for package developers to
take a defensive approach, and refrain from specifying packages such
that the same argument can be either simple or multi-line and have
different semantics depending on type.  perhaps we should put a note
to this effect somewhere near the spec.