RE: Operators

• Date: Mon, 22 Apr 1996 10:25:19 PDT
• From:
  Roger Crew <rfc@microsoft.com>
• Cc: "'manta'" <manta@dartmouth.edu>, "'rj@eli.wariat.org'" <rj@eli.wariat.org>, "'Jefferson M. Dubrule'" <Jefferson.M.Dubrule@dartmouth.edu>, "'bartmoss@mistral.co.uk'" <bartmoss@mistral.co.uk>, "'moo-cows@parc.xerox.com'" <moo-cows@parc.xerox.com>
• Content-Transfer-Encoding: 7bit
• Content-Type: text/plain; charset="us-ascii"

>> 	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... :)

• RE: Operators
• From: Michael Brundage <anomaly@u.washington.edu>

• Prev: Operators
• Next: RE: Operators
• Index: MOO-cows
• Thread: MOO-cows