Subject: Re: More C-like MOO

From: [email-masked] (Schlake)
Date: Tue, 4 Aug 1992 17:45:35 -0700

On Aug 3,  5:30pm, Barry T. Drake wrote:
> Subject: More C-like MOO
>Date: 	Mon, 3 Aug 1992 17:30:12 PDT
>From: [email-masked] (Barry T. Drake)
>
>Well, I'll probably get chewed for this one, but how about this sticky idea:
>
>Add '++', '+=', '-=', etc.  I know these are C conventions, but why not?
>I think they are more readable, but perhaps that is only me.  Just an
>idea. :)
>
>bdrake
>
}-- End of excerpt from Barry T. Drake

I got a better one.  How about adding in a 'break' statement that takes
an argument of how many control loops to beak out of.

:) :) :) :) (if you don't uderstand the smileys, look at pre-Haakon MOO)

-- void *(*(*schlake())[])(void *);

---

From: Roger Crew <[email-masked]>
Date: Mon, 10 Aug 1992 10:57:29 -0700

Note that in some communities, being more C-like is not considered to be a 
virtue.

Keep in mind that ++, +=, -=, etc... are just instances of C pretending to
be an assembly language; the only point behind having these constructs is
to suggest optimizations to the compiler, and this was only back in the bad
old days when compilers couldn't figure these things out for themselves.
Well okay, MOO probably isn't that good at it yet, but we can suppose that
some day it will be.  Suffice it to say that the main bottlenecks in MOO
lie elsewhere: e.g., having some destructive list operations available
would have a much more significant impact speedwise --- not that I'm actually
suggesting this, mind you; there are lots of good reasons for not doing it.

Meanwhile, here's a big YES vote for
1)  using only := for assignment, 
2)  continuing to use == for the relational equals, and
3)  having = be UNDEFINED.  

Note that continuing to support the old usage of = for assignment would
totally defeat the purpose of making such a change, namely that of guarding
against someone inadvertantly using = for == (as opposed to advertantly
like I do).  Likewise, using = relationally would just create the reverse
problem, one that is, I might add, even more mysterious to diagnose...

Re: pseudo-english keywords:  I hate them.  For one thing, they tend to
block out usable identifiers.  As for newbies, I figure the sooner they
realize they're dealing with something that doesn't actually understand
English, the better.

Actually, I would say the real problem with understanding relational
expressions is not the use of &&, ||, and ! but rather the fact that the
unparser insists on cramming the entire expression onto a single line,
which usually serves to obscure whatever structure it might have.  Now
there *is* something to be said for having all verbcode in a uniform
format.  In particular:

  1) individual styles have less impact on the appearance of code
     thus making other players' code easier to read.  Story:  at one point, 
     someone with a question actually moo-mailed me a rather long piece of code
     rather than simply pointing me to the object where it lived.  Suffice it 
     to say I am now *really* *glad* that the unparser enforces a particular 
     style.

  2) @grep remains possible.  I hate to say it, but this is actually
     important, mainly from a diagnostic point of view (i.e., does anyone 
     really use $foo:bar()??  Let's find out!) but also from a security stand-
     point as well (find me all wizard-owned verbs that call set_verb_code()).

Some time back I actually did try to tackle this problem:  #5803:@prettyprint
(on LambdaMOO) is the result and there are three notable problems with it
  (a) it's horribly slow.
  (b) ...I mean *really* *horribly* *slow*.
  (c) it does idiosyncratic things -- i.e., things that *I* like, but which 
      would draw numerous complaints if this were to be decreed the standard 
      format.

Unfortunately, any attempt to produce a more readable format for long
expressions is doomed to eventually contend with (c) questions of taste that 
might best be left to individual users.  This suggests that, in fact, the 
server is not really the right place to address this.

Note that while uniform formats are good, there's nothing that says the
uniform format has to be a TEXT format (i.e., list of strings) and in fact
I would much prefer it if verb_code()/set_verb_code() dealt with
*parsetrees* rather than lists of strings.  Once we get reference counting
this would even be fast (most of the time in #5803:@prettyprint is taken up
with parsing, and most of the server action is taken up in unnecessary
recopying of the list structures that parsing produces).  

Once verb_code/set_verb_code/@list/@program are dealing with parsetrees,
syntactic styles can, at least in small matters, be customized to suit the
player.  E.g., if you prefer to see AND rather than &&, your @list verb
could be made to do just that, not to mention that it would work the same
way no matter whose code you're looking at, thus keeping the main benefits
of uniformity.  This would also help on @grep since you wouldn't get the
false hits that the purely textbased search available now gives you.

	Roger

ps.  As long as we're on the subject of messing with the language, 
whatever happened to EXIT (a.k.a BREAK) and NEXT (a.k.a. LOOP or CONTINUE)?
I'm getting tired of creating bogus auxiliary verbs just so I can RETURN out
of the middle of them :-)

---

From: Jay Scott <[email-masked]>
Date: Mon, 10 Aug 1992 12:36:29 -0700

Changing the MOOspeak's syntax would be a problem for those, like
me, who keep all their code offline. My local code copies are in a
more readable form than the MOO unparser can give me, they contain
comments and organization that are not stored on the MOO, they're
around even when the MOO is down (like now), they don't have to be
fetched before editing, they stay put through crashes, and life
is more pleasant than it would be otherwise. But if MOO syntax changes,
I'll have to update all these files with no more help than I can
find in /usr/bin.

On the other hand, the syntax is pretty icky.

I *vastly* prefer keywords 'and' 'or' and 'not' over && || and !.
I think it makes a difference in readability.

My favorite assignment operator is <-. The old := is not half as nice.
My favorite equality operator is =, but as people have been saying,
this causes confusion among those with faulty childhood education. :-)
I'd settle for == or 'is'.

Nobody has mentioned the inequality operator. I'd say, if equality is
'is' then inequality should be 'isnt'; otherwise, if NOT is ! then
inequality should be !=; otherwise I personally would prefer /=
as in (shield your eyes) Ada, because it is more visually suggestive.
But it might be simplest to keep it as !=.

	Frand
	[email-masked]