Message 18 on *C& Group (#72879):
Date: Tue Mar 11 00:37:48 2003 PST
From: Ogun (#115189)
To: *C& Group (#72879)
Here's to hoping nobody minds me piping in...
One of the primary strengths of moo is, obviously, the inheritance
model. When you're speaking of processes as objects, would they be
descended from a single $process object and manipulated as such? Could
you add/remove functions as you desire?
I'm just trying to figure out the more realistic aspects of the usage in
a running system. It's easily possible I'm missing something basic.
For language standarization, I think keeping it backwards compatible is
going to be a priority. This language is going to be (at least
initially) used primarily by those people currently familar with MOO,
and I don't see any real purpose to making them have to remember a
seperate syntax. while the if/endif may look less than optimal (and can
be a noticable decrease in typing speed while coding) it does work, and
makes the parser that much simpler.
Alternatively, you could simply include support for both, with a simple
check past the conditional for the {, but that could potentially cause
problems with lists and the like. Perhaps merely just force to the ()
model and if there's no endif at compile time the if statement merely
exicutes the single line following (while the defintion of 'line'
includes anything in those (), despite the number of actual statements
Personally, I use the simple <cond> ? <true res> | <false res> syntax,
but the <cond> && <true res> syntax could be very useful for cases where
there's no need to worry about a non-zero return value in the false case.
Re: the naming situation, I'd personally as soon as call it just 'mil'
for Moo, interprited language. But I think that you should simply call
the lambamoo project moocode or moopp and just get it started, and if
you want to get a new name, make a new project and just update all the
old information to point to it.
Just my several cents....
Ogun
--------------------------
Message 19 on *C& Group (#72879):
Date: Tue Mar 11 09:36:45 2003 PST
From: Luke-Jr (#115349)
To: Ogun (#115189) and *C& Group (#72879)
Processes/threads would be pretty much how they are within a MOO
currently. They wouldn't be object-based at all.
Libraries and executables would have one or more objects within them.
More threads could be created with a simple fork(0) code...; endfork etc
As long as you mean that it is compatible with existing code when you
say "backwards compatible", then yes (one could use the term to mean new
code works with old vers). However, new operators such as "var += 5;"
are very likely to be added.
MOOcode/C& already allows single-line IFs. For example, instead of
putting "if(q) o:vrb(); endif", you can simply put "q && o:vrb();"
Problems with your suggestion for naming:
1. Languages should not be dependent on implementation. MOOcode/C& need
not be interpreted forever if a compiler is written.
2. There should probably be seperate names for a single-object (C
equivalent) version of the language and versions of the language with
aspect-oriented support.
Good idea with the SF UNIX-"renaming" idea though :)
--------------------------
#############################################################
This message is sent to you because you are subscribed to
the mailing list <[EMAIL PROTECTED]>.
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to <[EMAIL PROTECTED]>
