# Operators

Roger Crew (rfc@microsoft.com)
Mon, 22 Apr 1996 10:25:19 PDT

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    >> 	It is dangerous to draw direct analogies between objects in C++
    >> and MOO
    >
    > No kidding.  In addition, it's dangerous to draw direct lessons from C++
    > into MOO language design.

    I would be even less charitable and say that it's dangerous to draw
    direct lessons from C++ into *any* language design, unless the point is
    to have examples of things NOT to do.  In particular, C++ is a pretty
    good example of what you get when you throw together lots of random
    features without any thought for how they interact --- but since this
    isn't a C++ discussion list I'll spare you the full language flame and
    refer you to Chapter 10 of Unix-Haters if the idea of C++ being a total
    abortion is entirely new to you.

    w.r.t. the various suggestions about adding +=, *=, ++ and other
    C/C++-isms to MOO, keep in mind that the only reason these are in C in
    the first place is because the PDP-11 didn't have much room for compiler
    smarts; thus you had programmers essentially writing register-twiddling
    code themselves.  You really only need += if your compiler isn't very
    good at common subexpression elimination.

    The readability issue is highly debatable/religious --- it mostly boils
    down to what you're used to, I suppose.  My own favorite bad example
    (which I've actually seen in real C code):
      f = a;
      f *= x;
      f += b;
      f *= x;
      f += c;
    vs.
      f = (a * x + b) * x + c;
    The latter, by the way, happens to be a bit more efficient in MOO.

    Never mind that if the expression on the left of a += is an array
    reference, it won't, in MOO, mean anything close to what it looks like.

    Now there is indeed this Small Problem having to do with the fact that
    MOO doesn't actually have a compiler (*).  However, given that MOO
    doesn't have any nasty pointer/alias problems and no mutable values
    other from objects/properties, MOO may well be one of the easier
    compilers to write.  IMHO this would be, in the long run, a better
    course of action than various syntactic bandaids being proposed.

    The only immediate obstacle I see has to do with the fact that the byte
    code currently in use is designed both to be executable AND to be able
    to reproduce the source (modulo dropped blank ELSEIFs :-).  Once you
    start optimizing it you lose the latter, which entails either giving up
    on having the source available (probably bad), or keeping a separate
    copy of the source (hey, let's use more memory! --- perhaps not a
    problem if we have room to keep around stuff like Mr. Spell; parse trees
    can be made pretty compact, too).

    I would also think there'd be some serious wins if certain verbs could
    be inlined (e.g., $perm_utils:controls ...), though you'd need some
    recompile scheme for the (hopefully infrequent) occasions when these
    verbs get changed.

    (*) I really mean byte-code optimizer here, with perhaps also some
    notion of fixing MOO byte-code to be more readily optimizable; native
    code compilation will be a while yet, I think... :)