Static/Strong/Implicit Typing
sajiimori
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
| 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
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
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
> 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
> 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
> 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
> 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
> 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
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
> 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
| 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
will be satisfactory.
Erik Naggum
| 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
> 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
>
> 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
[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
> 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
> > 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
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
| I too am a recent arrival to the Lisp camp am still not convinced as
| 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
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
| /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
> 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
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
> 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
>
> > > 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
> /Static analysis does not mean it must run at compiletime./
It does mean that it has to run *before* run time, though.
Joe Marshall
>> 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
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
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
> * 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
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
> 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
> 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
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
| 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
> 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
<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
> 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
> 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
> 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
| 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
> [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
> don't), but in the spirit of Erik's "Different solutions can
> coexist" comment, instead of making a new language, you could take
> 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
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
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
> 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
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
| 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
> * 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
| 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
> 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
> 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
> [...]
a nice little psychological report :)
sajiimori
> 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
> 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
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
> 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
> 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
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.
>
> I did, but I couldn't find anything that really supplied a pervasive,
> implicit type system akin to that of Haskell.
See http://www.cs.utexas.edu/users/boyer/ftp/diss/akers.pdf
There are also other approaches. ACL2 and Qi might be of interest.
>>>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.)
This was a rhetoric answer. If this is not a typical error, why is it
relevant whether CMUCL warns about it or not?
Or to answer it more directly: I don't care whether a compiler would
flag an error that I actually don't make. I won't see the warning anyway.
Frode Vatvedt Fjeld
>> compiler that functions won't be redefined at runtime
"sajiimori" <myuse...@hotmail.com> writes:
> 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.
For some reason I just got this really strong association to Plato's
allegory of the cave.. I mean, it seems to me you might learn
something by making a conscious effort to turn your head away from the
world you know, and try to accept the new world on its own terms.
--
Frode Vatvedt Fjeld
Pascal Costanza
André Thieme wrote:
So these IDEs effectively turn Java into a dynamically typed language.
Only with the restriction that I can't take advantage of dynamic typing
in a deployed program.
The key thing to understand is not that "we" want dynamic typing as
such, but we want the kind of flexibility that languages like Common
Lisp and, say, Smalltalk provide. The flexibility to change the rules
for a program very late in the game. Actually as late as run time.
Brian Mastenbrook
sajiimori <myuse...@hotmail.com> wrote:
> 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?
No, what I pasted was an example of (test) causing an error when
executed, and then the exact same definition of (test) /not/ causing an
error when run. Thus the definition of "test" is perfectly correct.
You could equally redefine "test" to show that your add-x-to-y is
correct.
Perhaps I should ask you a simpler question: which definition in what
you wrote would you like to trigger the warning? Both of them are
correct.
> Agreed. In other languages, code like that might very well be meaningless.
CL isn't "other languages". You retain the ability to change the
definitions of functions at runtime.
> (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.)
I just pointed out that there is no type error in what you pasted at
all, until (test) is invoked without redefining either it or
add-x-to-y.
> Well, you can get CMUCL to at least warn about it (using what Eric Marsden
> informed me is called block-compilation), right?
Yes, you might be able to get it to warn you about it, but I would
suggest you not rely on such a feature - it's there for when you really
do make a mistake and the warning helps you identify it quicker. It is
not there to point out errors in code which might be error-free.
> 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.
The only thing that is "restricting" here is static typing. If you are
not in that mindset then the code you included has no errors in it.
--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/
sajiimori
> allegory of the cave.. I mean, it seems to me you might learn
> something by making a conscious effort to turn your head away from the
> world you know, and try to accept the new world on its own terms.
Sure, that's life. But forcing myself to use a tool that I don't currently
have a use for, and denying myself a tool that I *do* have a use for...
well, I don't see the point of that.
Do you really think I should conciously try to design my programs so that
they redefine global functions at runtime, or do you simply think that I
should keep the possibility in mind?
Brian Mastenbrook
sajiimori <myuse...@hotmail.com> wrote:
> Do you really think I should conciously try to design my programs so that
> they redefine global functions at runtime, or do you simply think that I
> should keep the possibility in mind?
I don't think anybody here would suggest that. But remember that the CL
model of "program" is quite a bit larger than most languages, and I get
into arguments even with Schemers who insist that a debugger (for
instance) is not a "normal" program.
When working on Lisp, people very rarely will start up a lisp image,
run the program, and then quit it. Most development is done by
interactive redefinition of functions, with incremental testing. This
is the lisp silver bullet - in no other language do you have the tools
to "grow" a program so quickly as you do in lisp.
As such there is one program which does do a lot of redifinitions of
global functions: YOU, the user. Treating code entered at the REPL for
purposes of testing differently than code which has been compiled would
be a fundamentally anti-Lisp decision - people expect to be able to
redefine code from a compiled file.
sajiimori
> >
> > 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.)
>
> This was a rhetoric answer. If this is not a typical error, why is it
> relevant whether CMUCL warns about it or not?
>
> Or to answer it more directly: I don't care whether a compiler would
> flag an error that I actually don't make. I won't see the warning anyway.
Maybe I misunderstood your question. I thought you were asking if typical
programmers would write code that has a type error as simple as the one
given, but now it seems like you were asking whether typical programmers
*ever* make type errors. To the former, I answered 'no', but I'm inclined
to answer 'yes' to the latter -- I don't know if I'm a typical programmer,
but I've made type errors before (or more specifically, errors that would be
caught by static typing systems -- and I don't just mean having to placate
the compiler, I mean real mistakes).
But if you meant type errors in general: Are you really saying you never
make type errors? Do you think that's typical?
sajiimori
> global functions: YOU, the user.
Ah, good point.
> Treating code entered at the REPL for
> purposes of testing differently than code which has been compiled would
> be a fundamentally anti-Lisp decision - people expect to be able to
> redefine code from a compiled file.
After I get used to this style of development (I still don't like EMACS
(maybe someday), and IDE's... well I'm poor right now ;-) ), I suspect that
I'd only want global type checking on final builds of products that aren't
meant to be reprogrammable (so that would exclude lots of cool Lisp apps).
Static typing starts sounding less and less interesting then.
sajiimori
type errors, but nobody should use the feature. Thanks for the advice.
Brian Mastenbrook
sajiimori <myuse...@hotmail.com> wrote:
> After I get used to this style of development (I still don't like EMACS
> (maybe someday), and IDE's... well I'm poor right now ;-) ), I suspect that
> I'd only want global type checking on final builds of products that aren't
> meant to be reprogrammable (so that would exclude lots of cool Lisp apps).
Can I suggest you try emacs with SLIME ( http://www.cliki.net/SLIME )?
I didn't like emacs when I first started using it for lisp (before
SLIME no less) but for editing lisp code it really is quite workable.
My remaining fights with emacs are due to buffer management and elisp
now, not the general model of the program.
Note that a lot of "serious" Lisp apps use CLOS, where static typing
makes absolutely no sense. In addition you may want to retain the
ability to perform live upgrades on the code. But yes, with block
compilation, you can get type warnings. I just don't really ever think
about typing as a compile-time property anymore.
> Static typing starts sounding less and less interesting then.
Welcome :-)
Gareth McCaughan
> 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?
I can't answer that question without more information about this
hypothetical programming language. To me, being dynamically typed
is an important part of what makes Lisp Lisp, and so talking about
a "statically typed Lisp" is a little like talking about a "C++
with really clean syntax" or "Java without classes".
But let's have a go. First pass at a definition: start with
Common Lisp, allow DEFMETHOD-style argument lists for DEFUN,
do Hindley-Miller-ish type inference on functions whose argument
lists aren't fully typed.
Then I can't use the sequence functions of Common Lisp that
accept both lists and vectors. I can't use the nice flexible
arithmetic functions. That's going to hurt. But it seems
plausible that we can extend the type system a little to
allow this sort of thing. I believe that several modern
functional languages let you define "type classes" (is
that the right term?) and do restricted polymorphism.
Next: I can't write macros any more. To define a macro,
you define a function that operates on source code.
And embedded in that source code there may be all kinds
of objects. Numbers of various kinds, symbols, cons cells
(for code or data), arrays, strings, blah, blah, blah.
This is not a situation that static type systems tend
to handle well.
I can see three possible ways around this. First: ditch
macros. In that case, we're not doing Lisp any more. No
sale. Second: have a completely different sort of macro
system, where the macro expander knows much more about
the structure of the code it's working on. Perhaps it
would look a little like the "hygienic", "high-level"
macro system in Scheme, or like templates in C++. You
could still call that Lisp, but I wouldn't much like
programming in it. Thirdly ... well, *perhaps* there's
a third approach. Suppose we define a discriminated union
type that can contain anything that can appear literally
in source code, and then build our representation of code
out of that. (It would probably be necessary to forbid
user-defined types appearing here, but maybe that's not
so terrible.) I have a suspicion that this doesn't work
in practice for some reason, but let's give it the benefit
of the doubt and suppose we can carry on defining macros
this way.
Next: I can't have arbitrary-length inhomogeneous lists
any more. (The foregoing problem, about macros, was a
special case of this one, and I waved my hands and suggested
that there might be a way around it. But that involved
fixing the set of types for all time; that's not going
to work well in general.) Right now, it seems like that
would hurt, but maybe it's a restriction you learn to
get along with or even like. I'll assume for the sake of
argument that that's so.
Next: I can't do exploratory programming so well any more.
I can't take my running web server program and decide that
I need such-and-such a function to accept strings as well
as symbols, type in a new definition of that function,
and have everything just go on working. (I'm not sure I can
even redefine functions at all and have their callers use
the new definitions, even if the signatures haven't changed;
but it doesn't seem that there's any *fundamental* reason
why that should be impossible, so let's suppose it's possible.)
Well, maybe this whole thing is possible: any time anything
is changed, "just" redo type inference on every function
in the system. Let's hope that doesn't involve too much
pain when the signatures change and everything in sight
gets recompiled.
Next: I have trouble imagining how CLOS is going to carry
on working. I don't have a coherent argument for why it
wouldn't, and I'm not going to try to build one right now,
but it doesn't seem plausible.
It seems like every bit of CL that I look at is in danger
of stopping working in static-type land. So: What would
I miss in a "statically typed Lisp"? I'm afraid that what
I'd miss would be *Lisp*. I can't prove that that's so;
maybe all the things I'm concerned about will turn out
to have easy solutions, or not to be problems at all. But
right now, I can't see how that would be. Does someone have
a design for a statically typed Lisp that wouldn't feel
really un-Lispy to work with? For instance, do you? I don't
think it's really possible to answer your question without
having such a design; and I think that producing such a
design will probably tell you the answer to your question.
*
Some other people posted things that (1) seemed to me
to be insightful but (2) were accompanied by stuff that
upset you (i.e., "sajimori") and may have discouraged
you from reading them, and in some cases (3) were expresed
quite tersely. I'd like to bring one up again here.
Erik Naggum observed that you can *already* consider CL
to be strongly, statically, implicitly typed, with everything
having type T. He has an important point here. Unless you're
going to throw away all the extremely useful technology of
object orientation, you *have* to have some dynamism in your
type system. And unless your static type system supports
types like "integer between 23 and 69815", you *have* to
have the possibility that, at run-time, you'll unhappily
discover that something has a type (i.e., belongs to a set
of objects) that you didn't plan for. The only difference
is that the language typically doesn't offer you any way
of expressing that failure, so you don't *call* it a
type error. It still is one.
Now, for sure, there's a difference between the situation
in Common Lisp (where, e.g., the same variable can hold
an integer and a string and a hash table and a function
at different times) and the situation in Haskell (where
there's a partition of values into a large number of
"types" and each variable is only allowed to take values
in a restricted range of the parts): but it's a difference
of degree, not of kind. -- So if you want to ask questions
about a "statically typed Lisp" then you ought to be more
specific about just how fine-grained you want that partition
to be, and why.
--
Gareth McCaughan
.sig under construc
Pascal Costanza
sajiimori wrote:
>>>>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.)
>>
>>This was a rhetoric answer. If this is not a typical error, why is it
>>relevant whether CMUCL warns about it or not?
>>
>>Or to answer it more directly: I don't care whether a compiler would
>>flag an error that I actually don't make. I won't see the warning anyway.
>
> Maybe I misunderstood your question. I thought you were asking if typical
> programmers would write code that has a type error as simple as the one
> given, but now it seems like you were asking whether typical programmers
> *ever* make type errors.
No, I haven't said that. I was still talking about that specific
example. (+ 12 "banana"), or something like that.
> To the former, I answered 'no', but I'm inclined
> to answer 'yes' to the latter -- I don't know if I'm a typical programmer,
> but I've made type errors before (or more specifically, errors that would be
> caught by static typing systems -- and I don't just mean having to placate
> the compiler, I mean real mistakes).
For example?
> But if you meant type errors in general: Are you really saying you never
> make type errors? Do you think that's typical?
Several points here:
- The interesting aspect of a program is how it behaves at run time. Not
what an arbitrary analysis tool says about it.
- A Common Lisp environment starts up as the program you want to write.
You only need to shape it according to your needs. Seen from idealistic
point of view, there is no static program, there is only a running
system. So with Common Lisp (and some other languages), you are
immediately in an environment that is in the most important state, that
of a running program.
- The "right" way to check a running program is to interact with it and
check whether it produces the right results. This can be automated. So
what you do is you write test cases and bundle them into test suites.
There you express exactly the behaviors that you are interested in,
nothing more, nothing less.
- Now, it seems to be that such test suites, when sufficiently complete,
also discover all the interesting type errors as a side effect. I say
"seems" because that's what I have experienced and that's what I have
heard and read from several users of dynamic languages. This is not
empirical evidence in a strict sense. Still, I can relate to it and find
it more convincing than what static typers say. In a test suite you test
the behavior of a program, and that's what you ultimately want from the
program - to behave in certain ways.
- No matter whether you statically type-check your program or not, you
must ultimately test it. Some static typers argue that a sufficiently
sophisticated type system guarantees correct behavior of the resulting
program, but I haven't seen a convincing proof of this claim yet.
- The problem with enforced static type systems is that they need to be
systematic. They can either systematically reject a certain syntactic
shape of programs or accept it. If you need exceptions from the static
typing rules, you have to explicitly express them. This is tedious.
Exceptions are more naturally to express in a dynamic language IHMO,
because you don't basically say "here no type check", but you say "here
behave like this". This is closer to the intention of a programmer IMHO.
- Because of the fact that static type systems must be systematic in
their approach, they also necessarily need to reject programs that would
still behave well without a static type checker. Serious static typers
admit this.
So, to summarize: Static type systems reject programs that are correct;
they impose additional work on the programmer; and the test suites that
you need to write anyway will also take care of type errors.
So it doesn't seem to me that there is a real gain here.
The weak spots in this arguments are as follows:
1) Do programmers really make the type errors that static type systems
catch?
2) Beyond that, do sophisticated static type systems somehow ensure
program correctness? If so, how?
3) Do test suites also automagically take care of type errors without
the need to write test cases specifically for these type errors? If so, why?
IMHO, 1 is the most important question here, and it can be only answered
by a serious empirical study. 2 and 3 are also important, but I don't
know how to answer them. Maybe there are some "deep" causalities why
either or both of them can be positively answered, or they can also only
be answered empirically. My bet is that 2 and 3 are in fact social
and/or cognitive issues: some people have a better understanding of a
system from a static perspective while others prefer the dynamic one,
just like some people think textually while others think visually. It
might be that there isn't a clear winner here.
I don't think anyone can ultimately answer these questions at the
moment, because we simply don't have enough information. It's
essentially an open research issue.
André Thieme
>>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.
You might not appreciate the language (for example) Java itself to be
able to be productive with it. Thanks to the lib and ide you can be
pretty productive with Java. Integrating SAP with original libs of SAP
self is not very hard.
I just try to imagine that Sun and IBM pumped so much money and work
into Lisp..
Thomas F. Burdick
> So in short, your answer is: yes, CMUCL can generate warnings about possible
> type errors, but nobody should use the feature. Thanks for the advice.
No, fool, he said that you should not *rely* on it. It only tells you
when it knows something will be wrong with a given code path; if it
can't tell either way, it's quiet on the matter.
Rahul Jain
> 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.
Most of us call this process "inlining" followed by "optimization" which
includes "unreachable code elision". :)
--
Rahul Jain
rj...@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain
> But if you meant type errors in general: Are you really saying you never
> make type errors? Do you think that's typical?
Type errors are not fatal in Lisp. They are merely a situation that
needs to be handled as approriate for the current sitiuation in the
program. What if the type error was because the user typed in invalid
data? Does the existence of a keyboard mean your program should refuse
to compile?
sajiimori
I guess you're signing up for my 'ignore' list. Thanks for playing.
sajiimori
> to compile?
Well, a conforming CL compiler shouldn't refuse, that's for sure! But when
I said "error", I didn't mean something that causes the compiler to fail. I
meant it in the everyday sense of "making a mistake", as in "human error".
sajiimori
> example. (+ 12 "banana"), or something like that.
Oh, good.
> > To the former, I answered 'no', but I'm inclined
> > to answer 'yes' to the latter -- I don't know if I'm a typical
programmer,
> > but I've made type errors before (or more specifically, errors that
would be
> > caught by static typing systems -- and I don't just mean having to
placate
> > the compiler, I mean real mistakes).
>
> For example?
Hrmm...let's see. How about passing arguments in the wrong order? If the
arguments are supposed to be of different types, it could cause a type error
if they were mixed up.
More often, I forget to fully process a piece of data before I send it on
down the conveyor belt. A mistake like that can sometimes be caught if the
object changes type during processing (or rather, a new object is created
based on the original), and the destination requires a particular type.
> > But if you meant type errors in general: Are you really saying you
never
> > make type errors? Do you think that's typical?
>
> Several points here:
Ok, but what about the question?
> - The interesting aspect of a program is how it behaves at run time. Not
> what an arbitrary analysis tool says about it.
Right. The tool should be in service of generating the behavior you want.
> - A Common Lisp environment starts up as the program you want to write.
> You only need to shape it according to your needs. Seen from idealistic
> point of view, there is no static program, there is only a running
> system. So with Common Lisp (and some other languages), you are
> immediately in an environment that is in the most important state, that
> of a running program.
Ok.
> - The "right" way to check a running program is to interact with it and
> check whether it produces the right results. This can be automated. So
> what you do is you write test cases and bundle them into test suites.
> There you express exactly the behaviors that you are interested in,
> nothing more, nothing less.
Ok. Also, if you find some redundancy in the tests of different components
of a program, you might encapsulate that functionality. You might
occasionally discover a loose rule that can determine when a program is
probably wrong, even if it can't determine when it's definitely right.
Encapsulating the rule could make other tests easier to write, and more
likely to be complete.
Looking at static typing this way, it doesn't seem so bad.
> Some static typers argue that a sufficiently
> sophisticated type system guarantees correct behavior of the resulting
> program, but I haven't seen a convincing proof of this claim yet.
Depends on what "correct" means. In real life, it means "what the
programmer intended", which is obviously impossible for the compiler to
determine with 100% accuracy. Just imagine a compiler that fixes your logic
bugs...
> I don't think anyone can ultimately answer these questions at the
> moment, because we simply don't have enough information. It's
> essentially an open research issue.
Then I guess I'm researching one person at a time. ;-)
Kenny Tilton
<sob> I will always cherish your "I am troller, hear me roar"
breast-beating about not submitting to authority in reference to
lengthy, well-reasoned, detailed, specific, technical Web articles I am
guessing you did not even read.
Nice spin! :)
sajiimori
> accept both lists and vectors. I can't use the nice flexible
> arithmetic functions.
You could if the functions had multiple versions, and the compiler inserted
calls to the appropriate ones (since it has all the static type information
it needs to make that determination).
> Next: I can't write macros any more. To define a macro,
> you define a function that operates on source code.
> And embedded in that source code there may be all kinds
> of objects. Numbers of various kinds, symbols, cons cells
> (for code or data), arrays, strings, blah, blah, blah.
> This is not a situation that static type systems tend
> to handle well.
That is very important. I wonder why nobody else had mentioned it (that I
saw anyway)?
> Suppose we define a discriminated union
> type that can contain anything that can appear literally
> in source code, and then build our representation of code
> out of that.
This is what I was thinking.
> (It would probably be necessary to forbid
> user-defined types appearing here, but maybe that's not
> so terrible.)
Don't user-defined types have to be based on built-in types anyway?
> Next: I can't have arbitrary-length inhomogeneous lists
> any more.
I don't see the problem with allowing arbitrary length, but having to use
homogeneous lists... yeah, that could be inconvenient. Trying to re-add
them would just make the language more complicated (like Java).
> Next: I can't do exploratory programming so well any more.
> I can't take my running web server program and decide that
> I need such-and-such a function to accept strings as well
> as symbols, type in a new definition of that function,
> and have everything just go on working.
Right.
> Next: I have trouble imagining how CLOS is going to carry
> on working.
It won't. Next! ;-)
> Does someone have
> a design for a statically typed Lisp that wouldn't feel
> really un-Lispy to work with? For instance, do you?
Nope, just been toying with the idea.
> Erik Naggum observed that you can *already* consider CL
> to be strongly, statically, implicitly typed, with everything
> having type T.
Still sounds like a joke. Implementing such a type system requires exactly
0 lines of code. Its requirements are necessarily met. It's like a type
system that requires that objects are not of negative size.
> So if you want to ask questions
> about a "statically typed Lisp" then you ought to be more
> specific about just how fine-grained you want that partition
> to be, and why.
Akin to Haskell. And...umm...because I feel like it? =)
Tayssir John Gabbour
> 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.
I am going to study programming languages more carefully and see if I
can articulate my intuition better.
It's just that I don't want all the output of a static analysis to be
consumed by some compiled version. I would like to query the output
for certain guarantees that will be given if I'm willing to add more
information. And that information can be given in a separate file, so
the text of my code isn't encumbered by a lot of information that gets
in the way as requirements change.
As I understand static languages, they ask I write in a constrained
style in order to get certain guarantees. But I want this to be an
incremental process. With a lisp system, I ask, "Can you execute this
data for me?" Maybe I'm just a slavedriver, but I don't want it to
respond, "No, asshole."
Rahul Jain
> So, to summarize: Static type systems reject programs that are correct;
> they impose additional work on the programmer; and the test suites that
> you need to write anyway will also take care of type errors.
They also make the programmer optimize prematurely.
Rahul Jain
> Hrmm...let's see. How about passing arguments in the wrong order? If the
> arguments are supposed to be of different types,
And if it doesn't?
> More often, I forget to fully process a piece of data before I send it on
> down the conveyor belt. A mistake like that can sometimes be caught if the
> object changes type during processing (or rather, a new object is created
> based on the original), and the destination requires a particular type.
And if it doesn't?
I've found that this just lulls me into a false sense of security. Also,
the cases you've given are red herrings. In the first case, the error is
the fact that the function doesn't have keyworded args. In the second,
it's that the function doesn't implicitly do the massaging itself, if
that massaging is obvious. See also: the concept of string specifiers in
lisp.
Rahul Jain
>> No, fool
>
> I guess you're signing up for my 'ignore' list. Thanks for playing.
So you'll dish it out, but you can't take it. Are you TRYING to destroy
any reason anyone might have to respect anything you do or say?
Rahul Jain
And typing "-1" when the computer prompted for a positive number is a
human error. Should the program therefore fail to compile because it
could get erroneous input from an external source? Or should we be
forced to code for every possible case in which the user screwed up
instead of just having a decent condition system so that the user is
allowed to try to fix their mistake (either by replacing the result of
an intermediate computation or trying again from the point where they
entered the incorrect data or by just giving up and moving on because
the user realized he didn't really want to be in this operation)?
Thomas F. Burdick
> Jens Axel Søgaard <use...@jasoegaard.dk> writes:
>
> > 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.
>
> Most of us call this process "inlining" followed by "optimization" which
> includes "unreachable code elision". :)
I see the smiley, but in case anyone following this isn't clear on
what he's referring to, it is different. If you have a function like:
(defun foo (&optional base)
(labels ((make-adder (&key base)
(lambda (x) (+ base x))))
(if base
(make-adder :base base)
#'make-adder)))
Your compiler might do something like this:
make-adder-arg-parser:
;; parse args for call to main body
...
jmp make-adder-noparse
make-adder-noparse:
;; This is a function of one fixed argument, BASE.
;; If BASE wasn't supplied, we should get a magic not-supplied
;; constant instead.
...
The call to MAKE-ADDER will call make-adder-noparse directly. The
function returned by the form #'make-adder, however, has to return a
function callable from any context, so it'll use make-adder-arg-parser.
Rahul Jain
>> Then I can't use the sequence functions of Common Lisp that
>> accept both lists and vectors. I can't use the nice flexible
>> arithmetic functions.
>
> You could if the functions had multiple versions, and the compiler inserted
> calls to the appropriate ones (since it has all the static type information
> it needs to make that determination).
Oh... does it? What if the object being operated on is chosen by the
user with a mouse? Should we forbid them from using a vector because the
code wanted a static declaration and the programmer chose to declare it
to be a list?
>> (It would probably be necessary to forbid
>> user-defined types appearing here, but maybe that's not
>> so terrible.)
>
> Don't user-defined types have to be based on built-in types anyway?
They have to be subclasses of built-in types that are there specifically
for being subclassed by user-defined types. They still break the concept
of knowing the exact type of all possible bindings of a variable at
compile time and then comparing them to the types that cause something
else to break. Of course, type errors can't cause lisp programs to
break, but that's something you refuse to accept, or so it seems.
>> Erik Naggum observed that you can *already* consider CL
>> to be strongly, statically, implicitly typed, with everything
>> having type T.
>
> Still sounds like a joke. Implementing such a type system requires exactly
> 0 lines of code. Its requirements are necessarily met. It's like a type
> system that requires that objects are not of negative size.
That's because lisp doesn't draw a distinction between static and
dynamic typing. You already have both. You can declare the types of
bindings to be as narrow as you'd like and you can declare the safety of
the compiled code to be what you like.
>> So if you want to ask questions
>> about a "statically typed Lisp" then you ought to be more
>> specific about just how fine-grained you want that partition
>> to be, and why.
>
> Akin to Haskell. And...umm...because I feel like it? =)
So you don't want anyone else to give you any serious, thoughtful
help because your goals are a secret. Got it.
Rahul Jain
Why can't you already do that with lisp? Note that raising a type error
in some specific situation is the _result_ of execution, not a defintion
of an unexecutable program. In fact, a type error may be exactly what
you want the program to do in that situation, as the remote end sent
over data of an incorrect type. Only the "functional programmers" write
programs which have no effect on the world around them (and are
therefore not allowed to have the world around them affect their
programs' behaviors).
Rahul Jain
> I see the smiley, but in case anyone following this isn't clear on
> what he's referring to, it is different.
The smiley was intended to show that this is a rather simple,
conventional solution to the problem.
It's different in implementation, but I don't see how it's different in
result (other than being inferior :). Both cases make redefinition
practically impossible, except that maybe the strategy that associates
the optimizations with the function itself could preserve all the
pre-exising type-specializations as the function is redefined.
Therefore, if you used to have an implementation where integers could
have an optimized call, but redefined it so that integers were treated
identically to ratios, you'd have to retain two entries for the rational
version of the function, one for integers and one for ratios.
Thomas F. Burdick
> t...@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > I see the smiley, but in case anyone following this isn't clear on
> > what he's referring to, it is different.
>
> The smiley was intended to show that this is a rather simple,
> conventional solution to the problem.
>
> It's different in implementation, but I don't see how it's different in
> result (other than being inferior :). Both cases make redefinition
> practically impossible, except that maybe the strategy that associates
> the optimizations with the function itself could preserve all the
> pre-exising type-specializations as the function is redefined.
No, that's exactly the difference. In the case of multiple
entrypoints, you can turn the old specialized entrypoint into a
trampoline.
Kenny Tilton
>
> > No, fool
>
> I guess you're signing up for my 'ignore' list. Thanks for playing.
Last one to be 'ignored' by sajii is a rotten egg.
:)
Thomas F. Burdick
He's right, tho, I did sign up for it. I wrote my message without the
Mr. T-ism, then wondered if I should bother. Inserting a one-syllable
quote from a retired actor answered that question...
Oh, and *tag*, Rahul's "it"
Frode Vatvedt Fjeld
> Sure, that's life. But forcing myself to use a tool that I don't
> currently have a use for, and denying myself a tool that I *do* have
> a use for... well, I don't see the point of that.
The idea is that perhaps you don't know lisp and typical modes of
development in lisp yet, so you also don't know very well what you
have use for.
> Do you really think I should conciously try to design my programs so
> that they redefine global functions at runtime, or do you simply
> think that I should keep the possibility in mind?
The perspective you should try to internalize is that of programs,
applications, and development as dynamic things that evolve with time,
rather than being static blobs that don't. It's somewhat like the
difference between photographs and film: Both do the "same" in some
sense, i.e. they capture reflections of the real world, but the latter
has an extra dimension that changes it profoundly.
--
Frode Vatvedt Fjeld
Pascal Costanza
sajiimori wrote:
> Hrmm...let's see. How about passing arguments in the wrong order? If the
> arguments are supposed to be of different types, it could cause a type error
> if they were mixed up.
That's better handled by keyword arguments.
>>>But if you meant type errors in general: Are you really saying you never
>>>make type errors? Do you think that's typical?
>>
>>Several points here:
>
> Ok, but what about the question?
What I am trying to say - obviously not very successfully - is that I
think that your question is the wrong question to ask.
>>- The "right" way to check a running program is to interact with it and
>>check whether it produces the right results. This can be automated. So
>>what you do is you write test cases and bundle them into test suites.
>>There you express exactly the behaviors that you are interested in,
>>nothing more, nothing less.
>
> Ok. Also, if you find some redundancy in the tests of different components
> of a program, you might encapsulate that functionality. You might
> occasionally discover a loose rule that can determine when a program is
> probably wrong, even if it can't determine when it's definitely right.
> Encapsulating the rule could make other tests easier to write, and more
> likely to be complete.
>
> Looking at static typing this way, it doesn't seem so bad.
Have you checked this? Or are you only guessing?
>>I don't think anyone can ultimately answer these questions at the
>>moment, because we simply don't have enough information. It's
>>essentially an open research issue.
>
> Then I guess I'm researching one person at a time. ;-)
Yes, that would be a good idea. And a good idea would be to just give a
dynamically typed language a serious try, and not to try to use it like
a statically typed one. Only then will you be able to really compare the
two approaches. Until then you can only guess.
Pascal Costanza
sajiimori wrote:
>>Erik Naggum observed that you can *already* consider CL
>>to be strongly, statically, implicitly typed, with everything
>>having type T.
>
> Still sounds like a joke. Implementing such a type system requires exactly
> 0 lines of code. Its requirements are necessarily met. It's like a type
> system that requires that objects are not of negative size.
...which means that the term "statically typed" doesn't mean anything
specific by itself. There are many variations out there what it means to
be statically typed. Hindley/Milner type systems come in numerous
flavors, and there doesn't seem to be an agreement what the right way is
for some of the more subtle issues.
So strictly speaking, you are not saying very much when you talk about
statically typed languages. You are only relying on a vague commonly
accepted set of typical representative languages.
Björn Lindberg
> Kenny Tilton <kti...@nyc.rr.com> writes:
>
> > sajiimori wrote:
> > >
> > > > No, fool
> > >
> > > I guess you're signing up for my 'ignore' list. Thanks for playing.
> >
> > Last one to be 'ignored' by sajii is a rotten egg.
> >
> > :)
>
> He's right, tho, I did sign up for it. I wrote my message without the
> Mr. T-ism, then wondered if I should bother. Inserting a one-syllable
> quote from a retired actor answered that question...
In all fairness, recall that this is an international forum. Probably
most readers did not get the actor reference in your reply. For
instance, when Kenny from time to time talks about various local
sports teams I am completely lost.
Björn
Espen Vestre
> Why is it that programmers always seem to think that the rest of the
> world is stupid?
Well, those of us who do a little customer support, knows that a large
share of computer users have an amazingly minimal knowledge of how
their computer works. This is *not* because they're stupid, but
because of their attitude and interest: They only use the computer to
perform a few specific tasks, and have no intention to explore its
possibilities beyond that. To get the idea: It's not uncommon that
Windows users have no idea what you're talking about if you ask them a
question about the 'Start menu'.
--
(espen)
Joe Marshall
>
> Why is it that programmers always seem to think that the rest of the
> world is stupid?
First-order engineering approximation.
Joe Marshall
> It's just that I don't want all the output of a static analysis to be
> consumed by some compiled version. I would like to query the output
> for certain guarantees that will be given if I'm willing to add more
> information.
I'll grudgingly add extra information to the code if I get a
substantial amount back in terms of either functionality or
performance, but any time you add extra information, there is the
possibility that you add incorrect extra information. The less I tell
the computer, the fewer typos and brain farts I have to fix. Ideally,
I'd tell the computer nothing, and it would do my will. Since that
won't happen anytime soon, I'd prefer to minimize what I have to tell
it.
> And that information can be given in a separate file, so
> the text of my code isn't encumbered by a lot of information that gets
> in the way as requirements change.
Ouch! You don't want the extra information too far away from the code
or it will get out of sync almost immediately.