?

Log in

No account? Create an account

Previous Entry | Next Entry

waru-sama wa otaku desu.

On Fri, Mar 12, 2004 at 09:19:46AM -0800, Dave Whipp wrote:
: Why are we mixing the concepts of assignment and topicalization -- 
: especially in a way that doesn't generalize. Why can't we invent a
: "topicalization" operator, analogous to the old binding operator, that
: simply sets its LHS as the topic of its RHS: and then have an assigning
: version of that operator.

Hmm, yes, other than the usual arguments against inventing *any* new
operator...

: For example, lets use the "section" Unicode symbol: "§" to locally set the
: current topic within an expression. Now we could say:
: 
:   $x = ( $foo § .a + .b + .c )
: 
: to mean
: 
:   $x = $foo.a + $foo.b + $foo.c

I expect the first thing a Nihongo-jin would do is to change it from
the section sign § to the は "wa" particle that already means "the
preceding is the topic for the following".

    $x = ( $foo は .a + .b + .c )

So maybe the ASCII workaround is just "wa".  :-) * .5

    $x = ( $foo wa .a + .b + .c )

(Yes, Simon, I know that that Japanese only allows wa in the top-level
sentence position, not embedded in subexpressions. ^_^  Perhaps we
should use ga instead...)

Some will argue that since English doesn't have a grammatical
postfix topicalizer like Japanese, we should stick with something
like more English-like:

    $x = (.a + .b + .c given $foo)

But that doesn't give us the corresponding assignment op.  Interestingly,
modifier "if" and "unless" do in fact have corresponding assignment ops,
namely &&= and ||=.

Or we could use a syntax that is already allowed:

    $x = {.a + .b + .c}($foo)

But that doesn't give us a simple topic-in-front form either...

: The assigning version of the operator could be
: 
:   $x §= .foo;
:   my Dog $dog §= .new;

Though I confess I find it hard to imagine persuading people to write:

    my Dog $dog wa= .new;

Now, if we had a unary = that assigned to the current topic, we could do
it with the existing topicalizer as

    given my Dog $dog { = .new }

But I'm not recommending that approach, because I dislike unary =, and
because I don't want every declaration to have to say "given".

For the sake of argument, let's call our theoretical new operator "wa".
Taking a clue from Japanese, it's perhaps a mistake to think of "wa"
as a binary operator.  In Japanese, it's a postpositional particle,
which is to say, a postfix operator.  You can, in fact, just say:

    Neko wa.

which means something like "consider the cat".  On the other hand,
as a natural language Japanese doesn't have to specify the scope of
topicalization, while Perl has to.  So it's not clear whether we
should define wa such that

    my Dog $dog wa= .new;

is really an assignment operator, or whether it actually
parses more like a postpositional:

    (my Dog $dog).wa = .new;
    
In the latter case, you could use the wa postposition anywhere you
could use the expression before it, because it would set up the
expectation that the next thing is an operator rather than a term.
So you could usefully say something like

    $modthingie wa %= .modulus;
    
or tell a subscript to default to the array as its topic:

    @array wa .[.min .. .max]

That would of course read better with a single character postfix:

    @array§[.min .. .max]

It's really a pity that question mark is already so overloaded with
boolean connotations, because

    $dog? .bark

would really be the best postfix operator in ASCII for this.
People would probably end up writing

    my Dog $spot ?= .new;

as an idiom.  And

    @array?[.min .. .max]

would be the way to get a topicalized subscript.  If "wa" were a binary
operator as originally proposed, then you'd have to write that:

    @array ? $_[.min .. .max]

or

    @array ? .[.min .. .max]

since it's setting up expectation for a term rather than an operator.

On the other hand, if it's a binary operator of a particular precedence,
then the scoping of "wa" is clear.  It's not so clear if mark the term
with a postfix.  Unless the rule is simply that it governs for the
rest of the entire statement.  In which case we'd have people writing

    $foo? (
	...
    )

when they should probably be saying

    given $foo {
	...
    }

But maybe the rule is that it governs the rest of the surrounding
paren scope, much like a "my" declaration does in a block, or like
a list operator eats all the commas to its right.

Not sure I want to explain that though...I certainly haven't explained
it well here.  It is certainly a fact that most Perl and C programmers
are more comfortable with infix operators than postfix.

But this is gonna be a weird binary operator, if operator it is.
Its purpose is not just to evaluate the left argument but to bind
it as a temporary topic and then call the right side with that
temporary topic.

Arguably, we already have exactly this operator.  It's called "dot".

Ignore for the moment that we've said that .() calls a sub.  What
if binary . were our mini-topicalizer?

    $topic . (.a + .b + .c)

Then we're back to

    my dog $spot .= .new;

and then the dotted subscript form:

    @array .[.min .. .max]

would automatically topicalize the subscript.  Except that people would
be confused by the difference between that and

    @array . [.min .. .max]

which would presumably just produce an anonymous list of subscripts without
actually doing the subscripting.

Hmm.  The basic problem is that we're using the same notation to both
create and use the topic.  So I think "dot" isn't the operator we want.
Forget that.

Despite the severe overloading problems, it's really gonna be hard
to do much better than

    $topic ? (.a + .b + .c)
    my dog $spot ?= .new;
    @array?.[.min .. .max]

And I do think people would rebel at using Latin-1 for that one.
I get enough grief for «...».  :-)

Larry


And I'm guessing at the mangling for "Wall". Let me know if I'm wrong.

Comments

( Read 1 comment — Leave a comment )
chiave_trust
Mar. 12th, 2004 07:19 pm (UTC)
I'm not a Perl hacker, but I understood this... >.>

<.<

Uh, I plead the fifth. Yeah. >.
( Read 1 comment — Leave a comment )