[692] in Coldmud discussion meeting

Re: assignment operator

daemon@ATHENA.MIT.EDU (Fri Mar 10 14:36:27 1995 )

Date: Fri, 10 Mar 95 11:29:29 -0800
From: jsp@betz.biostr.washington.edu (Jeff Prothero)
To: coldstuff@MIT.EDU


| < I think these endless squabbles over syntactic minutia
| < are a good reason to put compilers in-db rather than
| < inserver, personally :).
| 
| Because of a reason you yourself brought up (twisting it a little).  The most
| frequently used sequence/procedure should be the most optimized.  Doing it
| in-db means it will not be very optimized.  Doing it in-driver means it will
| be (referring to both compile and decompile).

Um.  I'm not sure I agree.

It's generally accepted in the industry that programs spend
90% of their time in 10% of the code:  One doesn't have to
C-code the complete compiler to get essentially C-level
performance.  Coding a few crucial prims should suffice.

I could also comment that just 'cause it's in C doesn't
mean it's efficient... I'd bet Larry Wall can write Perl
that would run circles around a lot of undergrad's C code,
say... :)

Your next paragraph sounds like it is making very nearly
this point anyhow...

| Actually, with the change Crag is working on we can remove "compile()"
| and have an 'add_method(name, flags, args, vars, body)', then take the
| parsing code in compile and make a 'coldc_to_method()' and a
| 'method_to_coldc()' (so, if people wanted to they could easilly add more
| parsing functions).
| 
| The end result is, to compile code you would do:
| 
|   add_method('foo, @coldc_to_method(["arg foo; return foo;"]))
| 
| Instead of:
| 
|   compile(["arg foo; return foo;"], 'foo);
| 
| -Brandon

If you can rig it so in-db parse/compile functions can't hang
or crash the server by deliberately producing bad code, you've
got it.  If not, you can't really afford to open up the
facility to non-wizards, and you're pretty much back where you
started... imho, anyhow :)