Newsgroups: rec.arts.int-fiction
Path: news.duke.edu!newsgate.duke.edu!zombie.ncsc.mil!alnews.ncsc.mil!feed.news.qwest.net!newsfeed.cwix.com!nntp.abs.net!uunet!dca.uu.net!ash.uu.net!world!not-for-mail
From: buzzard@TheWorld.com (Sean T Barrett)
Subject: Re: [TADS] A subtle incompatibility between 2.2 and 2.5.5
Sender: news@world.std.com (Mr Usenet Himself)
Message-ID: <Gu328o.97r@world.std.com>
Date: Fri, 5 Apr 2002 07:02:48 GMT
References: <a7sdvj$2oa$1@news.lth.se> <665b644a.0204030030.7e8d5215@posting.google.com> <Gu1uIx.34C@world.std.com> <y77r8.980$AB3.234097686@newssvr21.news.prodigy.com>
NNTP-Posting-Host: shell01.theworld.com
Organization: The World Public Access UNIX, Brookline, MA
X-Newsreader: trn 4.0-test72 (19 April 1999)
Lines: 93
Xref: news.duke.edu rec.arts.int-fiction:102617

Mike Roberts <mjr_@hotmail.com> wrote:
>"Sean T Barrett" <buzzard@TheWorld.com> wrote:
>> The thing about this is that it's such an inconsistent
>> use of () compared to the other two uses. It makes
>> sense in the sense that if it were somehow meaningful
>> to say obj.5, then if you wanted to say obj.(2+3) you'd
>> need parentheses; but it really doesn't make much sense,
>> I sense.
>
>How about obj.(f(x)), or obj.(other.prop)?  The parens are necessary in just
>about every case involving a property pointer value other than a local
>variable.

The parens are necessary because there is an ambiguity to *grouping*:

    foo.bar(x) could mean:
         (foo.bar)(x)
         foo.(bar(x))
    foo.bar.baz could mean:
         (foo.bar).baz
         foo.(bar.baz)

There is no ambiguous *grouping* in:

    foo.bar could mean
         foo.local-variable-bar
         foo.property-name-bar

and therefore I find it disconcering for
it to be used to arbitraryily pick one of
these.

And really the above could say

    foo.bar could mean
         local-variable-foo.bar
         global-object-name-foo.bar

and I don't see anyone using parentheses
to try to distinguish those two cases.

>Syntax is a matter of taste, of course, but I personally think this use of
>parens *is* entirely consistent with the usual sense (in TADS source code)
>of expression grouping: parens always mean that you should first evaluate
>what's inside them in isolation from any surrounding operators, and then
>plug the result into the surrounding expression.

This is a bit of a stretch to me: parentheses traditionally
control the order of operation, but not the semantics of what
the operators me. Is there any other case where TADS parentheses
require the definition you just gave, rather than the traditional?
This doesn't read to me as "the usual sense", but rather as
"the sense constructed to account for this one special case".
(It's not at all accurate for the *other* use of parentheses,
function application.)

>Well, again, universal agreement on syntax is unlikely, but to me the tads 3
>rule seems too easily stated to seem very hackish: "x.y" *always* means that
>"y" should be interpreted as a property name, and "x.(y)" always means that
>"y" should be interpreted as an expression yielding a property pointer.
>From a usability perspective, I like this better than letting the meaning of
>"x.y" vary according to local context.

Except that 'x' does vary. Perhaps it's just that I've been exposed
to too many various different languages, and I'm over-sensitive
to the vagaries of syntax, but the only way I can form a mental
model of your approach is to think in my head of ".y" as a
special, different-from-everything-else syntax, in which the
identifier binds so tightly to the '.' as to create a new special
operator; it is not "." applies "y" to "x", but rather ".y" is
applied to x. But that is *not* how I think about it, and I do
not think it is how people should be encouraged to think about
it; I think it makes it unecessarily hard for people to then
understand things like "property pointers", which scare them
off from doing useful things.

>property pointer expressions are relatively rare, and usually are somewhat
>subtle in meaning, so I think it's more useful to draw attention to them
>than to draw attention to ordinary property evaluations that happen to be in
>a lexical context with a colliding local variable name.

Among other things, I normally use TADS-esque objects as
hashes/dictionaries--as a bucket into which you can stick
arbitrary <name, value> pairs. The keys are property pointers,
and hence they're not "relatively rare" or "subtle in meaning"
at all; normally all interesting constants that aren't numeric
are property pointers, and they get flung around all over the
place.  So I lean heavily in the direction of making people
familiar with and comfortable with them.

So, agree to disagree, I guess.

SeanB
