Static/Strong/Implicit Typing

483 views
Skip to first unread message

sajiimori

unread,
Jan 23, 2004, 8:58:10 PM1/23/04
to
Warning: This thread is not a request for help on any particular problem.
It's just for discussion, so if you're not into that sort of thing, don't
blame me if you decide to post anyway.

If there were a statically, implicitly typed Lisp, would you use it? What
qualities of dynamic typing would you miss?


Erik Naggum

unread,
Jan 24, 2004, 5:13:49 AM1/24/04
to
* sajiimori

| If there were a statically, implicitly typed Lisp, would you use it?

Common Lisp is already statically, implicitly typed. All objects are
of type T, and this is very rigourously enforced.

| What qualities of dynamic typing would you miss?

You may have noticed that every language worth using these days has
(added) an object system that carries type information in the objects.
You appear to want to take a step backwards in this respect. Why?

--
Erik Naggum | Oslo, Norway

Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.

Pascal Costanza

unread,
Jan 24, 2004, 8:38:20 AM1/24/04
to

sajiimori wrote:

Dynamicity? ;)

Static type systems are not bad per se, especially those based on type
inference. They can in fact be useful to determine certain properties of
your programs that sometimes might help you.

However, what sucks in most statically typed languages is that their
type systems are enforced at compile time without any unobtrusive way to
switch to dynamic typing. The mindset of static typers seems to be
that when the compiler complains about a static type error, you should
not be allowed at all to run your program. This doesn't make sense,
especially in scenarios in which a run of an erroneous program could
actually help you to detect the source of a problem. From an engineering
point of view, it does not make sense to restrict your toolset.

What good dynamically typed languages give you beyond better debugging
facilities is the ability to change a program at run time, which means
adding, removing or changing features dynamically. Especially the
removal of features is not handled very well in statically typed
languages. Dynamic software evolution enables a whole range of new
deployment models, like running your software on a web server and being
able to update it without any downtimes.

It's important to note that the kind of type system is not the only
important factor, and that the default typing "philosophy" of a language
does not necessarily preclude the switch to the other one.

Examples:

- Many people are scared when they hear about changing features of a
program at run time. However, notions like keyword arguments and generic
functions in Common Lisp or categories in Smalltalk make this a
relatively harmless process. The fact that changing a C++ program at run
time would wreak havoc isn't a compelling argument against dynamic
software evolution.

- There are approaches to add static type checking to dynamically typed
languages as an additional tool, without strictly enforcing what static
typers call "type soundness". For example, CMU Common Lisp (CMUCL) and
Strongtalk are good examples in this regard.

- Likewise, modern Java IDEs like Eclipse have implemented their own
Java compiler that allows them to treat static type soundness as an
optional feature. In Eclipse it is possible to run a Java program even
when the Java compiler emits compile-time errors. Obviously, this degree
of flexibility is needed in the "real world".

Still, Java's static type system is one of the worst, and will even
become worse in JDK 1.5. I am not aware of a language with a reasonably
well-designed static type system that allows this kind of optional
switch to dynamic type checking.

- Again likewise, there are dynamically typed languages out there that
still suck very badly. Again, whether a language is dynamically or
statically typed does not determine whether it is a good language.
Programming languages are holistic entities, in the sense that all the
distinguishing features have to complement each other well.


Pascal

--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."

Marco Antoniotti

unread,
Jan 24, 2004, 12:53:43 PM1/24/04
to

sajiimori wrote:

Yes, I would use it, as long as any conformant Common Lisp program would
run in it. Otherwise, I would not be so interested.

Cheers
--
Marco


Joe Marshall

unread,
Jan 24, 2004, 3:28:58 PM1/24/04
to
"sajiimori" <myuse...@hotmail.com> writes:

> Warning: This thread is not a request for help on any particular problem.
> It's just for discussion, so if you're not into that sort of thing, don't
> blame me if you decide to post anyway.
>
> If there were a statically, implicitly typed Lisp, would you use it?

Possibly.

> What qualities of dynamic typing would you miss?

What qualities of dynamic typing would be missing?

--
~jrm

sajiimori

unread,
Jan 26, 2004, 12:29:05 AM1/26/04
to
> Common Lisp is already statically, implicitly typed. All objects are
> of type T, and this is very rigourously enforced.

I don't know if you're being serious, but the rule that all objects are of
type T means that if X is an object, the statement "X is of type T" carries
no information. I don't know how you could consider something a static type
system when it doesn't offer any static distinction between objects.

> You may have noticed that every language worth using these days has
> (added) an object system that carries type information in the objects.

Static and/or implicit typing doesn't forbid objects from carrying type
information, so I don't see your point.

> You appear to want to take a step backwards in this respect. Why?

You folks sure are touchy -- I didn't even say that I want static or
implicit typing. I thought it would take at least a few posts before the
rudeness began.


Kenny Tilton

unread,
Jan 26, 2004, 12:57:23 AM1/26/04
to
sajiimori wrote:
> You folks sure are touchy --

We're having a nasty winter. Wait till spring and try again.

kenny


--

clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama

sajiimori

unread,
Jan 26, 2004, 1:15:57 AM1/26/04
to
> The mindset of static typers seems to be
> that when the compiler complains about a static type error, you should
> not be allowed at all to run your program. This doesn't make sense,
> especially in scenarios in which a run of an erroneous program could
> actually help you to detect the source of a problem.

Interesting... Do you have an example of how running a program can lead to
the discovery of the source of a static typing error? I would think that
since nothing that happens at runtime can affect static typing, there would
be no useful information to glean about such an error.

> From an engineering
> point of view, it does not make sense to restrict your toolset.

My first impulse is to agree, but the biggest (generally agreed upon)
benefit of static typing is that type errors are caught at compile-time, and
that benefit can only be reaped by restricting yourself from doing anything
that would violate the system. I guess it depends on what freedoms you'd be
willing to forfeit (if any) to have that feature -- which is sort of what my
original question was about.

> What good dynamically typed languages give you beyond better debugging
> facilities is the ability to change a program at run time, which means
> adding, removing or changing features dynamically. Especially the
> removal of features is not handled very well in statically typed
> languages. Dynamic software evolution enables a whole range of new
> deployment models, like running your software on a web server and being
> able to update it without any downtimes.

These ideas are still pretty new to me. What do you mean by "removing
features", and why does the type system affect it so much?

> It's important to note that the kind of type system is not the only
> important factor, and that the default typing "philosophy" of a language
> does not necessarily preclude the switch to the other one.

