Subject: Comments on Moo Syntax

From: Clay Luther <[email-masked]>
Date: Mon, 10 Aug 1992 13:38:47 -0700

Musing:

If moo would only support comments stored in the code.  The original reason
for not having them seems faulty given that in the same breath the author goes
on to say "use strings instead."

It would just be great to use some comment delimiter, like //.  I mean,
we use comment strings *anyway* and comments do add a great deal of
readability to the code.

As far as for converting C-like symbols to Pascal/Modula/Hypertalk/Ada-like
ands, ors, and nots....welllllll, I find I can read either just as well.  Once
the syntax is learned, I don't have any trouble reading the code whether it
says (x && y) or (x and y).

Since moo doesn't support bitwise & and | ops, I see no compelling syntactical
reason to change moo's logical ops.

HOWEVER, = and == can lead to devastating consequences very easily in moo.  I
would break from C tradition here and go with the Pascally := for becomes.  It
actually adds clarity: 

  := becomes
  == equals
  != not equals

  = syntax error

I would also disagree with syntasugar-phobes like Judy who claim +=, -=, ++,
and -- make the code "unclear."  On the contrary, I find these operators to
be very concise.  Of course, I had to *learn* what they meant, but that took all
of a minute.  I wish moo had them.

Finally, a break statement for loops would be very nice indeed.  Hey,
while we're at it, let's go two-whole steps backward and add labels and gotos
(just *kidding*).

-- 
Clay Luther
[email-masked]

---

From: Doug Orleans <[email-masked]>
Date: Mon, 10 Aug 1992 23:40:22 -0700

> be very concise.  Of course, I had to *learn* what they meant, but that took
 > all of a minute.  I wish moo had them.

Personally, I much prefer

a_very_long_variable_name_or_possibly_a_convoluted_lvalue_expression\
_that_may_take_some_time_to_compute += 36

to

a_very_long_variable_name_or_possibly_a_convoluted_lvalue_expression\
_that_may_take_some_time_to_compute = a_very_long_variable_name_or\
_possibly_a_convoluted_lvalue_expression_that_may_take_some_time_to\
_compute + 36

but maybe I'm exaggerating a bit, especially since I don't think any
MOO expressions result in lvalues.  Plus we all program like
G7 and use variables like k and z.

It's debatable whether

long_name_etc++

is any better than

long_name_etc += 1

especially when, as Roger pointed out, this isn't being compiled
directly into object code where INC and ADD instructions make a big
difference.  But I still prefer ++ and --, just because I'm used to
them.  Same goes for = vs. ==, and && vs. and.

If anyone ever decides to do += et al, a very useful one would be @=:

list_with_long_name_etc @= {foo, bar, baz}

would be equivalent to

list_with_long_name_etc = {@list_with_long_name_etc, @{foo, bar, baz}}

(I think Jonny brought this up first).  But scheme hackers might
prefer

append!(list_with_long_name_etc, {foo, bar, baz})

-- DougO, aka WR, who is less and less interested in MOO the more he
		  plays with FMPL