[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

T vs. franz



I can't understand how anyone can defend a defaultly dynamically
scoped Lisp except on the grounds of tradition.  A dynamically scoped
lisp violates referential transparency: you can not guarantee that a
equivalent texual substitution of one variable name with another
doesn't change the semantics of your code.  i.e. merely by chosing a
variable name unwisely and using it as a free variable you can get
screwed if someone else's function you call temporally binds the
variable.

Package systems help this problem with large different systems, like
avoiding conflicts between a editor and a window system, but you still
have to be careful when you're writing code with someone else.  And I
personally think package systems are a gross and inelegant kludge.

Scott Falhman is of course correct that you have to have dynamic
scoping avaliable.

Big packages written in dynamically scoped lisps tend to consist of
lots of top level functions, and to avoid naming conflicts people tend
to use very long variable names like subprogram-name-do-the-right-
thing.  Lexically scoped lisps allow the use of Algol style block
structure; you can hide functions that are used only by one superior
function.

Another important point is that in lexically scoped lisps the
semantics of the interpreter and the compiler are the same.  In
systems where arranging incremental compilation is not completely
trivial (i.e. anything other than a lisp machine where you can invoke
the compiler on a function in the editor with a keystroke) you tend to
debug you code in the interpreter and then debug it again when you
compile it.  All the lisp machine users I've worked with only use
interpreted functions when they are tracking down subtle bugs and
don't want to deal with assembly code.

The bottom line for me is that after doing lots of system work and
maintaince on the lisp machine elegance and cleanliness assume value
beyond aesthestics.

					- Harold