That's exactly what I'm hoping for, because I'm trying to make a Lispy
language that uses strong, static, implicit typing (just as an experiment --
I don't know if I would even use such a language in place of CL).

> - There are approaches to add static type checking to dynamically typed
> languages as an additional tool, without strictly enforcing what static
> typers call "type soundness". For example, CMU Common Lisp (CMUCL) and
> Strongtalk are good examples in this regard.

If I were still running a Unix, I'd check out CMUCL -- as it is, I've only
seen CLISP and Corman, neither of which catch type errors at compile time.
:( Would CMUCL warn about this during compile-time? If not, do you think
it should?

(defun x-plus-y (x y)
(+ x y))

(defun test ()
(x-plus-y 5 "asdf"))

> Again, whether a language is dynamically or
> statically typed does not determine whether it is a good language.
> Programming languages are holistic entities, in the sense that all the
> distinguishing features have to complement each other well.

Of course! So, as a variant of my original question: In a statically,
implicitly typed Lisp, do you think the features would still complement each
other well?


sajiimori

unread,
Jan 26, 2004, 1:20:17 AM1/26/04
to
> Yes, I would use it, as long as any conformant Common Lisp program would
> run in it. Otherwise, I would not be so interested.

Hmm...I guess it would have to support dynamic typing as a fallback then.


sajiimori

unread,
Jan 26, 2004, 1:27:14 AM1/26/04
to
> What qualities of dynamic typing would be missing?

Good question... how about this?

(setq x 5)
(setq x "hello")

Or this?

(typecase (read)
(integer (print "you typed an integer"))
(string (print "you typed a string"))
(t (print "i don't know what you typed")))

I'm sure that's just the tip of the iceberg, but I haven't been using Lisp
long enough to discover many significant benefits of dynamic typing.


Erik Naggum

unread,
Jan 26, 2004, 2:52:16 AM1/26/04
to
* Erik Naggum

> Common Lisp is already statically, implicitly typed. All objects are
> of type T, and this is very rigourously enforced.

* sajiimori


| I don't know how you could consider something a static type system
| when it doesn't offer any static distinction between objects.

I think you may want to return to your books on types and focus on the
definition of static type analysis. The Common Lisp type system does
in fact satisfy the definition of a static type system in that both
you and the compiler always know the type of the object statically: It
is always T, and you can never violate this static type.

> You may have noticed that every language worth using these days has
> (added) an object system that carries type information in the objects.

| Static and/or implicit typing doesn't forbid objects from carrying type
| information, so I don't see your point.

Well, consider this: all Common Lisp objects (of type T) carry type
information. Are you beginning to see the point?

> You appear to want to take a step backwards in this respect. Why?

| You folks sure are touchy -- I didn't even say that I want static or
| implicit typing. I thought it would take at least a few posts before
| the rudeness began.

If you are so concerned about rudeness, why are you rude towards us?
You get one simple question about your motives, and you start talking
about «you folks». Your brain is malfunctioning, sajiimori.

You have made it clear that you are incapable of processing answers to
your questions, incapable of seeing the point I made when you type it
in yourself, incapable of polite conversation, and so nervous about
your objectives that you become defensive when questioned about them.

Go away, annoying troll.

--
Erik Naggum | Oslo, Norway 2004-026

Erik Naggum

unread,
Jan 26, 2004, 3:11:48 AM1/26/04
to
* sajiimori

| If I were still running a Unix, I'd check out CMUCL -- as it is, I've
| only seen CLISP and Corman, neither of which catch type errors at
| compile time. :( Would CMUCL warn about this during compile-time? If
| not, do you think it should?
|
| (defun x-plus-y (x y)
| (+ x y))
|
| (defun test ()
| (x-plus-y 5 "asdf"))

I keep wondering why the static type crowd always make up this kind of
examples.

In the Common Lisp world, you are supposed to be conscious when you
write your code, and the above fragment suggests that you are not, but
want the compiler to wake you up from your code-writing coma.

One reason to cater to the comatose programmers is that static typing
with a wide variety of types adds a lot more things to think about.
The other solution to this problem is dynamic typing.

If you want to understand what is going on here, you have to begin by
realizing that both static and dynamic typing are answers to another,
logically preceding question. The static type crowd solved a problem
when people passed around machine words with different meanings. «I
know», said that static type genius, «I'll let the compiler keep track
of all the types and refuse to run the program with values of random
types confusing the machine!». In another office, far away, sat the
dynamic typing genius and thought «I know, I'll make all values self-
determine their types!». The latter genius laid the foundation for
the reinvention of object-orientation with run-time type information,
which needed to be added to the static type genius's world view at at
heavy cost.

If you write the above code in Common Lisp, the purpose of running it
will be to investigate the response to type errors. You will observe
that you invoke the debugger. One of the things you could do then is
to realize that the function that was called should be a generic
function, and you can back out of the call, redefine the function
x-plus-y, and resume execution by retrying the call. Another thing
you could do is to realize that you had made a mistake in the caller.
In this case, you would back out of the call to test, instead, and
redefine that function and resume execution by calling the new test
function.

Please think about how this is different from the static typing
systems you appear to know better than Common Lisp.

| So, as a variant of my original question: In a statically, implicitly
| typed Lisp, do you think the features would still complement each
| other well?

As long as you do not understand what you already have, there is no
point in answering your question about what would be.

And /calm down/, please. Say to yourself that you are not «touchy»,
and that you have to /think/ when you feel uncomfortable, not lash out
at whoever you think makes you feel uncomfortable. Can you do this?

sajiimori

unread,
Jan 26, 2004, 3:19:26 AM1/26/04
to
Alright, I won't annoy you with any more replies to your posts. I hope that
will be satisfactory.


Erik Naggum

unread,
Jan 26, 2004, 3:30:03 AM1/26/04
to
* sajiimori

| I'm sure that's just the tip of the iceberg, but I haven't been using Lisp
| long enough to discover many significant benefits of dynamic typing.

We already knew that by now. You are probably the millionth person to
come to Common Lisp thinking that the only solution to your problems
in making programs work correctly is static type analysis, because
that was the solution to the same problem in the previous language you
tried to learn by trial-and-error. Trust me, the solution is not to
add static type analysis to the language, it is to upgrade your brain
to work with a new language and a new set of solutions to a new set of
problems. Static type analysis leads to brain damage and it has to be
repaired before you can deal with a world where others are not obliged
to do only what you have advertised that you accept.

There is a golden rule about learning anything new. First, you look
long and hard at it and determine that it is not something you already
know. Then, you look at all the differences you can find and work
hard to disregard any emotional responses of the sort «I already know
this!» because you think you see a similarity. Finally, you approach
it as something you have to learn, because you realize that you do not
already know it. If you do not follow this golden rule, you will only
succeed in treating all things that are somewhat similar as the same,
and you will respond with things like «You folks sure are touchy» when
you think you see something that is similar to something you already
determined was the result of being «touchy». When you are mistaken in
making such pronouncements, you get snubbed by people you have angered
and you probably become even more certain that they are touchy, but
you have in fact insulted them with your prejudice and they try to
make you back off and take another look at the evidence. If you are
not the kind of person who is able to disregard similarities and look
for the surprising dissimilarity with curiosity, this will not work,
and you will only deepen your conviction that you already understand
what you see. I know what I think about you right now, but you have
the option of responding with more curiosity and less judgment at any
time. Some psychologists argue that this is a personality property
and that some people naturally judge before they know what they look
at, while others are naturally curious and defer judgment even when
they know what they look at. Both need to do something unnatural at
times and break the natural habit, but if you are the judging type and
something uncomfortable shows up, your tendency to judge before you
think will most probably overwhelm any residiual curiosity. You make
a distinct impression of being very strongly judging, so this is a
very strong strong request for you to back off from your judgments and
take a closer look at the evidence.

Adam Warner

unread,
Jan 26, 2004, 3:40:43 AM1/26/04
to
Hi sajiimori,

> If I were still running a Unix, I'd check out CMUCL -- as it is, I've only
> seen CLISP and Corman, neither of which catch type errors at compile time.
> :( Would CMUCL warn about this during compile-time? If not, do you think
> it should?
>
> (defun x-plus-y (x y)
> (+ x y))
>
> (defun test ()
> (x-plus-y 5 "asdf"))

Ideally they could catch this. But consider the correct implementation
using a compiler macro:

(declaim (inline x-plus-y))


(defun x-plus-y (x y)
(+ x y))

(define-compiler-macro x-plus-y (x y)
`(+ ,x ,y))

Now try defining test and compiling it:

* (defun test ()
(x-plus-y 5 "asdf"))

* (compile 'test)
; Compiling lambda nil:

; In: lambda nil

; (x-plus-y 5 "asdf")
; ==>
; (+ 5 "asdf")
; Warning: Lisp error during constant folding:
; Argument y is not a number: "asdf".
;
; Warning: This is not a (values &optional number &rest t):
; "asdf"
;
; Compiling Top-Level Form:

; Compilation unit finished.
; 2 warnings

The error is instantly discovered in SBCL because it compiles
all forms.

Regards,
Adam

Kenny Tilton

unread,
Jan 26, 2004, 3:50:10 AM1/26/04
to
sajiimori wrote:
>
> My first impulse is to agree, but the biggest (generally agreed upon)
> benefit of static typing is that type errors are caught at compile-time,

I think you are a bit behind the times. The hard-core, static-typing C++
crowd has changed its mind:

http://www.mindview.net/WebLog/log-0025

Bruce Eckels writes:

"That is to say, if a program compiles in a strong, statically typed
language, it just means that it has passed some tests. It means that the
syntax is guaranteed to be correct (Python checks syntax at compile
time, as well. It just doesn't have as many syntax contraints). But
there's no guarantee of correctness just because the compiler passes
your code. If your code seems to run, that's also no guarantee of
correctness... The only guarantee of correctness, regardless of whether
your language is strongly or weakly typed, is whether it passes all the
tests that define the correctness of your program. "

Along the way he cites Robert Martin coming to the same conclusion:

http://www.artima.com/weblogs/viewpost.jsp?thread=4639

Martin also contradicts your lack of enthusiasm for dynamic languages:

"I thought an experiment was in order. So I tried writing some
applications in Python, and then Ruby (well known dynamically typed
languages). I was not entirely surprised when I found that type issues
simply never arose. My unit tests kept my code on the straight and
narrow. I simply didn't need the static type checking that I had
depended upon for so many years.

"I also realized that the flexibility of dynamically typed langauges
makes writing code significantly easier. Modules are easier to write,
and easier to change. There are no build time issues at all. Life in a
dynamically typed world is fundamentally simpler.

"Now I am back programming in Java because the projects I'm working on
call for it. But I can't deny that I feel the tug of the dynamically
typed languages. I wish I was programming in Ruby or Python, or even
Smalltalk."

So maybe you should get off Usenet and do some Lisp and find out what
you are missing.

kenny


--

Kristian Elof Sørensen

unread,
Jan 26, 2004, 4:07:50 AM1/26/04
to
Erik Naggum wrote:

[cut]


> If you write the above code in Common Lisp, the purpose of running it
> will be to investigate the response to type errors. You will observe
> that you invoke the debugger. One of the things you could do then is
> to realize that the function that was called should be a generic
> function, and you can back out of the call, redefine the function
> x-plus-y, and resume execution by retrying the call. Another thing
> you could do is to realize that you had made a mistake in the caller.
> In this case, you would back out of the call to test, instead, and
> redefine that function and resume execution by calling the new test
> function.

I too am a recent arrival to the Lisp camp am still not convinced as to
the unconditionally superiority of the dynamic aspects of the type system.

What happens when the program is being put to actual use by actual end
users, who outnumbers the programmer(s) who made the program many
thousand times? The programmer(s) who made the program will not be there
to do their magic stuff at the top level in the break loop when the
program rolls over and falls into the break loop so to speak.

I guess you have to wrap everything important in a handler-case or
ignore-errors with a handler that can
restart/retry/shutdown/bugreport/etc. Just like you would do to for
instance a java program to handle runtime errors.

But if this is the case, then is all this dynamic typing stuff only of
benefit during development and debugging, and of no use during actual
use by end users because at that time going into the break loop equals a
crashed program?

Kristian

sajiimori

unread,
Jan 26, 2004, 4:17:50 AM1/26/04
to
> Ideally they could catch this. But consider the correct implementation
> using a compiler macro:

Don't worry; I wasn't trying to pass that code off as "correct". =) I only
had a very specific question about one CL implementation in particular.


sajiimori

unread,
Jan 26, 2004, 4:38:54 AM1/26/04
to
> > My first impulse is to agree, but the biggest (generally agreed upon)
> > benefit of static typing is that type errors are caught at compile-time,
>
> I think you are a bit behind the times. The hard-core, static-typing C++
> crowd has changed its mind:

Thanks, but I'm not particularly interested in arguments from authority.

Besides, the quote from Bruce Eckel doesn't seem to argue against static
typing -- all it says is that the compiler can't guarantee that your program
is correct (which should be obvious).

> Martin also contradicts your lack of enthusiasm for dynamic languages:

Sorry, I'll try to post with more enthusiasm next time. Do I need more
smileys? (I guess I can't say the word 'static' without getting
pidgeon-holed.)

> So maybe you should get off Usenet and do some Lisp and find out what
> you are missing.

I wonder how you got the impression that I have not used Lisp? (This
newsgroup seems to have a taboo against discussing language features.)

I think I may take your advice and stop posting here... everybody is so
hostile. It's really shocking to go from a friendly community of developers
(like the Gameboy Advance forum I visit often) to a group like this one. It
really makes me lose a bit of faith in the Internet, and in human decency in
general.


sajiimori

unread,
Jan 26, 2004, 4:59:30 AM1/26/04
to
Also, Robert Martin is comparing Python and Ruby to C++ and Java, saying
that dynamic typing made things much easier. No suprise there.

I'd imagine that if he were comparing to OCAML or Haskell he wouldn't see
such a clear distinction. But that's just speculation.


Erik Naggum

unread,
Jan 26, 2004, 5:12:25 AM1/26/04
to
* Kristian Elof Sørensen

| I too am a recent arrival to the Lisp camp am still not convinced as
| to the unconditional superiority of the dynamic aspects of the type
| system.

Nobody implied it was unconditionally superior. You have to lose this
«one winner takes all» attitude. Different solutions can coexist. In
fact, different solutions /must/ coexist for the proper solution to be
applied to problems that differ from the historic problems to which
they were the solutions. Think evolution. In the real world, there
are no winners, only temporary advantages. The myth of the «winner»
is probably the second most destructive myth that Western civilization
has hoisted upon its population. (The most destructive myth is that
of people being either «good» or «evil», which is the root cause of
all injustice ever perpetrated by humans.)

| But if this is the case, then is all this dynamic typing stuff only of
| benefit during development and debugging, and of no use during actual
| use by end users because at that time going into the break loop equals
| a crashed program?

What «this» refers to is not the case and none of the above follows.

If you insist that the way you view the world is the only only possible
(as is implied by resorting to «unconditional superiority»), everything
will turn out to run against your world-view sooner or later, and this
will naturally be interpreted as there being something wrong with the
world. For instance, when you equate a handled error condition with a
crash, you look at only the most superficial quality of a failure: That
it does something other than the user wanted. But most of the time,
real-world applications have an extremely strong requirement to either
complete their task to specification or not do any harm. The Common
Lisp condition system is eminently able to make computers behave in
the most rational way possible when they are unable to complete a task.

I strongly suggest that you not explore the boundary conditions until
you are comfortable with the normal operating parameters. This means
that you have to lose «unconditional», «all», «only», «of no use», etc.

Incidentally, type errors are irrelevant. They just do not happen in
Common Lisp code as often as they do in languages where the compiler
is responsible for catching them. It is understandable that someone
who has been burned hard and often by compilers who never seem to be
satisfied with one's code no matter how hard one tries, will believe
that this kind of mistake is very important and stands between him and
total disaster of the program. However, this is not how it works in
Common Lisp, because Common Lisp systems do not crash. They are so
forgiving and friendly that anyone who approaches them believing that
they will be hostile and interpret their responses as if they could
only have been hostile, will misunderstand and fight the system, much
like they would people they mistakenly believe are hostile.

Tayssir John Gabbour

unread,
Jan 26, 2004, 6:41:20 AM1/26/04
to
I think you will want to explicate what precisely you want from a
static lisp. More on this below.


"sajiimori" <myuse...@hotmail.com> wrote in message news:<xg2Rb.27138$1e.1...@newsread2.news.pas.earthlink.net>...


> Interesting... Do you have an example of how running a program can lead to
> the discovery of the source of a static typing error? I would think that
> since nothing that happens at runtime can affect static typing, there would
> be no useful information to glean about such an error.

Many lispers seem to believe hardcore static fans suffer from
tunnelvision. A system that statically catches type errors is
subordinate to the goal of writing generally good code. For which
analyzing statically verifiable errors is a possible resource.

Let's make the assumption that errors tend to cluster. Perhaps some
other guy was experimenting with drugs and wrote some mind-altering
code for three hours. With normal languages, the testing phase
branches -- you have tests at compiletime, and another at runtime.
You effectively lose the compiletime information at runtime.

/Static analysis does not mean it must run at compiletime./ What if I
had a file from which I could import type data, which the static
checker uses in helping diagnose the codebase? Or I could
incrementally give static data and ask what some analyzer thinks.
Imagine the implications for software engineering if we had tools
which could say, "Check out module Frobule; there is a high incidence
of problems in code which calls it."

I AM NOT impugning static analysis. Far from it; proving properties
about code is wonderful. However, there is this insane presumption,
orthogonal to static analysis, that says we must run screaming from
errors with our hands over our ears. I don't think this is a fault in
anyone, just our byzantine languages and educations that pressure us
into being macho and hiding our faults as soon as possible, before
anyone else can see them.

Anyway, good luck on experimenting with your static analyzer! If I
sound ranty, it's because I've been playing around with an assembly
language environment (MIT's BSim) and this diaperless environment is
SO MUCH better than these other languages I've messed around with save
for lisp.


> My first impulse is to agree, but the biggest (generally agreed upon)
> benefit of static typing is that type errors are caught at compile-time, and
> that benefit can only be reaped by restricting yourself from doing anything
> that would violate the system.

This is a case where a bunch of people agreeing doesn't count for
anything. You wish to do an innovative thing, creating a static lisp.
Therefore you can stand a little zigging while others zag.

Erik Naggum

unread,
Jan 26, 2004, 6:54:41 AM1/26/04
to
* Tayssir John Gabbour

| /Static analysis does not mean it must run at compiletime./

Actually, that it run at compile time is the definition of «static» --
it requires no dynamic (= run-time) information.

| However, there is this insane presumption, orthogonal to static
| analysis, that says we must run screaming from errors with our hands
| over our ears. I don't think this is a fault in anyone, just our
| byzantine languages and educations that pressure us into being macho
| and hiding our faults as soon as possible, before anyone else can see
| them.

Well said. :)

Tayssir John Gabbour

unread,
Jan 26, 2004, 7:15:44 AM1/26/04
to
"sajiimori" <myuse...@hotmail.com> wrote in message news:<BA1Rb.27109$1e....@newsread2.news.pas.earthlink.net>...

> You folks sure are touchy -- I didn't even say that I want static or
> implicit typing. I thought it would take at least a few posts before the
> rudeness began.

You're wrong here. Erik was very polite. Did you notice most people
presume software people are rude by being very exacting with peers,
almost to the point of triviality?

And it's not just "software people"; you'll find it among people who
care about what they do. Or social retards, but I'm talking generally
and there are exceptions.

Eric Marsden

unread,
Jan 26, 2004, 9:18:13 AM1/26/04
to
>>>>> "sm" == sajiimori <myuse...@hotmail.com> writes:

sm> If I were still running a Unix, I'd check out CMUCL -- as it is, I've only
sm> seen CLISP and Corman, neither of which catch type errors at compile time.
sm> :( Would CMUCL warn about this during compile-time? If not, do you think
sm> it should?
sm>
sm> (defun x-plus-y (x y)
sm> (+ x y))
sm>
sm> (defun test ()
sm> (x-plus-y 5 "asdf"))

in its default mode of operation, the CMUCL compiler assumes that a
function may be redefined at runtime (unless it is declared to be
inlineable). Therefore, it doesn't generate a warning when compiling
code like this.

However, CMUCL's block-compilation mechanism allows you to tell the
compiler that functions won't be redefined at runtime, which gives you
semantics closer to static languages like C/Java/ML. There are a
number of ways to obtain block-compilation (see the CMUCL User's
Manual); one of them is to provide extra arguments to COMPILE-FILE.

,----
| CL-USER> (compile-file "err" :block-compile t :entry-points '(test))
| ; File: /tmp/err.lisp
| ; In: defun x-plus-y
| ; (+ x y)


| ; Warning: Lisp error during constant folding:
| ; Argument y is not a number: "asdf".

`----

--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>

Hannu Koivisto

unread,
Jan 26, 2004, 11:18:11 AM1/26/04
to
"sajiimori" <myuse...@hotmail.com> writes:

> That's exactly what I'm hoping for, because I'm trying to make a Lispy
> language that uses strong, static, implicit typing (just as an experiment --
> I don't know if I would even use such a language in place of CL).

Feel free to do that if you think it is the most useful approach (I
don't), but in the spirit of Erik's "Different solutions can
coexist" comment, instead of making a new language, you could take
a look at soft typing¹, researched quite a bit by the PLT Scheme¹
folks and realized in, for example, MrSpidey¹. Although one could
say that CMUCL effectively has that sort of stuff built-in, the
"external tool" approach of the PLT people might be a better match
if you liked to experiment with your own code in the context of
Common Lisp in general (I think this would be quite interesting).
Their work is also backed by papers that you can delve into,
whereas CMUCL's analysis is more ad-hoc and not very well
documented, IIRC.

----
¹ Google this.
--
Hannu

Kenny Tilton

unread,
Jan 26, 2004, 11:22:21 AM1/26/04
to
sajiimori wrote:
>
> > > My first impulse is to agree, but the biggest (generally agreed upon)
> > > benefit of static typing is that type errors are caught at compile-time,
> >
> > I think you are a bit behind the times. The hard-core, static-typing C++
> > crowd has changed its mind:
>
> Thanks, but I'm not particularly interested in arguments from authority.

What about arguments from superiority? You couldn't carry Eckel or
Martin's lunch pail.

> I think I may take your advice and stop posting here... everybody is so
> hostile. It's really shocking to go from a friendly community of developers
> (like the Gameboy Advance forum I visit often) to a group like this one. It
> really makes me lose a bit of faith in the Internet, and in human decency in
> general.

Don't judge all of Usenet by us, the Savages of Comp.lang.lisp. Trolls
survive for weeks on other NGs, we The Savages chew them up and spit
them out in days.

Joe Marshall

unread,
Jan 26, 2004, 11:42:15 AM1/26/04
to
tayss...@yahoo.com (Tayssir John Gabbour) writes:

> /Static analysis does not mean it must run at compiletime./

It does mean that it has to run *before* run time, though.

Joe Marshall

unread,
Jan 26, 2004, 11:53:36 AM1/26/04
to
"sajiimori" <myuse...@hotmail.com> writes:

>> What qualities of dynamic typing would be missing?
>
> Good question... how about this?
>
> (setq x 5)
> (setq x "hello")

I do this sort of thing.

> Or this?
>
> (typecase (read)
> (integer (print "you typed an integer"))
> (string (print "you typed a string"))
> (t (print "i don't know what you typed")))
>

And this. As a matter of fact, I find myself doing this more and
more.

I would not want to use a language that did not let me do this sort of
thing.

---

I imagine that you may want an example, though. I have a versioned
transaction system where a transaction takes `version specifier' as an
argument. The version specifier may take on many possible forms:

a literal bitmap specifying which composite elements to use

the keyword :LATEST

a versioned object reference indicating indirection through a
meta-versioned context

and certain combinations of those.

Actually, the code that constructs the version from the version
specifier is recursive, so I need a recursive discriminated union.
Fortunately, Lisp objects are a recursive discriminated union.

It is type-safe, though. If you pass in a floating point number, you
will get an error.


Marco Antoniotti

unread,
Jan 26, 2004, 12:26:15 PM1/26/04
to

sajiimori wrote:

Well, yes. There is nothing "bad" about dynamic typing. The bottom
line is that I want the "environment" to be helpful. Static typing has
the potential to do a lot, but it has not done much for me in the past.
Especially when I had to introduce lots and lots of parenthesis just
to placate the type checker.

Call it as you want, consider it a real challenge. Add some form of
static typing to Common Lisp in such a way to maintain backward
compatibility in the sense that every conformant CL program (with
"conformant" being defined in the ANSI spec).

That would be a truly challenging research project. (Incidentally there
are people working on this.) A "new" Lisp with static typing would not
be very interesting to me.

Cheers
--
Marco

Marco Antoniotti

unread,
Jan 26, 2004, 12:39:06 PM1/26/04
to

sajiimori wrote:

>>The mindset of static typers seems to be
>>that when the compiler complains about a static type error, you should
>>not be allowed at all to run your program. This doesn't make sense,
>>especially in scenarios in which a run of an erroneous program could
>>actually help you to detect the source of a problem.
>
>
> Interesting... Do you have an example of how running a program can lead to
> the discovery of the source of a static typing error? I would think that
> since nothing that happens at runtime can affect static typing, there would
> be no useful information to glean about such an error.

I think what Pascal was hinting here, is that "semantic" errors due to
non-typing issues (e.g. race coniditons, inproper control flows etc) may
be identified earlier if you could run a program that did not pass the
type checker.

>>From an engineering
>>point of view, it does not make sense to restrict your toolset.
>
>
> My first impulse is to agree, but the biggest (generally agreed upon)
> benefit of static typing is that type errors are caught at compile-time, and
> that benefit can only be reaped by restricting yourself from doing anything
> that would violate the system. I guess it depends on what freedoms you'd be
> willing to forfeit (if any) to have that feature -- which is sort of what my
> original question was about.

Again this is the issue. What "programming freedoms are you willing to
forfeit". Common Lispers (at least the writer :) ) are not willing to
forfeit anything that would break a conformant Common Lisp program.
That is *not* to say that you do not want static typing (CMUCL and SBCL
do quite a bit of it, and I am sure the commercial implementations are
as good in many respects.) It is to say that you want static typing
when it helps and when it does not interfere with time-honored (and,
allow me to say, sound) programming activities.

I do not have CMUCL handy as I write, but: (1) you can make CMUCL
complain at compile time, (2) even if CMUCL complains, I still want to
be able to write afterward

(defun test2 ()
(if (read) (test) 42))

(test2)

compile it and run it.


>
>>Again, whether a language is dynamically or
>>statically typed does not determine whether it is a good language.
>>Programming languages are holistic entities, in the sense that all the
>>distinguishing features have to complement each other well.
>
>
> Of course! So, as a variant of my original question: In a statically,
> implicitly typed Lisp, do you think the features would still complement each
> other well?

That is the challenge for you :) First of all you have to substitute
"Lisp" with "Common Lisp" and then you have to make sure that such
features do complement each other well.

Cheers

--
Marco

Thomas F. Burdick

unread,
Jan 26, 2004, 12:43:46 PM1/26/04
to
Erik Naggum <er...@naggum.no> writes:

> * Tayssir John Gabbour
> | /Static analysis does not mean it must run at compiletime./
>
> Actually, that it run at compile time is the definition of «static» --
> it requires no dynamic (= run-time) information.

You forgot about load time. If you're doing static analysis to assist
the programmer, compile time is the appropriate time, but if you're
doing static analysis for safety reasons (eg, we only load modules
that follow these rules), you need to work at load time. In the most
likely case, you actually did the static analysis at compile time and
generated a proof for the load time checker to use, but conceptually
(and literally if you don't have compiler support) the checking is
done at load time.

--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'

Ray Dillinger

unread,
Jan 26, 2004, 12:51:48 PM1/26/04
to

What would be cool is a program that attempts to statically prove code
to be type sound. Some programs it will succeed on, and then you can be
*sure* that no type error is possible in those programs.

Other programs it will fail on, and in that case it's the programmers'
responsibility to make sure that type errors do not actually occur.

The idea though is that a correct program is a correct program, regardless
of whether it can be automatically proven to not generate type errors. It's
certainly a useful thing to know if it can be proven, but it is often true
even when it can't be proven. And correct programs ought to run.

There's a performance boost to be had by using the type correctness proof
as justification to remove all type checks and type-error generating code
from a program; but a lot of dynamic-typing compilers do much of that sort
of work incrementally, so there may not be much performance left to claim.

Bear

Thomas F. Burdick

unread,
Jan 26, 2004, 1:19:49 PM1/26/04
to
Ray Dillinger <be...@sonic.net> writes:

> sajiimori wrote:
> >
> > > Yes, I would use it, as long as any conformant Common Lisp program would
> > > run in it. Otherwise, I would not be so interested.
> >
> > Hmm...I guess it would have to support dynamic typing as a fallback then.
>
> What would be cool is a program that attempts to statically prove code
> to be type sound. Some programs it will succeed on, and then you can be
> *sure* that no type error is possible in those programs.
>
> Other programs it will fail on, and in that case it's the programmers'
> responsibility to make sure that type errors do not actually occur.

One important idea to keep in mind when thinking about static
analysis, when you're asking it to prove something that cannot be
proved or disproved in the general case, is: there are three things
that can happen; it can prove the code correct, it can fail to prove
anything, or it can prove the code to be incorrect. A lot of the time
the people seem to think of the last two as the same case, whereas
they're very very different.

Joe Marshall

unread,
Jan 26, 2004, 1:56:23 PM1/26/04
to
t...@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:

> One important idea to keep in mind when thinking about static
> analysis, when you're asking it to prove something that cannot be
> proved or disproved in the general case, is: there are three things
> that can happen; it can prove the code correct, it can fail to prove
> anything, or it can prove the code to be incorrect. A lot of the time
> the people seem to think of the last two as the same case, whereas
> they're very very different.

Unless you perform one of the two following sleights of hand:

Define `correctness' as passing the static analysis. Code that does
not is ipso facto incorrect.

Define `code' as that which passes the static analysis. Things that
do not are not even code.

(These are usually followed by the definition of a type error as only
those errors caught via static analysis, which leads to the conclusion
that runtime type errors cannot happen.)

Brian Mastenbrook

unread,
Jan 26, 2004, 2:20:27 PM1/26/04
to
In article <xg2Rb.27138$1e.1...@newsread2.news.pas.earthlink.net>,
sajiimori <myuse...@hotmail.com> wrote:

> (defun x-plus-y (x y)
> (+ x y))
>
> (defun test ()
> (x-plus-y 5 "asdf"))

Argument Y is not a NUMBER: "asdf".
[Condition of type SIMPLE-TYPE-ERROR]

Select the abort restart...

(defgeneric x-plus-y (x y))

(defmethod x-plus-y ((x number) (y number))
(+ x y))

(defmethod x-plus-y (x (y string))
(concatenate 'string (prin1-to-string x) y))

CL-USER> (test)
"5asdf"

The point is that in general, in Common Lisp, you don't know ahead of
time what values a function may accept. Without changing the definition
of "test", I made it execute without error - thus why should the
compiler yell at you for something which is a /current, possible/ error
in the code?

Errors in compilation only mean that the code is meaningless. The code
you provided was not meaningless. Its meaning happened to involve a
runtime error, but not meaninglessness. And there is no way to make the
compiler gag on the above without destroying the dynamicity of the
language.

--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/

Erik Naggum

unread,
Jan 26, 2004, 2:43:54 PM1/26/04
to
* Thomas F. Burdick

| You forgot about load time.

No. I'm trying very hard to prevent «static» from being redefined
away from the accepted meaning in the computer science literature.

Maybe it helps to admit to the ulterior motive -- I want to show that
if you accept the standard meaning of «static» to mean /syntactic/
analysis, with as little (dynamic) semantics as possible, what you can
determine may well be gratifying to the computer scientist who works
hard on his thesis, but it is completely irrelevant in the real world,
and in fact detrimental to every other kind of software quality.

Paolo Amoroso

unread,
Jan 26, 2004, 2:58:26 PM1/26/04
to
Kristian Elof Sørensen <el...@image.dk> writes:

> What happens when the program is being put to actual use by actual end
> users, who outnumbers the programmer(s) who made the program many
> thousand times? The programmer(s) who made the program will not be
> there to do their magic stuff at the top level in the break loop when
> the program rolls over and falls into the break loop so to speak.

Not necessarily. Check the article in which Paul Graham explains how
bugs were fixed at ViaWeb (later Yahoo! Store) while the customers who
reported them were still at the phone.


Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

Erann Gat

unread,
Jan 26, 2004, 3:20:39 PM1/26/04
to
In article <32841350348...@naggum.no>, Erik Naggum
<er...@naggum.no> wrote:

> * Thomas F. Burdick
> | You forgot about load time.
>
> No. I'm trying very hard to prevent «static» from being redefined
> away from the accepted meaning in the computer science literature.
>
> Maybe it helps to admit to the ulterior motive -- I want to show that
> if you accept the standard meaning of «static» to mean /syntactic/
> analysis, with as little (dynamic) semantics as possible, what you can
> determine may well be gratifying to the computer scientist who works
> hard on his thesis, but it is completely irrelevant in the real world,
> and in fact detrimental to every other kind of software quality.

Do you have any evidence or arguments to support this view? (My ulterior
motive: I would like very much to believe that your thesis is true, being
a fan of dynamism myself, but find I can muster very little to support it
other than my own personal experience, which doesn't carry much weight in
certain arenas that are relevant to me.)

E.

sajiimori

unread,
Jan 26, 2004, 4:00:17 PM1/26/04
to
> You're wrong here. Erik was very polite. Did you notice most people
> presume software people are rude by being very exacting with peers,
> almost to the point of triviality?

>
> And it's not just "software people"; you'll find it among people who
> care about what they do. Or social retards, but I'm talking generally
> and there are exceptions.

Maybe...I consider myself a "software people" (and an occasional social
retard), but I also consider my tendancy for excessive precision to be a
character flaw, and I make an effort to restrain myself in order to maintain
civil relationships.

That aside, I don't think any level of precision would lead a reasonable,
cooperative person to the conclusion that I "want to take a step backwards",
given the text of my original post. Erik's response was nothing but an
underhanded attack on a position that I never even took up.

I tried to frame my questions in a way that would avoid a flamewar, but some
people are so interested in creating conflict that they'll go out of their
way to misinterpret others and put words in their mouths.


sajiimori

unread,
Jan 26, 2004, 4:16:21 PM1/26/04
to
> However, CMUCL's block-compilation mechanism allows you to tell the
> compiler that functions won't be redefined at runtime

Hey, that's great! For the projects I've done so far in CL, I would
probably turn on such a feature globally. Then if the time comes that
rebinding function values of symbols (via defun, not labels) seems useful,
it would be nice to be able to fall back to the normal compilation style.


Kenny Tilton

unread,
Jan 26, 2004, 4:27:38 PM1/26/04
to
sajiimori wrote:
> I tried to frame my questions in a way that would avoid a flamewar, but some
> people are so interested in creating conflict that they'll go out of their
> way to misinterpret others and put words in their mouths.

If you are so interested avoiding flamewars, why are you adding fuel to
this one? Looks like non-avoiding avoidance to me.

I agree you received a chilly reception with your static worship, but
static vs. dynamic is of course an oft-contested battle, and perhaps as
a newcomer you did not realize how weary of it we denizens of cll might
be. Chilliness aside, you get the prize for kicking off the name-calling
by slurring the whole group because you came in like a bull in a china
shop.

When you go to Boston, do you wear Bucky Dent or Aaron Boone jerseys?
You are like the Boston groundskeeper who got his ass kicked in the
Yankee bullpen for celebrating a Boston success and then wonders why.

kenny


--

http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama

Erik Naggum

unread,
Jan 26, 2004, 4:33:22 PM1/26/04
to
* sajiimori

| Erik's response was nothing but an underhanded attack on a position
| that I never even took up.

Amazing. You are clearly malfunctioning. Please do not involve me in
your messy breakdown.

| I tried to frame my questions in a way that would avoid a flamewar,
| but some people are so interested in creating conflict that they'll go
| out of their way to misinterpret others and put words in their mouths.

I do not appreciate your being so interested in creating conflict that
you go out of your way to misinterpret me and put words in my mouth.
I do not appreciate your need to blame me for your very own flaws.

You are the only hostile person here. /Please calm down./

sajiimori

unread,
Jan 26, 2004, 4:44:48 PM1/26/04
to
> Argument Y is not a NUMBER: "asdf".
> [Condition of type SIMPLE-TYPE-ERROR]
> ...

> The point is that in general, in Common Lisp, you don't know ahead of
> time what values a function may accept. Without changing the definition
> of "test", I made it execute without error - thus why should the
> compiler yell at you for something which is a /current, possible/ error
> in the code?

I don't understand. I thought you were posting an example of CMUCL issuing
a warning about a current, possible error. So at first, I thought you were
saying "yeah, CMUCL can do that", but then it sounded like you didn't think
the feature makes sense. Were you giving an example of a feature of CMUCL
that you don't like?

> Errors in compilation only mean that the code is meaningless. The code
> you provided was not meaningless. Its meaning happened to involve a
> runtime error, but not meaninglessness.

Agreed. In other languages, code like that might very well be meaningless.
(I've been informed that Eclipse can run Java code that has type errors, but
Eclipse is very generous to do so, because such code isn't really in Java.)

> And there is no way to make the
> compiler gag on the above without destroying the dynamicity of the
> language.

Well, you can get CMUCL to at least warn about it (using what Eric Marsden
informed me is called block-compilation), right? I suppose you could say
that enabling that feature destroys the dynamicity of the language, but as
Pascal Costanza argued earlier, why restrict your toolset? I might want
static type checking sometimes.


sajiimori

unread,
Jan 26, 2004, 4:47:42 PM1/26/04
to
> Feel free to do that if you think it is the most useful approach (I
> don't), but in the spirit of Erik's "Different solutions can
> coexist" comment, instead of making a new language, you could take
> a look at soft typingน, researched quite a bit by the PLT Schemeน
> folks and realized in, for example, MrSpideyน. Although one could

> say that CMUCL effectively has that sort of stuff built-in, the
> "external tool" approach of the PLT people might be a better match
> if you liked to experiment with your own code in the context of
> Common Lisp in general (I think this would be quite interesting).
> Their work is also backed by papers that you can delve into,
> whereas CMUCL's analysis is more ad-hoc and not very well
> documented, IIRC.

I was reading about soft-typing for Scheme recently -- to be honest, most of
the papers were a little over my head. =) I recall reading that most
function return types and variable types couldn't be inferred to a
significant degree (perhaps because idiomatic Scheme tends to be too
dynamic).

I think I'll have to set up some sort of Unix again, just to try out
CMUCL... it's sounding better by the minute.


Pascal Costanza

unread,
Jan 26, 2004, 4:55:55 PM1/26/04
to

sajiimori wrote:

> Interesting... Do you have an example of how running a program can lead to
> the discovery of the source of a static typing error? I would think that
> since nothing that happens at runtime can affect static typing, there would
> be no useful information to glean about such an error.

Imagine a Java class C that needs to implement an interface I. Assume
that I requires you to implement quite a large number of methods, but
that you currently only want to focus on a few of them. Let's say you
want to implement an test m, but I additionally requires you to
implement n and o. You can't write the following and test the code
straight ahead.

class C implements I {

void m() {...}

}

No, you have to add dummy definitions for n and o:

class C implements I {

void m() {...}

void n() {}

int o() {}

}

Hey, wait, the compiler still doesn't accept this. You need to return
something from o.

class C implements I {

void m() {...}

void n() {}

int o() {return 0;}

}

Now, you might get into real trouble here: 0 is most probably not the
right result for o (and neither is doing nothing the right behavior for
n). Your goal was to focus on implementing and testing m, and this is
what you probably want to do right now. If n and o go unnoticed for some
time now, you might get funny results from test runs of a whole program.
So in fact, (enforced) static type checking has made your program more
buggy rather than more correct. BTW, the right way to implement dummy
methods so that they behave well in unit tests is this:

class C implements I {

void m() {...}

void n() {
throw new RuntimeException("C::n not yet implemented");
}

int o() {
throw new RuntimeException("C::o not yet implemented");
}
}

This is _exactly_ what dynamically typed languages do by default when
functions/methods are called that don't exist yet. So my conclusions are:

a) Statically typed languages distract you from your flow of thinking.
(See how much you need to do before you can proceed with your original
goal, to work on m.)

b) Dynamically typed languages implement the behavior by default that
you need to write yourself repeatedly in a statically typed language.

Now one might object that Java has a bad type system and that it's
unfair to judge the notion of static typing based on a bad type system.
However, I think that at least a still holds even in languages like ML
and Haskell.

The right question is not whether static typing is good or bad, but what
combination of language features make a good programming language.

>>From an engineering
>>point of view, it does not make sense to restrict your toolset.
>
> My first impulse is to agree, but the biggest (generally agreed upon)
> benefit of static typing is that type errors are caught at compile-time, and
> that benefit can only be reaped by restricting yourself from doing anything
> that would violate the system. I guess it depends on what freedoms you'd be
> willing to forfeit (if any) to have that feature -- which is sort of what my
> original question was about.

No, it's not a generally agreed upon benefit of static typing that type
errors are caught at compile-time. There are sufficiently big
communities behind dynamically typed languages to render this statement
incorrect. But more to the point, the biggest problem with this claim is
that it's circular. Static type systems have not been designed to
prevent errors that programmers actually make, but they are rather
mathematically attractive proof systems that prevent exactly what they
happen to be able to prevent, nothing more, nothing less. There are no
serious empirical studies out there that actually show that programmers
make these errors, nor are there studies that show that programmers
don't make them. This is purely guesswork. And even if there were
studies that showed a considerably high number of certain kinds of type
errors made by programmers, this still wouldn't mean that static type
system would be the right answer. It could be that training programmers
in a certain way could be much more effective. This is in fact another
problem of computer scientists: They tend to devise technological
solutions for what are in fact social problems. That's probably because
they are good at defining algorithms, but forget that algorithms don't
work on people. (As a sidenote: People learn very well by making
mistakes. Preventing them to make mistakes is not very clever in this
light.)

>>What good dynamically typed languages give you beyond better debugging
>>facilities is the ability to change a program at run time, which means
>>adding, removing or changing features dynamically. Especially the
>>removal of features is not handled very well in statically typed
>>languages. Dynamic software evolution enables a whole range of new
>>deployment models, like running your software on a web server and being
>>able to update it without any downtimes.
>
> These ideas are still pretty new to me. What do you mean by "removing
> features", and why does the type system affect it so much?

Imagine a class C providing a public definition for a method m. Now
imagine that you want to remove method m from your running program
altogether. If a programming language allows for such a removal of
methods at run time, this makes a static type check nearly impossible.

The ability to add, remove or change features at run time makes
modelling of certain real-world events much simpler. Think of children
who grow up to becoming adults, take on a job, become self-employed, get
a doctoral degree, and so forth. Some even change their sex. Dynamically
typed languages are much better able to handle even unanticipated changes.

>>It's important to note that the kind of type system is not the only
>>important factor, and that the default typing "philosophy" of a language
>>does not necessarily preclude the switch to the other one.
>
> That's exactly what I'm hoping for, because I'm trying to make a Lispy
> language that uses strong, static, implicit typing (just as an experiment --
> I don't know if I would even use such a language in place of CL).

This has been done before. You might want to google for papers on this
issue.

> If I were still running a Unix, I'd check out CMUCL -- as it is, I've only
> seen CLISP and Corman, neither of which catch type errors at compile time.
> :( Would CMUCL warn about this during compile-time? If not, do you think
> it should?
>

> (defun x-plus-y (x y)
> (+ x y))
>
> (defun test ()
> (x-plus-y 5 "asdf"))

Do you think this is an example of a typical error programmers make?

>>Again, whether a language is dynamically or
>>statically typed does not determine whether it is a good language.
>>Programming languages are holistic entities, in the sense that all the
>>distinguishing features have to complement each other well.
>
> Of course! So, as a variant of my original question: In a statically,
> implicitly typed Lisp, do you think the features would still complement each
> other well?

I don't know. Maybe, maybe not. For several reasons, the statically
typed languages I have seen so far are not very convincing to me. I have
thought otherwise in the past, but learning about Common Lisp has taught
me many important lessons in this regard.

The single most important feature of Lisp for me is its metacircularity,
both in its simple form available as macro programming and in its more
structured form as the CLOS metaobject protocol. I simply can't imagine
how this could be achieved in a statically typed language.

But if you happen to be able to devise such a thing I wouldn't mind
using it.

You know, Common Lispers sound very religious at times, but they are
actually extremely pragmatic. They just want to use the best tool for
their job. ;)


Pascal

--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."

Pascal Costanza

unread,
Jan 26, 2004, 5:02:12 PM1/26/04
to

Kristian Elof Sørensen wrote:

> What happens when the program is being put to actual use by actual end
> users, who outnumbers the programmer(s) who made the program many
> thousand times?

What makes you think that end users are necessarily not able to handle
such complexities.

For example, http://joint.org/use2003/Papers/18500041.pdf is a paper
that describes how end users have used the metaobject protocl of Xotcl
to extend the program they have worked with. IIRC, they have added some
very non-trivial etensions. And these were not regular programmers before.

Why is it that programmers always seem to think that the rest of the
world is stupid?

sajiimori

unread,
Jan 26, 2004, 5:04:08 PM1/26/04
to
> I think what Pascal was hinting here, is that "semantic" errors due to
> non-typing issues (e.g. race coniditons, inproper control flows etc) may
> be identified earlier if you could run a program that did not pass the
> type checker.

It sounds like you're talking about having the choice of which bugs to fix
first. That does seem like a good thing.

> Common Lispers (at least the writer :) ) are not willing to
> forfeit anything that would break a conformant Common Lisp program.

*gasp* -- A straightforward answer to the original question! =)

> > Of course! So, as a variant of my original question: In a statically,
> > implicitly typed Lisp, do you think the features would still complement
each
> > other well?
>
> That is the challenge for you :) First of all you have to substitute
> "Lisp" with "Common Lisp" and then you have to make sure that such
> features do complement each other well.

After hearing more about CMCUL, I'm wondering if the challenge is still
there to be had. Maybe all you have to do to get a statically typed CL is:

1) Write a CL program that doesn't do anything particularly dynamic.

2) Compile it with CMUCL, with all the type checking facilities turned on.


Pascal Costanza

unread,
Jan 26, 2004, 5:07:18 PM1/26/04
to

Erik Naggum wrote:

> * Tayssir John Gabbour
> | /Static analysis does not mean it must run at compiletime./
>
> Actually, that it run at compile time is the definition of «static» --
> it requires no dynamic (= run-time) information.

Compilation means to translate one representation of a program into
another one. Static analysis doesn't necessarily involve such a translation.

Erik Naggum

unread,
Jan 26, 2004, 5:26:36 PM1/26/04
to
* Pascal Costanza

| Why is it that programmers always seem to think that the rest of the
| world is stupid?

Because they are autodidacts. The main purpose of higher education
and making all the smartest kids from one school come together with
all the smartest kids from other schools, recursively, is to show every
smart kid everywhere that they are not the smartest kid around, that
no matter how smart they are, they are not equally smart at everything
even though they were just that to begin with, and there will therefore
always be smarter kids, if nothing else, than at something other than
they are smart at. If you take a smart kid out of this system, reward
him with lots of money that he could never make otherwise, reward him
with control over machines that journalists are morbidly afraid of and
make the entire population fear second-hand, and prevent him from ever
meeting smarter people than himself, he will have no recourse but to
believe that he /is/ smarter than everybody else. Educate him properly
and force him to reach the point of intellectual exhaustion and failure
where there is no other route to success than to ask for help, and he
will gain a profound respect for other people. Many programmers act
like they are morbidly afraid of being discovered to be less smart than
they think they are, and many of them respond with extreme hostility on
Usenet precisely because they get a glimpse of their own limitations.
To people whose entire life has been about being in control, loss of
control is actually a very good reason to panic.

Thomas F. Burdick

unread,
Jan 26, 2004, 5:28:44 PM1/26/04
to
Erik Naggum <er...@naggum.no> writes:

> * Thomas F. Burdick
> | You forgot about load time.
>
> No. I'm trying very hard to prevent «static» from being redefined
> away from the accepted meaning in the computer science literature.

I don't think what I described is doing that. Essentially, I was
describing Proof-Carrying Code.

> Maybe it helps to admit to the ulterior motive -- I want to show that
> if you accept the standard meaning of «static» to mean /syntactic/
> analysis, with as little (dynamic) semantics as possible, what you can
> determine may well be gratifying to the computer scientist who works
> hard on his thesis, but it is completely irrelevant in the real world,
> and in fact detrimental to every other kind of software quality.

I think you're describing static typing, which is only one part of the
big world of static analysis. Unfortunately, it's where most effort
seems to go -- and it's also fairly useless, IMO.

Erik Naggum

unread,
Jan 26, 2004, 5:29:49 PM1/26/04
to
* Pascal Costanza

| Compilation means to translate one representation of a program into
| another one. Static analysis doesn't necessarily involve such a
| translation.

Yes, you can perform the static analysis without producing any output
upon success other than «like, wow, that was a type-correct program».

Thomas F. Burdick

unread,
Jan 26, 2004, 5:30:38 PM1/26/04
to
Joe Marshall <j...@ccs.neu.edu> writes:

> t...@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > One important idea to keep in mind when thinking about static
> > analysis, when you're asking it to prove something that cannot be
> > proved or disproved in the general case, is: there are three things
> > that can happen; it can prove the code correct, it can fail to prove
> > anything, or it can prove the code to be incorrect. A lot of the time
> > the people seem to think of the last two as the same case, whereas
> > they're very very different.
>
> Unless you perform one of the two following sleights of hand:

That's exactly the "a lot of the time" bit I was referring to above.
It would be okay if those people could keep it to themselves, but they
tend to blur the line in other people's heads, too.

sajiimori

unread,
Jan 26, 2004, 5:34:48 PM1/26/04
to
> Imagine a Java class C that needs to implement an interface I. Assume
> that I requires you to implement quite a large number of methods, but
> that you currently only want to focus on a few of them.

Great example -- thanks!

> No, it's not a generally agreed upon benefit of static typing that type
> errors are caught at compile-time.

I guess I should have said something like: "For all X who believe that
static typing has significant benefits, X is likely to believe that the
biggest benefit of static typing is the ability to catch type errors at
runtime." I apologize for my lack of precision.

> Dynamically
> typed languages are much better able to handle even unanticipated changes.

That makes sense.

> > That's exactly what I'm hoping for, because I'm trying to make a Lispy
> > language that uses strong, static, implicit typing (just as an
experiment --
> > I don't know if I would even use such a language in place of CL).
>
> This has been done before. You might want to google for papers on this
> issue.

I did, but I couldn't find anything that really supplied a pervasive,
implicit type system akin to that of Haskell.

> > Would CMUCL warn about this during compile-time? If not, do you think
> > it should?
> >
> > (defun x-plus-y (x y)
> > (+ x y))
> >
> > (defun test ()
> > (x-plus-y 5 "asdf"))
>
> Do you think this is an example of a typical error programmers make?

Of course not. It was a very specific question about one particular CL
implementation. (Why have I had to explain that so many times? I thought I
was being clear.)

> The single most important feature of Lisp for me is its metacircularity,
> both in its simple form available as macro programming and in its more
> structured form as the CLOS metaobject protocol. I simply can't imagine
> how this could be achieved in a statically typed language.

It seems like the simple answer is to provide static typing when it's both
possible and desirable.

> You know, Common Lispers sound very religious at times, but they are
> actually extremely pragmatic. They just want to use the best tool for
> their job. ;)

As usual, it depends on the individual. Practical people can be hostile
too, and that's what I have a problem with.


André Thieme

unread,
Jan 26, 2004, 5:35:24 PM1/26/04
to
Erik Naggum wrote:

> [...]

a nice little psychological report :)

sajiimori

unread,
Jan 26, 2004, 5:45:54 PM1/26/04
to
> Call it as you want, consider it a real challenge. Add some form of
> static typing to Common Lisp in such a way to maintain backward
> compatibility in the sense that every conformant CL program (with
> "conformant" being defined in the ANSI spec).

Would that even require extending CL? If all you're doing is statically
typing what you can, and leaving the rest dynamic (which you'd have to do to
allow all CL features), that's just an implementation issue (and I hear
CMUCL does implement something like that).


André Thieme

unread,
Jan 26, 2004, 5:45:15 PM1/26/04
to
Pascal Costanza wrote:

> class C implements I {
>
> void m() {...}
>
> void n() {
> throw new RuntimeException("C::n not yet implemented");
> }
>
> int o() {
> throw new RuntimeException("C::o not yet implemented");
> }
> }
>
> This is _exactly_ what dynamically typed languages do by default when
> functions/methods are called that don't exist yet. So my conclusions are:
>
> a) Statically typed languages distract you from your flow of thinking.
> (See how much you need to do before you can proceed with your original
> goal, to work on m.)
>
> b) Dynamically typed languages implement the behavior by default that
> you need to write yourself repeatedly in a statically typed language.

With a good IDE you can create such code with a fingertip on a hotkey.
The IDE will insert a lot of things that you would usually have to type
by yourself, so while programming you can let do the IDE the work and
continue working on your real problem.
For Java IDEA looks very nice.

sajiimori

unread,
Jan 26, 2004, 5:51:06 PM1/26/04
to
> static worship

Because you've committed yourself to intentional and hostile
misinterpretation, I'm not going to be replying to your posts anymore.
Sorry.


Jens Axel Søgaard

unread,
Jan 26, 2004, 5:49:48 PM1/26/04
to
sajiimori wrote:

> I was reading about soft-typing for Scheme recently -- to be honest, most of
> the papers were a little over my head. =) I recall reading that most
> function return types and variable types couldn't be inferred to a
> significant degree (perhaps because idiomatic Scheme tends to be too
> dynamic).

Some compilers make several compiled versions of the same function.
A little simplified: If the types of the arguments are known in
a specific function call, a specialized function is called.
If the types are unknown a general version is called. Using this
approach [but in a much more sophisticated way] Siskind and others
have gotten fine results.

--
Jens Axel Søgaard

sajiimori

unread,
Jan 26, 2004, 5:55:37 PM1/26/04
to
> With a good IDE you can create such code with a fingertip on a hotkey.
> The IDE will insert a lot of things that you would usually have to type
> by yourself, so while programming you can let do the IDE the work and
> continue working on your real problem.
> For Java IDEA looks very nice.

For me, the more I have to rely on an IDE to turn an unfriendly language
into a friendly one, the less I tend to appreciate the language itself.
When I kept hearing people say that Lisp is a pain unless you use EMACS, it
really turned me off for a while. In reality, it only took me about a week
to get used to it with a simpler editor (ConTEXT).


Pascal Costanza

unread,
Jan 26, 2004, 5:57:09 PM1/26/04
to

sajiimori wrote:

>>>That's exactly what I'm hoping for, because I'm trying to make a Lispy
>>>language that uses strong, static, implicit typing (just as an
>
> experiment --
>
>>>I don't know if I would even use such a language in place of CL).
>>
>>This has been done before. You might want to google for papers on this
>>issue.
>
&g