jallen@libserv1.ic.sunysb.edu (Joseph Allen) (04/04/91)
Several points:
EMACS: The easy parts are written in LISP, the hard parts are written in C.
Actually I like the argument about EMACS being written in TECO. EMACS stands
for Editor Macros so I guess it is written in LISP. I.E., LISP is merely a
MACRO language :-)
The "editor engine" part of EMACS is, however, written in C.
(I happen to hate using EMACS although I think the editor engine in it is
pretty amazing)
LISP: Just try to write a terminal screen optimizer in it which is fast enough
to be used in a real editor.
C: This isn't really a high level language, it's portable assembly language.
And it really does have dynamic typing and all that:
/* Graph function user types in... */
top: printf("Type function in terms of variable x: "); gets(buf);
sprintf(buf1,"main(argc,argv)char *argv[];{int x=atof(argv[1]);"
"printf(\"%%f\n\",%s);}",buf);
sprintf(buf2,"echo '%s' >tmp.c;cc tmp.c",buf1);
if(system(buf2))
{ printf("Try again\n");
goto top; }
/* Now graph the function... */
for(x=0.0;x!=1.0;x+=.001)
{
sprintf(buf,"./a.out %f",x);
popen() etc...
}
So what we really need is a "OBJ *compile(char *func)" function in the C
library to compile functions in run-time and then also a
"(*(dynlink(OBJ *)))()" function. Hmm... and maybe an sdb() function...
--
#define h 23 /* Height */ /* jallen@ic.sunysb.edu (129.49.12.74) */
#define w 79 /* Width */
int i,r,b[]={-w,w,1,-1},d,a[w*h];m(p){a[p]=1;while(d=(p>2*w?!a[p-w-w]?1:0:0)|(
p<w*(h-2)?!a[p+w+w]?2:0:0)|(p%w!=w-2?!a[p+2]?4:0:0)|(p%w!=1?!a[p-2]?8:0:0)){do
i=3&(r=(r*57+1))/d;while(!(d&(1<<i)));a[p+b[i]]=1;m(p+2*b[i]);}}main(){r=time(
0L);m(w+1);for(i=0;i%w?0:printf("\n"),i!=w*h;i++)a[i]?printf(" "):printf("#");}markf@zurich.ai.mit.edu (Mark Friedman) (04/04/91)
In article <1991Apr4.075558.19873@sbcs.sunysb.edu> jallen@libserv1.ic.sunysb.edu (Joseph Allen) writes:
LISP: Just try to write a terminal screen optimizer in it which is
fast enough to be used in a real editor.
We have done that. The Edwin editor that comes with MIT Scheme is an
EMACS clone written, naturally enough, in Scheme (a.k.a. the uncommon
Lisp).
-Mark
--
Mark Friedman
MIT Artificial Intelligence Lab
545 Technology Sq.
Cambridge, Ma. 02139
markf@zurich.ai.mit.edujallen@csserv1.ic.sunysb.edu (Joseph Allen) (04/06/91)
In article <MARKF.91Apr4104859@montreux.ai.mit.edu> markf@zurich.ai.mit.edu writes: >In article <1991Apr4.075558.19873@sbcs.sunysb.edu> jallen@libserv1.ic.sunysb.edu (Joseph Allen) writes: > LISP: Just try to write a terminal screen optimizer in it which is > fast enough to be used in a real editor. >We have done that. The Edwin editor that comes with MIT Scheme is an >EMACS clone written, naturally enough, in Scheme (a.k.a. the uncommon >Lisp). !! I'm very surprised. Scheme's optimizer must be really good. Or does scheme have simpler arrays (statically typed ones) than common lisp? I suppose lisp compilers are much more global than those of other languages. They must detect that an object will only ever be assigned one data type and then make that object static instead of dynamic. Oh that reminds me, when the above optimization is done, how are bignums handled? I can see how the compiler might detect that only integers are involved, but how does it know that the integers will be small? Or is there always runtime code for checking integer sizes? -- #define h 23 /* Height */ /* jallen@ic.sunysb.edu (129.49.12.74) */ #define w 79 /* Width */ /* Amazing */ int i,r,b[]={-w,w,1,-1},d,a[w*h];m(p){a[p]=1;while(d=(p>2*w?!a[p-w-w]?1:0:0)|( p<w*(h-2)?!a[p+w+w]?2:0:0)|(p%w!=w-2?!a[p+2]?4:0:0)|(p%w!=1?!a[p-2]?8:0:0)){do i=3&(r=(r*57+1))/d;while(!(d&(1<<i)));a[p+b[i]]=1;m(p+2*b[i]);}}main(){r=time( 0L);m(w+1);for(i=0;i%w?0:printf("\n"),i!=w*h;i++)printf(a[i]?" ":"#");}
olson@lear.juliet.ll.mit.edu ( Steve Olson) (04/06/91)
!! I'm very surprised. Scheme's optimizer must be really good. Or does scheme have simpler arrays (statically typed ones) than common lisp? Common Lisp has extensive facilities for declaring array types. With the appropriate declarations an optimizing Common Lisp compiler can do quite well with simple array references. I suppose lisp compilers are much more global than those of other languages. They must detect that an object will only ever be assigned one data type and then make that object static instead of dynamic. No, thats not how Lisp compilers work. I doubt that any Lisp compiler would try to infer the types of random global variables. The optimizing Lisp compiler that I am familiar with (Lucid) does not even try to optimize local variables in that manner. What it will do is infer the types of some intermediate values. If a,b, and c are declared float then then compiler wll fully optimize the expression "(+ a (+ b c))" by inferring the type of the intermediate expression "(+ b c)". It won't even do that much if a, b, and c are fixnums. "(+ b c)" could evaluate to a bignum, so you have to promise that that won't happen by doing "(+ a (the fixnum (+ b c)))". Oh that reminds me, when the above optimization is done, how are bignums handled? I can see how the compiler might detect that only integers are involved, but how does it know that the integers will be small? Or is there always runtime code for checking integer sizes? If you promise that a variable is a fixnum then the compiler (at high levels of optimization) will produce code that does not check for overflows. If you're wrong about your promise then you lose. - Steve Olson MIT Lincoln Laboratory olson@juliet.ll.mit.edu