Related articles |
---|
Need info on incremental compilers. march@iis.nsk.su (1995-07-31) |
Re: Need info on incremental compilers. Steve_Kilbane@cegelecproj.co.uk (1995-08-04) |
Re: Need info on incremental compilers. bill@amber.ssd.hcsc.com (1995-08-14) |
Re: Need info on incremental compilers. reinder@neuretp.biol.ruu.nl (1995-12-28) |
Re: Need info on incremental compilers. stefan.monnier@lia.di.epfl.ch (Stefan Monnier) (1995-12-30) |
Re: Need info on incremental compilers. reinder@neuretp.biol.ruu.nl (1996-01-12) |
From: | reinder@neuretp.biol.ruu.nl (Reinder Verlinde) |
Newsgroups: | comp.compilers |
Date: | 12 Jan 1996 17:22:56 -0500 |
Organization: | Rijksuniversiteit Utrecht |
References: | 95-08-027 95-12-148 95-12-153 |
Keywords: | incremental, OOP, Lisp |
Reinder Verlinde <reinder@neuretp.biol.ruu.nl> wrote:
] code, yet, but Dylan is designed to produce fast code.
Stefan Monnier <stefan.monnier@lia.di.epfl.ch> wrote:
) What part of the design makes it possible to generate fast code ?
) (unless you mean that it hasn't been specifically designed to make it hard to
) generate fast code, like CLOS has)
I don't think CLOS is specifically _designed_ to make it hard to
generate fast code, although it may seem so. In Dylan, things like
run-time class modification are forbidden. This is also said to be
beneficial in keeping the size of produced binaries small.
Also, Dylan introduces the concept of 'sealing'. Once a class is
sealed no new class deriving from that class can be created. This
gives a compilation environment possibilities for optimizations which
would be possible only at final 'link' time otherwise. I think that
this will help in an interactive programming environment, since it
allows the compiler (I use that word in a loose definition here) to
create fast code for debugged parts of your program, while maintaining
tinkerability in non-debugged parts.
Also, Dylan allows one, but does not require one, to specify the type
of parameters. For instance, one could start with a generic 'square'
routine, and add a square which takes an integer later. The compiler
could bypass dynamic dispatch to the 'square' routine, if it inferred
that the type of the argument is integer. This allows for prototyping
at the cost of speed, but also can give you the speed benefits of
strongly typed languages. Of course, a smart compiler could figure
out that certain functions can be replaced by type-specific ones
itself, but in a language which does not carry type information that
might require a rather advanced compiler.
Reinder Verlinde
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.