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?
* sajiimori
| If there were a statically, implicitly typed Lisp, would you use it?
Common Lisp is already statically, implicitly typed. All objects are
of type T, and this is very rigourously enforced.
| What qualities of dynamic typing would you miss?
You may have noticed that every language worth using these days has
(added) an object system that carries type information in the objects.
You appear to want to take a step backwards in this respect. Why?
--
Erik Naggum | Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
> Common Lisp is already statically, implicitly typed. All objects are
> of type T, and this is very rigourously enforced.
I don't know if you're being serious, but the rule that all objects are of
type T means that if X is an object, the statement "X is of type T" carries
no information. I don't know how you could consider something a static type
system when it doesn't offer any static distinction between objects.
> You may have noticed that every language worth using these days has
> (added) an object system that carries type information in the objects.
Static and/or implicit typing doesn't forbid objects from carrying type
information, so I don't see your point.
> You appear to want to take a step backwards in this respect. Why?
You folks sure are touchy -- I didn't even say that I want static or
implicit typing. I thought it would take at least a few posts before the
rudeness began.
"sajiimori" <··········@hotmail.com> wrote in message news:<···················@newsread2.news.pas.earthlink.net>...
> You folks sure are touchy -- I didn't even say that I want static or
> implicit typing. I thought it would take at least a few posts before the
> rudeness began.
You're wrong here. Erik was very polite. Did you notice most people
presume software people are rude by being very exacting with peers,
almost to the point of triviality?
And it's not just "software people"; you'll find it among people who
care about what they do. Or social retards, but I'm talking generally
and there are exceptions.
> You're wrong here. Erik was very polite. Did you notice most people
> presume software people are rude by being very exacting with peers,
> almost to the point of triviality?
>
> And it's not just "software people"; you'll find it among people who
> care about what they do. Or social retards, but I'm talking generally
> and there are exceptions.
Maybe...I consider myself a "software people" (and an occasional social
retard), but I also consider my tendancy for excessive precision to be a
character flaw, and I make an effort to restrain myself in order to maintain
civil relationships.
That aside, I don't think any level of precision would lead a reasonable,
cooperative person to the conclusion that I "want to take a step backwards",
given the text of my original post. Erik's response was nothing but an
underhanded attack on a position that I never even took up.
I tried to frame my questions in a way that would avoid a flamewar, but some
people are so interested in creating conflict that they'll go out of their
way to misinterpret others and put words in their mouths.
sajiimori wrote:
> I tried to frame my questions in a way that would avoid a flamewar, but some
> people are so interested in creating conflict that they'll go out of their
> way to misinterpret others and put words in their mouths.
If you are so interested avoiding flamewars, why are you adding fuel to
this one? Looks like non-avoiding avoidance to me.
I agree you received a chilly reception with your static worship, but
static vs. dynamic is of course an oft-contested battle, and perhaps as
a newcomer you did not realize how weary of it we denizens of cll might
be. Chilliness aside, you get the prize for kicking off the name-calling
by slurring the whole group because you came in like a bull in a china
shop.
When you go to Boston, do you wear Bucky Dent or Aaron Boone jerseys?
You are like the Boston groundskeeper who got his ass kicked in the
Yankee bullpen for celebrating a Boston success and then wonders why.
kenny
--
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
> static worship
Because you've committed yourself to intentional and hostile
misinterpretation, I'm not going to be replying to your posts anymore.
Sorry.
sajiimori wrote:
>
> > static worship
>
> Because you've committed yourself to intentional and hostile
> misinterpretation, I'm not going to be replying to your posts anymore.
> Sorry.
<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
| 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./
--
Erik Naggum | Oslo, Norway 2004-026
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
sajiimori wrote:
> You folks sure are touchy --
We're having a nasty winter. Wait till spring and try again.
kenny
--
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
* 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
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
sajiimori wrote:
> 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?
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
> Yes, I would use it, as long as any conformant Common Lisp program would
> run in it. Otherwise, I would not be so interested.
Hmm...I guess it would have to support dynamic typing as a fallback then.
sajiimori 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.
>
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
> Call it as you want, consider it a real challenge. Add some form of
> static typing to Common Lisp in such a way to maintain backward
> compatibility in the sense that every conformant CL program (with
> "conformant" being defined in the ANSI spec).
Would that even require extending CL? If all you're doing is statically
typing what you can, and leaving the rest dynamic (which you'd have to do to
allow all CL features), that's just an implementation issue (and I hear
CMUCL does implement something like that).
sajiimori wrote:
>>Call it as you want, consider it a real challenge. Add some form of
>>static typing to Common Lisp in such a way to maintain backward
>>compatibility in the sense that every conformant CL program (with
>>"conformant" being defined in the ANSI spec).
>
>
> Would that even require extending CL? If all you're doing is statically
> typing what you can, and leaving the rest dynamic (which you'd have to do to
> allow all CL features), that's just an implementation issue (and I hear
> CMUCL does implement something like that).
AFAIU it does require extending Common Lisp. Maybe it does not require
extending the "syntactic" features of Common Lisp, or maybe it requires
extenting the syntax in a predictable way. I do not know.
In a certain sense it is true that it is "an implementation issue". But
don't think that that is belittling the issues. Suppose I do
(defun foo (x y)
(+ x y))
I compile it and now I have that the environment "knows" that the type
of FOO is
(function (number number) number)
(Do not even think of making floats and integers use different operators!)
Now I define
(defun bar (x)
(* 3 (foo x 42)))
It is conceivable to infer that the type of BAR is
(function (number) number)
Now suppose I redefine
(defun foo (x y)
(declare (type double-float x y))
(+ x y))
I may want the system to automagically update the type of BAR to
(function (double-float) double-float)
However, if somewhere else in the program I already have a call
(... (bar 42) ...)
I may want the type of BAR to be retained as
(function (number) double-float)
You can issue all the warning you want and you can add all the
declarations you want. You just cannot break a conformant program.
You see what are the difficulties you have to face just by accepting
these "specs" (quotes mandatory).
Now you face a choice. You can pick up the challenge, or you can flee
and devise you own statically typed language where everything is under
control from scratch but which is not as flexible as Common Lisp. I
cannot guaratee you that I will be interested.
Cheers
--
Marco
Marco Antoniotti <·······@cs.nyu.edu> writes:
> It is conceivable to infer that the type of BAR is
>
> (function (number) number)
>
> Now suppose I redefine
>
> (defun foo (x y)
> (declare (type double-float x y))
> (+ x y))
At this point, I'd want it to warn me that my declarations here
conflict with the call in BAR.
> I may want the system to automagically update the type of BAR to
>
> (function (double-float) double-float)
I would want it to update BAR's type, but to indicate that it won't
return (because it has only one code path, and that calls FOO with an
argument of the wrong type).
I think I'd want BAR to be
(function (number))
> Now you face a choice. You can pick up the challenge, or you can flee
> and devise you own statically typed language where everything is under
> control from scratch but which is not as flexible as Common Lisp. I
> cannot guaratee you that I will be interested.
Personally, I can guarantee you that I will not be interested.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> [static typing and redefinition]
>
> I think I'd want BAR to be
>
> (function (number))
(function (number)) means the same as (function (number) *). You
probably meant (function (number) nil) here; the NIL return type is
the CL way of saying "does not return normally". Though you'd then
better hope that your debugger doesn't have the ability to return from
an arbitrary frame :-)
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes <·····@cam.ac.uk> writes:
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > [static typing and redefinition]
> >
> > I think I'd want BAR to be
> >
> > (function (number))
>
> (function (number)) means the same as (function (number) *). You
> probably meant (function (number) nil) here; the NIL return type is
> the CL way of saying "does not return normally".
Shoot, I knew I'd screwed that up.
> Though you'd then better hope that your debugger doesn't have the
> ability to return from an arbitrary frame :-)
Well, in this hypothetical superlisp, I'd assume all source is kept
around in a database, so the act of returning from the debugger would
first change BAR's type, which would cause a cascading of type
consequences :-)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
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.
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
Ray Dillinger <····@sonic.net> writes:
> sajiimori wrote:
> >
> > > Yes, I would use it, as long as any conformant Common Lisp program would
> > > run in it. Otherwise, I would not be so interested.
> >
> > Hmm...I guess it would have to support dynamic typing as a fallback then.
>
> What would be cool is a program that attempts to statically prove code
> to be type sound. Some programs it will succeed on, and then you can be
> *sure* that no type error is possible in those programs.
>
> Other programs it will fail on, and in that case it's the programmers'
> responsibility to make sure that type errors do not actually occur.
One important idea to keep in mind when thinking about static
analysis, when you're asking it to prove something that cannot be
proved or disproved in the general case, is: there are three things
that can happen; it can prove the code correct, it can fail to prove
anything, or it can prove the code to be incorrect. A lot of the time
the people seem to think of the last two as the same case, whereas
they're very very different.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Joe Marshall
Subject: Re: Static/Strong/Implicit Typing
Date:
Message-ID: <isiyilns.fsf@ccs.neu.edu>
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> One important idea to keep in mind when thinking about static
> analysis, when you're asking it to prove something that cannot be
> proved or disproved in the general case, is: there are three things
> that can happen; it can prove the code correct, it can fail to prove
> anything, or it can prove the code to be incorrect. A lot of the time
> the people seem to think of the last two as the same case, whereas
> they're very very different.
Unless you perform one of the two following sleights of hand:
Define `correctness' as passing the static analysis. Code that does
not is ipso facto incorrect.
Define `code' as that which passes the static analysis. Things that
do not are not even code.
(These are usually followed by the definition of a type error as only
those errors caught via static analysis, which leads to the conclusion
that runtime type errors cannot happen.)
Joe Marshall <···@ccs.neu.edu> writes:
> ···@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.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
sajiimori wrote:
> 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?
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."
> The mindset of static typers seems to be
> that when the compiler complains about a static type error, you should
> not be allowed at all to run your program. This doesn't make sense,
> especially in scenarios in which a run of an erroneous program could
> actually help you to detect the source of a problem.
Interesting... Do you have an example of how running a program can lead to
the discovery of the source of a static typing error? I would think that
since nothing that happens at runtime can affect static typing, there would
be no useful information to glean about such an error.
> From an engineering
> point of view, it does not make sense to restrict your toolset.
My first impulse is to agree, but the biggest (generally agreed upon)
benefit of static typing is that type errors are caught at compile-time, and
that benefit can only be reaped by restricting yourself from doing anything
that would violate the system. I guess it depends on what freedoms you'd be
willing to forfeit (if any) to have that feature -- which is sort of what my
original question was about.
> What good dynamically typed languages give you beyond better debugging
> facilities is the ability to change a program at run time, which means
> adding, removing or changing features dynamically. Especially the
> removal of features is not handled very well in statically typed
> languages. Dynamic software evolution enables a whole range of new
> deployment models, like running your software on a web server and being
> able to update it without any downtimes.
These ideas are still pretty new to me. What do you mean by "removing
features", and why does the type system affect it so much?
> It's important to note that the kind of type system is not the only
> important factor, and that the default typing "philosophy" of a language
> does not necessarily preclude the switch to the other one.
That's exactly what I'm hoping for, because I'm trying to make a Lispy
language that uses strong, static, implicit typing (just as an experiment --
I don't know if I would even use such a language in place of CL).
> - There are approaches to add static type checking to dynamically typed
> languages as an additional tool, without strictly enforcing what static
> typers call "type soundness". For example, CMU Common Lisp (CMUCL) and
> Strongtalk are good examples in this regard.
If I were still running a Unix, I'd check out CMUCL -- as it is, I've only
seen CLISP and Corman, neither of which catch type errors at compile time.
:( Would CMUCL warn about this during compile-time? If not, do you think
it should?
(defun x-plus-y (x y)
(+ x y))
(defun test ()
(x-plus-y 5 "asdf"))
> Again, whether a language is dynamically or
> statically typed does not determine whether it is a good language.
> Programming languages are holistic entities, in the sense that all the
> distinguishing features have to complement each other well.
Of course! So, as a variant of my original question: In a statically,
implicitly typed Lisp, do you think the features would still complement each
other well?
I think you will want to explicate what precisely you want from a
static lisp. More on this below.
"sajiimori" <··········@hotmail.com> wrote in message news:<····················@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.
From: Joe Marshall
Subject: Re: Static/Strong/Implicit Typing
Date:
Message-ID: <vfmyirvc.fsf@ccs.neu.edu>
···········@yahoo.com (Tayssir John Gabbour) writes:
> /Static analysis does not mean it must run at compiletime./
It does mean that it has to run *before* run time, though.
Joe Marshall <···@ccs.neu.edu> wrote in message news:<············@ccs.neu.edu>...
> ···········@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."
···········@yahoo.com (Tayssir John Gabbour) writes:
> 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."
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
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
From: Joe Marshall
Subject: Re: Static/Strong/Implicit Typing
Date:
Message-ID: <oesph39u.fsf@ccs.neu.edu>
···········@yahoo.com (Tayssir John Gabbour) writes:
> 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.
Joe Marshall <···@ccs.neu.edu> wrote in message news:<············@ccs.neu.edu>...
> Ouch! You don't want the extra information too far away from the code
> or it will get out of sync almost immediately.
If this information is added as part of an optimization step, I think
it'll get out of sync less, because I'll be operating on code that
doesn't need to change often. And my static analyses would complain
loudly anyway forcing me to disable or correct my declarations.
This could be blue sky though... Maybe it requires some hypertext
system. ;)
> 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.
One place I don't mind making some errors is the test cases, because
most likely something will complain and I'll think carefully. There
is probably a class of code where making errors is either negligible
or helpful to engage the head. Static declarations would be nice in
that category.
* Tayssir John Gabbour
| /Static analysis does not mean it must run at compiletime./
Actually, that it run at compile time is the definition of �static� --
it requires no dynamic (= run-time) information.
| However, there is this insane presumption, orthogonal to static
| analysis, that says we must run screaming from errors with our hands
| over our ears. I don't think this is a fault in anyone, just our
| byzantine languages and educations that pressure us into being macho
| and hiding our faults as soon as possible, before anyone else can see
| them.
Well said. :)
--
Erik Naggum | Oslo, Norway 2004-026
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Erik Naggum <····@naggum.no> writes:
> * Tayssir John Gabbour
> | /Static analysis does not mean it must run at compiletime./
>
> Actually, that it run at compile time is the definition of �static� --
> it requires no dynamic (= run-time) information.
You forgot about load time. If you're doing static analysis to assist
the programmer, compile time is the appropriate time, but if you're
doing static analysis for safety reasons (eg, we only load modules
that follow these rules), you need to work at load time. In the most
likely case, you actually did the static analysis at compile time and
generated a proof for the load time checker to use, but conceptually
(and literally if you don't have compiler support) the checking is
done at load time.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
* 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.
--
Erik Naggum | Oslo, Norway 2004-026
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
In article <·······················@naggum.no>, Erik Naggum
<····@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.
Erik Naggum <····@naggum.no> writes:
> * Thomas F. Burdick
> | You forgot about load time.
>
> No. I'm trying very hard to prevent �static� from being redefined
> away from the accepted meaning in the computer science literature.
I don't think what I described is doing that. Essentially, I was
describing Proof-Carrying Code.
> Maybe it helps to admit to the ulterior motive -- I want to show that
> if you accept the standard meaning of �static� to mean /syntactic/
> analysis, with as little (dynamic) semantics as possible, what you can
> determine may well be gratifying to the computer scientist who works
> hard on his thesis, but it is completely irrelevant in the real world,
> and in fact detrimental to every other kind of software quality.
I think you're describing static typing, which is only one part of the
big world of static analysis. Unfortunately, it's where most effort
seems to go -- and it's also fairly useless, IMO.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
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.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
* Pascal Costanza
| Compilation means to translate one representation of a program into
| another one. Static analysis doesn't necessarily involve such a
| translation.
Yes, you can perform the static analysis without producing any output
upon success other than �like, wow, that was a type-correct program�.
--
Erik Naggum | Oslo, Norway 2004-026
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
* sajiimori
| If I were still running a Unix, I'd check out CMUCL -- as it is, I've
| only seen CLISP and Corman, neither of which catch type errors at
| compile time. :( Would CMUCL warn about this during compile-time? If
| not, do you think it should?
|
| (defun x-plus-y (x y)
| (+ x y))
|
| (defun test ()
| (x-plus-y 5 "asdf"))
I keep wondering why the static type crowd always make up this kind of
examples.
In the Common Lisp world, you are supposed to be conscious when you
write your code, and the above fragment suggests that you are not, but
want the compiler to wake you up from your code-writing coma.
One reason to cater to the comatose programmers is that static typing
with a wide variety of types adds a lot more things to think about.
The other solution to this problem is dynamic typing.
If you want to understand what is going on here, you have to begin by
realizing that both static and dynamic typing are answers to another,
logically preceding question. The static type crowd solved a problem
when people passed around machine words with different meanings. �I
know�, said that static type genius, �I'll let the compiler keep track
of all the types and refuse to run the program with values of random
types confusing the machine!�. In another office, far away, sat the
dynamic typing genius and thought �I know, I'll make all values self-
determine their types!�. The latter genius laid the foundation for
the reinvention of object-orientation with run-time type information,
which needed to be added to the static type genius's world view at at
heavy cost.
If you write the above code in Common Lisp, the purpose of running it
will be to investigate the response to type errors. You will observe
that you invoke the debugger. One of the things you could do then is
to realize that the function that was called should be a generic
function, and you can back out of the call, redefine the function
x-plus-y, and resume execution by retrying the call. Another thing
you could do is to realize that you had made a mistake in the caller.
In this case, you would back out of the call to test, instead, and
redefine that function and resume execution by calling the new test
function.
Please think about how this is different from the static typing
systems you appear to know better than Common Lisp.
| So, as a variant of my original question: In a statically, implicitly
| typed Lisp, do you think the features would still complement each
| other well?
As long as you do not understand what you already have, there is no
point in answering your question about what would be.
And /calm down/, please. Say to yourself that you are not �touchy�,
and that you have to /think/ when you feel uncomfortable, not lash out
at whoever you think makes you feel uncomfortable. Can you do this?
--
Erik Naggum | Oslo, Norway 2004-026
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Erik Naggum wrote:
[cut]
> If you write the above code in Common Lisp, the purpose of running it
> will be to investigate the response to type errors. You will observe
> that you invoke the debugger. One of the things you could do then is
> to realize that the function that was called should be a generic
> function, and you can back out of the call, redefine the function
> x-plus-y, and resume execution by retrying the call. Another thing
> you could do is to realize that you had made a mistake in the caller.
> In this case, you would back out of the call to test, instead, and
> redefine that function and resume execution by calling the new test
> function.
I too am a recent arrival to the Lisp camp am still not convinced as to
the unconditionally superiority of the dynamic aspects of the type system.
What happens when the program is being put to actual use by actual end
users, who outnumbers the programmer(s) who made the program many
thousand times? The programmer(s) who made the program will not be there
to do their magic stuff at the top level in the break loop when the
program rolls over and falls into the break loop so to speak.
I guess you have to wrap everything important in a handler-case or
ignore-errors with a handler that can
restart/retry/shutdown/bugreport/etc. Just like you would do to for
instance a java program to handle runtime errors.
But if this is the case, then is all this dynamic typing stuff only of
benefit during development and debugging, and of no use during actual
use by end users because at that time going into the break loop equals a
crashed program?
Kristian
* Kristian Elof S�rensen
| I too am a recent arrival to the Lisp camp am still not convinced as
| to the unconditional superiority of the dynamic aspects of the type
| system.
Nobody implied it was unconditionally superior. You have to lose this
�one winner takes all� attitude. Different solutions can coexist. In
fact, different solutions /must/ coexist for the proper solution to be
applied to problems that differ from the historic problems to which
they were the solutions. Think evolution. In the real world, there
are no winners, only temporary advantages. The myth of the �winner�
is probably the second most destructive myth that Western civilization
has hoisted upon its population. (The most destructive myth is that
of people being either �good� or �evil�, which is the root cause of
all injustice ever perpetrated by humans.)
| But if this is the case, then is all this dynamic typing stuff only of
| benefit during development and debugging, and of no use during actual
| use by end users because at that time going into the break loop equals
| a crashed program?
What �this� refers to is not the case and none of the above follows.
If you insist that the way you view the world is the only only possible
(as is implied by resorting to �unconditional superiority�), everything
will turn out to run against your world-view sooner or later, and this
will naturally be interpreted as there being something wrong with the
world. For instance, when you equate a handled error condition with a
crash, you look at only the most superficial quality of a failure: That
it does something other than the user wanted. But most of the time,
real-world applications have an extremely strong requirement to either
complete their task to specification or not do any harm. The Common
Lisp condition system is eminently able to make computers behave in
the most rational way possible when they are unable to complete a task.
I strongly suggest that you not explore the boundary conditions until
you are comfortable with the normal operating parameters. This means
that you have to lose �unconditional�, �all�, �only�, �of no use�, etc.
Incidentally, type errors are irrelevant. They just do not happen in
Common Lisp code as often as they do in languages where the compiler
is responsible for catching them. It is understandable that someone
who has been burned hard and often by compilers who never seem to be
satisfied with one's code no matter how hard one tries, will believe
that this kind of mistake is very important and stands between him and
total disaster of the program. However, this is not how it works in
Common Lisp, because Common Lisp systems do not crash. They are so
forgiving and friendly that anyone who approaches them believing that
they will be hostile and interpret their responses as if they could
only have been hostile, will misunderstand and fight the system, much
like they would people they mistakenly believe are hostile.
--
Erik Naggum | Oslo, Norway 2004-026
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Kristian Elof S�rensen <····@image.dk> writes:
> What happens when the program is being put to actual use by actual end
> users, who outnumbers the programmer(s) who made the program many
> thousand times? The programmer(s) who made the program will not be
> there to do their magic stuff at the top level in the break loop when
> the program rolls over and falls into the break loop so to speak.
Not necessarily. Check the article in which Paul Graham explains how
bugs were fixed at ViaWeb (later Yahoo! Store) while the customers who
reported them were still at the phone.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
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?
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
* Pascal Costanza
| Why is it that programmers always seem to think that the rest of the
| world is stupid?
Because they are autodidacts. The main purpose of higher education
and making all the smartest kids from one school come together with
all the smartest kids from other schools, recursively, is to show every
smart kid everywhere that they are not the smartest kid around, that
no matter how smart they are, they are not equally smart at everything
even though they were just that to begin with, and there will therefore
always be smarter kids, if nothing else, than at something other than
they are smart at. If you take a smart kid out of this system, reward
him with lots of money that he could never make otherwise, reward him
with control over machines that journalists are morbidly afraid of and
make the entire population fear second-hand, and prevent him from ever
meeting smarter people than himself, he will have no recourse but to
believe that he /is/ smarter than everybody else. Educate him properly
and force him to reach the point of intellectual exhaustion and failure
where there is no other route to success than to ask for help, and he
will gain a profound respect for other people. Many programmers act
like they are morbidly afraid of being discovered to be less smart than
they think they are, and many of them respond with extreme hostility on
Usenet precisely because they get a glimpse of their own limitations.
To people whose entire life has been about being in control, loss of
control is actually a very good reason to panic.
--
Erik Naggum | Oslo, Norway 2004-026
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Erik Naggum wrote:
> [...]
a nice little psychological report :)
From: Joe Marshall
Subject: Re: Static/Strong/Implicit Typing
Date:
Message-ID: <smi1h3iz.fsf@ccs.neu.edu>
Pascal Costanza <········@web.de> writes:
>
> Why is it that programmers always seem to think that the rest of the
> world is stupid?
First-order engineering approximation.
Pascal Costanza <········@web.de> writes:
> 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)
sajiimori wrote:
>
> My first impulse is to agree, but the biggest (generally agreed upon)
> benefit of static typing is that type errors are caught at compile-time,
I think you are a bit behind the times. The hard-core, static-typing C++
crowd has changed its mind:
http://www.mindview.net/WebLog/log-0025
Bruce Eckels writes:
"That is to say, if a program compiles in a strong, statically typed
language, it just means that it has passed some tests. It means that the
syntax is guaranteed to be correct (Python checks syntax at compile
time, as well. It just doesn't have as many syntax contraints). But
there's no guarantee of correctness just because the compiler passes
your code. If your code seems to run, that's also no guarantee of
correctness... The only guarantee of correctness, regardless of whether
your language is strongly or weakly typed, is whether it passes all the
tests that define the correctness of your program. "
Along the way he cites Robert Martin coming to the same conclusion:
http://www.artima.com/weblogs/viewpost.jsp?thread=4639
Martin also contradicts your lack of enthusiasm for dynamic languages:
"I thought an experiment was in order. So I tried writing some
applications in Python, and then Ruby (well known dynamically typed
languages). I was not entirely surprised when I found that type issues
simply never arose. My unit tests kept my code on the straight and
narrow. I simply didn't need the static type checking that I had
depended upon for so many years.
"I also realized that the flexibility of dynamically typed langauges
makes writing code significantly easier. Modules are easier to write,
and easier to change. There are no build time issues at all. Life in a
dynamically typed world is fundamentally simpler.
"Now I am back programming in Java because the projects I'm working on
call for it. But I can't deny that I feel the tug of the dynamically
typed languages. I wish I was programming in Ruby or Python, or even
Smalltalk."
So maybe you should get off Usenet and do some Lisp and find out what
you are missing.
kenny
--
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
> > My first impulse is to agree, but the biggest (generally agreed upon)
> > benefit of static typing is that type errors are caught at compile-time,
>
> I think you are a bit behind the times. The hard-core, static-typing C++
> crowd has changed its mind:
Thanks, but I'm not particularly interested in arguments from authority.
Besides, the quote from Bruce Eckel doesn't seem to argue against static
typing -- all it says is that the compiler can't guarantee that your program
is correct (which should be obvious).
> Martin also contradicts your lack of enthusiasm for dynamic languages:
Sorry, I'll try to post with more enthusiasm next time. Do I need more
smileys? (I guess I can't say the word 'static' without getting
pidgeon-holed.)
> So maybe you should get off Usenet and do some Lisp and find out what
> you are missing.
I wonder how you got the impression that I have not used Lisp? (This
newsgroup seems to have a taboo against discussing language features.)
I think I may take your advice and stop posting here... everybody is so
hostile. It's really shocking to go from a friendly community of developers
(like the Gameboy Advance forum I visit often) to a group like this one. It
really makes me lose a bit of faith in the Internet, and in human decency in
general.
sajiimori wrote:
>
> > > My first impulse is to agree, but the biggest (generally agreed upon)
> > > benefit of static typing is that type errors are caught at compile-time,
> >
> > I think you are a bit behind the times. The hard-core, static-typing C++
> > crowd has changed its mind:
>
> Thanks, but I'm not particularly interested in arguments from authority.
What about arguments from superiority? You couldn't carry Eckel or
Martin's lunch pail.
> I think I may take your advice and stop posting here... everybody is so
> hostile. It's really shocking to go from a friendly community of developers
> (like the Gameboy Advance forum I visit often) to a group like this one. It
> really makes me lose a bit of faith in the Internet, and in human decency in
> general.
Don't judge all of Usenet by us, the Savages of Comp.lang.lisp. Trolls
survive for weeks on other NGs, we The Savages chew them up and spit
them out in days.
Also, Robert Martin is comparing Python and Ruby to C++ and Java, saying
that dynamic typing made things much easier. No suprise there.
I'd imagine that if he were comparing to OCAML or Haskell he wouldn't see
such a clear distinction. But that's just speculation.
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.
>
>
>>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"))
>
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
> I think what Pascal was hinting here, is that "semantic" errors due to
> non-typing issues (e.g. race coniditons, inproper control flows etc) may
> be identified earlier if you could run a program that did not pass the
> type checker.
It sounds like you're talking about having the choice of which bugs to fix
first. That does seem like a good thing.
> Common Lispers (at least the writer :) ) are not willing to
> forfeit anything that would break a conformant Common Lisp program.
*gasp* -- A straightforward answer to the original question! =)
> > Of course! So, as a variant of my original question: In a statically,
> > implicitly typed Lisp, do you think the features would still complement
each
> > other well?
>
> That is the challenge for you :) First of all you have to substitute
> "Lisp" with "Common Lisp" and then you have to make sure that such
> features do complement each other well.
After hearing more about CMCUL, I'm wondering if the challenge is still
there to be had. Maybe all you have to do to get a statically typed CL is:
1) Write a CL program that doesn't do anything particularly dynamic.
2) Compile it with CMUCL, with all the type checking facilities turned on.
sajiimori wrote:
>>I think what Pascal was hinting here, is that "semantic" errors due to
>>non-typing issues (e.g. race coniditons, inproper control flows etc) may
>>be identified earlier if you could run a program that did not pass the
>>type checker.
>
>
> It sounds like you're talking about having the choice of which bugs to fix
> first. That does seem like a good thing.
Yes. It is about "habitability" of software. This is a concept that
Gabriel wrote about in his "Patterns of Software".
>
>
>>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! =)
Hope you like it :) Let me be nastier. :)
Common Lispers (at least the writer :) ) are not willing to write any
code that will work only in implementation X (Ok: bear with me. I am
currently writing code that runs on implementation Y! :) ).
That is to say: if you come up with an implementation X of Common Lisp
that does a form of "static type checking", then I want to be able to
take the code I wrote for it and be able to run it in another conformant
CL implementation that does not use your static type checking machinery.
>
>
>>>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.
>
Yes and no. There are issues in Common Lisp typing that can only be
fixed by extending the language. One of them is "sealing" of classes.
Another one is declaration of return values in functions. CMUCL (and
SBCL) is a step in the right direction.
There are plenty of open problems to be fixed in non trivial ways.
Whether that will get you published in TOPLAS etc etc is another matter :)
Cheers
--
Marco
Hi Marco Antoniotti,
> Yes and no. There are issues in Common Lisp typing that can only be
> fixed by extending the language. [...] one is declaration of return
> values in functions.
Look up FTYPE. Here's a global example:
(declaim (ftype (function ((double-float 0d0)) double-float) df-sqrt))
(defun df-sqrt (df)
(declare (optimize (speed 3) (safety 3)))
(sqrt df))
Paste the code into the SBCL REPL and try evaluating (df-sqrt 2d0) and
then (df-sqrt 2f0). In the second case you will find the debugger is
invoked with "The value 2.0 is not of type (DOUBLE-FLOAT 0.0d0)."
Now try returning a different type than declared:
(defun df-sqrt (df)
(declare (optimize (speed 3) (safety 3)))
(coerce (sqrt df) 'single-float))
You will get this compilation warning:
; caught warning:
; Asserted type (values double-float &rest t) conflicts with derived type
; (values single-float &optional).
Now try evaluating the square root of 2d0 using DF-SQRT:
debugger invoked on a SB-KERNEL:VALUES-TYPE-ERROR in thread 2071:
The values set [1.4142135] is not of type (VALUES DOUBLE-FLOAT &REST T).
Regards,
Adam
In article <····················@newsread2.news.pas.earthlink.net>,
sajiimori <··········@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/
> Argument Y is not a NUMBER: "asdf".
> [Condition of type SIMPLE-TYPE-ERROR]
> ...
> The point is that in general, in Common Lisp, you don't know ahead of
> time what values a function may accept. Without changing the definition
> of "test", I made it execute without error - thus why should the
> compiler yell at you for something which is a /current, possible/ error
> in the code?
I don't understand. I thought you were posting an example of CMUCL issuing
a warning about a current, possible error. So at first, I thought you were
saying "yeah, CMUCL can do that", but then it sounded like you didn't think
the feature makes sense. Were you giving an example of a feature of CMUCL
that you don't like?
> Errors in compilation only mean that the code is meaningless. The code
> you provided was not meaningless. Its meaning happened to involve a
> runtime error, but not meaninglessness.
Agreed. In other languages, code like that might very well be meaningless.
(I've been informed that Eclipse can run Java code that has type errors, but
Eclipse is very generous to do so, because such code isn't really in Java.)
> And there is no way to make the
> compiler gag on the above without destroying the dynamicity of the
> language.
Well, you can get CMUCL to at least warn about it (using what Eric Marsden
informed me is called block-compilation), right? I suppose you could say
that enabling that feature destroys the dynamicity of the language, but as
Pascal Costanza argued earlier, why restrict your toolset? I might want
static type checking sometimes.
In article <·····················@newsread1.news.pas.earthlink.net>,
sajiimori <··········@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" <··········@hotmail.com> writes:
> 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.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
"sajiimori" <··········@hotmail.com> writes:
>> 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
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
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.
:)
Kenny Tilton <·······@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...
Oh, and *tag*, Rahul's "it"
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Kenny Tilton <·······@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
·······@nada.kth.se (Bj�rn Lindberg) writes:
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > Kenny Tilton <·······@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.
Yeah, but I wasn't expecting him to -- I was just being a little
obnoxious, partly to see if I was going to get a grand You Are Not
Worthy Of My Attention post in response to something that was 37/38
helpful content. Got my answer.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
"Thomas F. Burdick" wrote:
>
> ·······@nada.kth.se (Bj�rn Lindberg) writes:
>
> > ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> >
> > > Kenny Tilton <·······@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.
>
> Yeah, but I wasn't expecting him to -- I was just being a little
> obnoxious, partly to see if I was going to get a grand You Are Not
> Worthy Of My Attention post in response to something that was 37/38
> helpful content. Got my answer.
Ok, so that's how you level up in this game. Sajii poses as reasonable
to avoid triggering the troll immune response and keep the troll going
for a couple of months. His only problem is when someone makes a really
good point. Then he has to claim a foul, to avoid responding. So until
you get Sajii to claim a foul and put you on ignore, you haven't won.
Looks like Erik got the gold, I got the silver, Thomas got the bronze.
:)
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
In article <·················@nyc.rr.com>, Kenny Tilton
<·······@nyc.rr.com> wrote:
> Looks like Erik got the gold, I got the silver, Thomas got the bronze.
And do I get a dishonorable mention for making good points without
being ignored?
FWIW, I think you're all being juvenile about this.
--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/
Brian Mastenbrook wrote:
>
> In article <·················@nyc.rr.com>, Kenny Tilton
> <·······@nyc.rr.com> wrote:
>
> > Looks like Erik got the gold, I got the silver, Thomas got the bronze.
>
> And do I get a dishonorable mention for making good points without
> being ignored?
Worse. You get the Lady Bing Trophy* for being decent enough to take Saj
seriously. c.l.l. has in the past been castigated for being toxic to
newbies. On the contrary, even trolls get treated with courtesy and
earnest attempts to educate. That drives trolls nuts, btw.
>
> FWIW, I think you're all being juvenile about this.
<harrumph> I prefer silly. Also drives trolls nuts.
:)
kenny
*Annual National Hockey League (US/Canada) award to the nicest hockey
player.
Kenny Tilton wrote:
> Looks like Erik got the gold, I got the silver, Thomas got the bronze.
Kenny,
Discussions about who is best at dispelling trolls are equally useful as
discussions about whether Ben Affleck is a vegetarian because he wears a
headscarf while watching football.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza <········@web.de> writes:
> Discussions about who is best at dispelling trolls are equally useful
It's an unwritten usenet law that we need pissing contests every now
and then!
--
(espen)
* Pascal Costanza -> Kenny Tilton
| Discussions about who is best at dispelling trolls are equally useful
| as discussions about whether Ben Affleck is a vegetarian because he
| wears a headscarf while watching football.
In good Lisp style, you have offered a novelty: The recursive troll.
I say: Death to the meta-trolls! Off with their heads!
--
Erik Naggum | Oslo, Norway 2004-028
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Erik Naggum <····@naggum.no> writes:
> * Pascal Costanza -> Kenny Tilton
> | Discussions about who is best at dispelling trolls are equally useful
> | as discussions about whether Ben Affleck is a vegetarian because he
> | wears a headscarf while watching football.
>
> In good Lisp style, you have offered a novelty: The recursive troll.
>
> I say: Death to the meta-trolls! Off with their heads!
And then their tails.
--
Gareth McCaughan
.sig under construc
A long time ago, in a galaxy far, far away, Erik Naggum <····@naggum.no> wrote:
> * Pascal Costanza -> Kenny Tilton
> | Discussions about who is best at dispelling trolls are equally useful
> | as discussions about whether Ben Affleck is a vegetarian because he
> | wears a headscarf while watching football.
>
> In good Lisp style, you have offered a novelty: The recursive troll.
>
> I say: Death to the meta-trolls! Off with their heads!
So that would mean...
(cdr meta-trolls)?
--
let name="cbbrowne" and tld="ntlug.org" in name ^ ·@" ^ tld;;
http://www3.sympatico.ca/cbbrowne/wp.html
"On a normal ascii line, the only safe condition to detect is a
'BREAK' - everything else having been assigned functions by Gnu
EMACS." -- Tarl Neustaedter
From: Kenny Tilton
Subject: Ben & Jen [was Re: Static/Strong/Implicit Typing]
Date:
Message-ID: <4017D522.B15C1071@nyc.rr.com>
Pascal Costanza wrote:
>
> Kenny Tilton wrote:
>
> > Looks like Erik got the gold, I got the silver, Thomas got the bronze.
>
> Kenny,
>
> Discussions about who is best at dispelling trolls are equally useful as
> discussions about whether Ben Affleck is a vegetarian because he wears a
> headscarf while watching football.
Fantastic! I thought I was the only one who wanted to talk about Ben &
Jen. I guess it's really over this time. This is going to take me a
while to get over. I guess the bright side is that two hotties are back
on the open market. I wonder who they are seeing now. Have you heard
anything?
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
Pascal Costanza <········@web.de> writes:
> Discussions about who is best at dispelling trolls are equally useful as
> discussions about whether Ben Affleck is a vegetarian because he wears a
> headscarf while watching football.
But does his mother cook vegetables until they're indistinguishable from
toothpaste?
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
> In all fairness, recall that this is an international forum. Probably
> most readers did not get the actor reference in your reply.
I didn't, but then I don't know how one could type that Mr. T-ism well
enough to convey the speaker.
> For
> instance, when Kenny from time to time talks about various local
> sports teams I am completely lost.
I actually felt bad about that since I had no way of knowing if even the
addressee knew that decades apart Bucky Dent and Aaron Boone had been
the (baseball) New York Yankee executioners (by homerun) of the Boston
Red Sox. I'll try to footnote these important moments in human history
in the future.
And yes, a Boston groundskeeper started celebrating a Boston rally while
standing in the Yankee bullpen (with Yankee players). Jeez, one Yankee
left his position in the outfield to climb over the bullpen (where
pitchers warm up before entering a game) fence to join in the beating.
:)
It was a shameful moment. <pwuahhahahhahahah>
kenny
Kenny Tilton <·······@nyc.rr.com> writes:
> I didn't, but then I don't know how one could type that Mr. T-ism well
> enough to convey the speaker.
Ah pity da foo' dat don't know how ta talk like Mr. T!
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
>>>>> "sm" == sajiimori <··········@hotmail.com> writes:
sm> If I were still running a Unix, I'd check out CMUCL -- as it is, I've only
sm> seen CLISP and Corman, neither of which catch type errors at compile time.
sm> :( Would CMUCL warn about this during compile-time? If not, do you think
sm> it should?
sm>
sm> (defun x-plus-y (x y)
sm> (+ x y))
sm>
sm> (defun test ()
sm> (x-plus-y 5 "asdf"))
in its default mode of operation, the CMUCL compiler assumes that a
function may be redefined at runtime (unless it is declared to be
inlineable). Therefore, it doesn't generate a warning when compiling
code like this.
However, CMUCL's block-compilation mechanism allows you to tell the
compiler that functions won't be redefined at runtime, which gives you
semantics closer to static languages like C/Java/ML. There are a
number of ways to obtain block-compilation (see the CMUCL User's
Manual); one of them is to provide extra arguments to COMPILE-FILE.
,----
| CL-USER> (compile-file "err" :block-compile t :entry-points '(test))
| ; File: /tmp/err.lisp
| ; In: defun x-plus-y
| ; (+ x y)
| ; Warning: Lisp error during constant folding:
| ; Argument y is not a number: "asdf".
`----
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
> However, CMUCL's block-compilation mechanism allows you to tell the
> compiler that functions won't be redefined at runtime
Hey, that's great! For the projects I've done so far in CL, I would
probably turn on such a feature globally. Then if the time comes that
rebinding function values of symbols (via defun, not labels) seems useful,
it would be nice to be able to fall back to the normal compilation style.
>> However, CMUCL's block-compilation mechanism allows you to tell the
>> compiler that functions won't be redefined at runtime
"sajiimori" <··········@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
> 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.
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?
In article <····················@newsread1.news.pas.earthlink.net>,
sajiimori <··········@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.
--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/
> As such there is one program which does do a lot of redifinitions of
> 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.
In article <·····················@newsread1.news.pas.earthlink.net>,
sajiimori <··········@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 :-)
--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/
From: Joe Marshall
Subject: Re: Static/Strong/Implicit Typing
Date:
Message-ID: <k73dh32j.fsf@ccs.neu.edu>
Brian Mastenbrook <····················@cs.indiana.edu> writes:
> 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.
Huh? Who taught them that?!
In the ITS operating system, designed by the hackers at MIT, the
debugger *was* the shell. You could peek and poke at memory locations
from the prompt, or map in an image and jump to its entry point to run
a program.
The point is that the debugger should be an integral part of any
system that might have bugs.
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu>
wrote:
> Huh? Who taught them that?!
>
> In the ITS operating system, designed by the hackers at MIT, the
> debugger *was* the shell. You could peek and poke at memory locations
> from the prompt, or map in an image and jump to its entry point to run
> a program.
>
> The point is that the debugger should be an integral part of any
> system that might have bugs.
The issue in question was the relation of debugging to failure
continuations - the schemer in question is the author of SISC, and we
were discussing whether failure continuations should trip dynamic wind
points. My argument is that the debugger is just another failure
continuation, and debugging doesn't make sense if you are tripping wind
points on the way to it. His was that debugging is not the same as a
normal failure continuation, and that in debugging, you are in a
different mode of execution where you pause the program.
This is not an argument I personally accept - I expect the system to
treat me, the human, as just another program, and thus arguments about
debugging are valid arguments about the design of the system. For that
matter, I might be writing a programmatic debugger. Or I might not. Who
knows?
I think Schemers have a rather un-Lisp-like tendency against treating
the whole of program development in the same way, whether it's phase
separation or debugging. What good is too much phase separation when
you're just going to load it into the same image you compiled it in?
Why treat debugging differently when I may want to write a debugger? It
doesn't make much sense to me.
--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/
Brian Mastenbrook <··············@cs.indiana.edu> writes:
> In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu>
> wrote:
>
>> Huh? Who taught them that?!
>>
>> In the ITS operating system, designed by the hackers at MIT, the
>> debugger *was* the shell. You could peek and poke at memory locations
>> from the prompt, or map in an image and jump to its entry point to run
>> a program.
>>
>> The point is that the debugger should be an integral part of any
>> system that might have bugs.
>
> The issue in question was the relation of debugging to failure
> continuations - the schemer in question is the author of SISC, and we
> were discussing whether failure continuations should trip dynamic wind
> points. My argument is that the debugger is just another failure
> continuation, and debugging doesn't make sense if you are tripping wind
> points on the way to it. His was that debugging is not the same as a
> normal failure continuation, and that in debugging, you are in a
> different mode of execution where you pause the program.
That's a different and more subtle question. If the language is
supporting continuable exceptions (for instance, upon zero division it
allows you to supply a different divisor), then the debugger ought to
enter a REPL in the dynamic context of the error. If that's the case,
there is no need to unwind anything.
If, however, you transfer control to a different dynamic context, you
of course have to run the unwinds!
"sajiimori" <··········@hotmail.com> writes:
> 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
sajiimori wrote:
>>However, CMUCL's block-compilation mechanism allows you to tell the
>>compiler that functions won't be redefined at runtime
>
>
> Hey, that's great! For the projects I've done so far in CL, I would
> probably turn on such a feature globally. Then if the time comes that
> rebinding function values of symbols (via defun, not labels) seems useful,
> it would be nice to be able to fall back to the normal compilation style.
>
Yes. You can do that in CMUCL, and you can arrange your code to run
intact in another implementation.
However, the process of making such a feature part of the language, as
opposed to *one* implementation of the language, is not that
straightforward. Common Lisp has more than 1.8 implementations. The CL
"language" is somewhat separate from the CL "implementations".
Do you see the difficulties here as well?
Cheers
--
Marco
"sajiimori" <··········@hotmail.com> writes:
> That's exactly what I'm hoping for, because I'm trying to make a Lispy
> language that uses strong, static, implicit typing (just as an experiment --
> I don't know if I would even use such a language in place of CL).
Feel free to do that if you think it is the most useful approach (I
don't), but in the spirit of Erik's "Different solutions can
coexist" comment, instead of making a new language, you could take
a look at soft typing�, researched quite a bit by the PLT Scheme�
folks and realized in, for example, MrSpidey�. Although one could
say that CMUCL effectively has that sort of stuff built-in, the
"external tool" approach of the PLT people might be a better match
if you liked to experiment with your own code in the context of
Common Lisp in general (I think this would be quite interesting).
Their work is also backed by papers that you can delve into,
whereas CMUCL's analysis is more ad-hoc and not very well
documented, IIRC.
----
� Google this.
--
Hannu
> Feel free to do that if you think it is the most useful approach (I
> don't), but in the spirit of Erik's "Different solutions can
> coexist" comment, instead of making a new language, you could take
> a look at soft typing�, researched quite a bit by the PLT Scheme�
> folks and realized in, for example, MrSpidey�. Although one could
> say that CMUCL effectively has that sort of stuff built-in, the
> "external tool" approach of the PLT people might be a better match
> if you liked to experiment with your own code in the context of
> Common Lisp in general (I think this would be quite interesting).
> Their work is also backed by papers that you can delve into,
> whereas CMUCL's analysis is more ad-hoc and not very well
> documented, IIRC.
I was reading about soft-typing for Scheme recently -- to be honest, most of
the papers were a little over my head. =) I recall reading that most
function return types and variable types couldn't be inferred to a
significant degree (perhaps because idiomatic Scheme tends to be too
dynamic).
I think I'll have to set up some sort of Unix again, just to try out
CMUCL... it's sounding better by the minute.
sajiimori wrote:
> I was reading about soft-typing for Scheme recently -- to be honest, most of
> the papers were a little over my head. =) I recall reading that most
> function return types and variable types couldn't be inferred to a
> significant degree (perhaps because idiomatic Scheme tends to be too
> dynamic).
Some compilers make several compiled versions of the same function.
A little simplified: If the types of the arguments are known in
a specific function call, a specialized function is called.
If the types are unknown a general version is called. Using this
approach [but in a much more sophisticated way] Siskind and others
have gotten fine results.
--
Jens Axel S�gaard
Jens Axel S�gaard <······@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". :)
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain <·····@nyct.net> writes:
> Jens Axel S�gaard <······@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.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@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.
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.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain <·····@nyct.net> writes:
> ···@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.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Rahul Jain wrote:
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> 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 :).
Sajiimori wrote:
"I recall reading that most function return types and variable
types couldn't be inferred to a significant degree "
And that claim is somewhat vague. What specific analysis? Is
it typical programs or specific hard-to-analyze programs?
The more sophisticated techniques you use, the better results you get.
As a simplified example of how to improve a simple minded analysis,
I offered the case, where the analysis is fooled in general, but succeeds
at say 90% of the call sites. Making several specialized versions of the
same function is one way to make use of the type analysis. Redefinition is
harder to implement but not impossible.
--
Jens Axel S�gaard
Hi sajiimori,
> If I were still running a Unix, I'd check out CMUCL -- as it is, I've only
> seen CLISP and Corman, neither of which catch type errors at compile time.
> :( Would CMUCL warn about this during compile-time? If not, do you think
> it should?
>
> (defun x-plus-y (x y)
> (+ x y))
>
> (defun test ()
> (x-plus-y 5 "asdf"))
Ideally they could catch this. But consider the correct implementation
using a compiler macro:
(declaim (inline x-plus-y))
(defun x-plus-y (x y)
(+ x y))
(define-compiler-macro x-plus-y (x y)
`(+ ,x ,y))
Now try defining test and compiling it:
* (defun test ()
(x-plus-y 5 "asdf"))
* (compile 'test)
; Compiling lambda nil:
; In: lambda nil
; (x-plus-y 5 "asdf")
; ==>
; (+ 5 "asdf")
; Warning: Lisp error during constant folding:
; Argument y is not a number: "asdf".
;
; Warning: This is not a (values &optional number &rest t):
; "asdf"
;
; Compiling Top-Level Form:
; Compilation unit finished.
; 2 warnings
The error is instantly discovered in SBCL because it compiles
all forms.
Regards,
Adam
> Ideally they could catch this. But consider the correct implementation
> using a compiler macro:
Don't worry; I wasn't trying to pass that code off as "correct". =) I only
had a very specific question about one CL implementation in particular.
sajiimori 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."
> Imagine a Java class C that needs to implement an interface I. Assume
> that I requires you to implement quite a large number of methods, but
> that you currently only want to focus on a few of them.
Great example -- thanks!
> No, it's not a generally agreed upon benefit of static typing that type
> errors are caught at compile-time.
I guess I should have said something like: "For all X who believe that
static typing has significant benefits, X is likely to believe that the
biggest benefit of static typing is the ability to catch type errors at
runtime." I apologize for my lack of precision.
> Dynamically
> typed languages are much better able to handle even unanticipated changes.
That makes sense.
> > That's exactly what I'm hoping for, because I'm trying to make a Lispy
> > language that uses strong, static, implicit typing (just as an
experiment --
> > I don't know if I would even use such a language in place of CL).
>
> This has been done before. You might want to google for papers on this
> issue.
I did, but I couldn't find anything that really supplied a pervasive,
implicit type system akin to that of Haskell.
> > Would CMUCL warn about this during compile-time? If not, do you think
> > it should?
> >
> > (defun x-plus-y (x y)
> > (+ x y))
> >
> > (defun test ()
> > (x-plus-y 5 "asdf"))
>
> Do you think this is an example of a typical error programmers make?
Of course not. It was a very specific question about one particular CL
implementation. (Why have I had to explain that so many times? I thought I
was being clear.)
> The single most important feature of Lisp for me is its metacircularity,
> both in its simple form available as macro programming and in its more
> structured form as the CLOS metaobject protocol. I simply can't imagine
> how this could be achieved in a statically typed language.
It seems like the simple answer is to provide static typing when it's both
possible and desirable.
> You know, Common Lispers sound very religious at times, but they are
> actually extremely pragmatic. They just want to use the best tool for
> their job. ;)
As usual, it depends on the individual. Practical people can be hostile
too, and that's what I have a problem with.
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.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
> >>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. 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" <··········@hotmail.com> writes:
> 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?
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
> Does the existence of a keyboard mean your program should refuse
> 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" <··········@hotmail.com> writes:
>> Does the existence of a keyboard mean your program should refuse
>> 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".
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)?
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
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.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza <········@web.de> writes:
> 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
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
> No, I haven't said that. I was still talking about that specific
> 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. ;-)
"sajiimori" <··········@hotmail.com> writes:
> 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
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
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
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza wrote:
> class C implements I {
>
> void m() {...}
>
> void n() {
> throw new RuntimeException("C::n not yet implemented");
> }
>
> int o() {
> throw new RuntimeException("C::o not yet implemented");
> }
> }
>
> This is _exactly_ what dynamically typed languages do by default when
> functions/methods are called that don't exist yet. So my conclusions are:
>
> a) Statically typed languages distract you from your flow of thinking.
> (See how much you need to do before you can proceed with your original
> goal, to work on m.)
>
> b) Dynamically typed languages implement the behavior by default that
> you need to write yourself repeatedly in a statically typed language.
With a good IDE you can create such code with a fingertip on a hotkey.
The IDE will insert a lot of things that you would usually have to type
by yourself, so while programming you can let do the IDE the work and
continue working on your real problem.
For Java IDEA looks very nice.
> With a good IDE you can create such code with a fingertip on a hotkey.
> The IDE will insert a lot of things that you would usually have to type
> by yourself, so while programming you can let do the IDE the work and
> continue working on your real problem.
> For Java IDEA looks very nice.
For me, the more I have to rely on an IDE to turn an unfriendly language
into a friendly one, the less I tend to appreciate the language itself.
When I kept hearing people say that Lisp is a pain unless you use EMACS, it
really turned me off for a while. In reality, it only took me about a week
to get used to it with a simpler editor (ConTEXT).
sajiimori wrote:
>>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..
Andr� Thieme wrote:
> Pascal Costanza wrote:
>
>> class C implements I {
>>
>> void m() {...}
>>
>> void n() {
>> throw new RuntimeException("C::n not yet implemented");
>> }
>>
>> int o() {
>> throw new RuntimeException("C::o not yet implemented");
>> }
>> }
>>
>> This is _exactly_ what dynamically typed languages do by default when
>> functions/methods are called that don't exist yet. So my conclusions are:
>>
>> a) Statically typed languages distract you from your flow of thinking.
>> (See how much you need to do before you can proceed with your original
>> goal, to work on m.)
>>
>> b) Dynamically typed languages implement the behavior by default that
>> you need to write yourself repeatedly in a statically typed language.
>
>
> With a good IDE you can create such code with a fingertip on a hotkey.
> The IDE will insert a lot of things that you would usually have to type
> by yourself, so while programming you can let do the IDE the work and
> continue working on your real problem.
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.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Joe Marshall
Subject: Re: Static/Strong/Implicit Typing
Date:
Message-ID: <fze1h2nj.fsf@ccs.neu.edu>
Andr� Thieme <······································@justmail.de> writes:
> Pascal Costanza wrote:
>
>> class C implements I {
>> void m() {...}
>> void n() {
>> throw new RuntimeException("C::n not yet implemented");
>> }
>> int o() {
>> throw new RuntimeException("C::o not yet implemented");
>> }
>> }
>> This is _exactly_ what dynamically typed languages do by default
>> when functions/methods are called that don't exist yet. So my
>> conclusions are:
>> a) Statically typed languages distract you from your flow of
>> thinking. (See how much you need to do before you can proceed with
>> your original goal, to work on m.)
>> b) Dynamically typed languages implement the behavior by default
>> that you need to write yourself repeatedly in a statically typed
>> language.
>
> With a good IDE you can create such code with a fingertip on a
> hotkey.
I've always been amused by that. Rather than create an abstraction by
which you could say:
class C partly implements I {
....
}
It inserts a ton and a half of `boilerplate' that sort of papers over
the problem.
If your IDE writes code for you, then your language is missing an
important feature.
Andr� Thieme wrote:
> Pascal Costanza wrote:
>
>> class C implements I {
>>
>> void m() {...}
>>
>> void n() {
>> throw new RuntimeException("C::n not yet implemented");
>> }
>>
>> int o() {
>> throw new RuntimeException("C::o not yet implemented");
>> }
>> }
>>
>> This is _exactly_ what dynamically typed languages do by default when
>> functions/methods are called that don't exist yet. So my conclusions are:
>>
>> a) Statically typed languages distract you from your flow of thinking.
>> (See how much you need to do before you can proceed with your original
>> goal, to work on m.)
>>
>> b) Dynamically typed languages implement the behavior by default that
>> you need to write yourself repeatedly in a statically typed language.
>
>
> With a good IDE you can create such code with a fingertip on a hotkey.
> The IDE will insert a lot of things that you would usually have to type
> by yourself, so while programming you can let do the IDE the work and
> continue working on your real problem.
> For Java IDEA looks very nice.
Sounds like Emacs vintage 1986. That is when I switched from vi :)
Cheers
--
Marco
Pascal Costanza wrote:
> 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. ;)
>
Does it mean that *you* want to use the best tool for *my* job? :) I
like that. I have a few programming thingies to get done that I have no
time to get around and do :)
Cheers
--
Marco
Marco Antoniotti wrote:
>
>
> Pascal Costanza wrote:
>
>
>> 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. ;)
>>
>
> Does it mean that *you* want to use the best tool for *my* job? :)
No, not really... ;)
> I like that. I have a few programming thingies to get done that I have no
> time to get around and do :)
OK, I think I can manage. Unless you need this before 2007...
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
On 8635 day of my life ··········@hotmail.com wrote:
>> 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).
I am working on similar project: defstrong macro. Type inference
engine is almost complete (it is usable, but I plan to extend it).
I created my own type inference algorithm with unification, but later
I learn from someone that Hindley-Milner algorithm uses unification too,
so I probably reinvented a wheel :)
I started this project rather for fun than for applications. :) And I
want to demonstrate possibilities of Lisp macro systems to some local
non-believers :)
--
Ivan Boldyrev
Onions have layers. Unix has layers too.
From: Joe Marshall
Subject: Re: Static/Strong/Implicit Typing
Date:
Message-ID: <ptd9ozud.fsf@comcast.net>
"sajiimori" <··········@hotmail.com> writes:
> Warning: This thread is not a request for help on any particular problem.
> It's just for discussion, so if you're not into that sort of thing, don't
> blame me if you decide to post anyway.
>
> If there were a statically, implicitly typed Lisp, would you use it?
Possibly.
> What qualities of dynamic typing would you miss?
What qualities of dynamic typing would be missing?
--
~jrm
> What qualities of dynamic typing would be missing?
Good question... how about this?
(setq x 5)
(setq x "hello")
Or this?
(typecase (read)
(integer (print "you typed an integer"))
(string (print "you typed a string"))
(t (print "i don't know what you typed")))
I'm sure that's just the tip of the iceberg, but I haven't been using Lisp
long enough to discover many significant benefits of dynamic typing.
* sajiimori
| I'm sure that's just the tip of the iceberg, but I haven't been using Lisp
| long enough to discover many significant benefits of dynamic typing.
We already knew that by now. You are probably the millionth person to
come to Common Lisp thinking that the only solution to your problems
in making programs work correctly is static type analysis, because
that was the solution to the same problem in the previous language you
tried to learn by trial-and-error. Trust me, the solution is not to
add static type analysis to the language, it is to upgrade your brain
to work with a new language and a new set of solutions to a new set of
problems. Static type analysis leads to brain damage and it has to be
repaired before you can deal with a world where others are not obliged
to do only what you have advertised that you accept.
There is a golden rule about learning anything new. First, you look
long and hard at it and determine that it is not something you already
know. Then, you look at all the differences you can find and work
hard to disregard any emotional responses of the sort �I already know
this!� because you think you see a similarity. Finally, you approach
it as something you have to learn, because you realize that you do not
already know it. If you do not follow this golden rule, you will only
succeed in treating all things that are somewhat similar as the same,
and you will respond with things like �You folks sure are touchy� when
you think you see something that is similar to something you already
determined was the result of being �touchy�. When you are mistaken in
making such pronouncements, you get snubbed by people you have angered
and you probably become even more certain that they are touchy, but
you have in fact insulted them with your prejudice and they try to
make you back off and take another look at the evidence. If you are
not the kind of person who is able to disregard similarities and look
for the surprising dissimilarity with curiosity, this will not work,
and you will only deepen your conviction that you already understand
what you see. I know what I think about you right now, but you have
the option of responding with more curiosity and less judgment at any
time. Some psychologists argue that this is a personality property
and that some people naturally judge before they know what they look
at, while others are naturally curious and defer judgment even when
they know what they look at. Both need to do something unnatural at
times and break the natural habit, but if you are the judging type and
something uncomfortable shows up, your tendency to judge before you
think will most probably overwhelm any residiual curiosity. You make
a distinct impression of being very strongly judging, so this is a
very strong strong request for you to back off from your judgments and
take a closer look at the evidence.
--
Erik Naggum | Oslo, Norway 2004-026
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
From: Joe Marshall
Subject: Re: Static/Strong/Implicit Typing
Date:
Message-ID: <r7xmircf.fsf@ccs.neu.edu>
"sajiimori" <··········@hotmail.com> writes:
>> What qualities of dynamic typing would be missing?
>
> Good question... how about this?
>
> (setq x 5)
> (setq x "hello")
I do this sort of thing.
> Or this?
>
> (typecase (read)
> (integer (print "you typed an integer"))
> (string (print "you typed a string"))
> (t (print "i don't know what you typed")))
>
And this. As a matter of fact, I find myself doing this more and
more.
I would not want to use a language that did not let me do this sort of
thing.
---
I imagine that you may want an example, though. I have a versioned
transaction system where a transaction takes `version specifier' as an
argument. The version specifier may take on many possible forms:
a literal bitmap specifying which composite elements to use
the keyword :LATEST
a versioned object reference indicating indirection through a
meta-versioned context
and certain combinations of those.
Actually, the code that constructs the version from the version
specifier is recursive, so I need a recursive discriminated union.
Fortunately, Lisp objects are a recursive discriminated union.
It is type-safe, though. If you pass in a floating point number, you
will get an error.
"sajiimori" wrote:
> 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
> 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).
> 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? =)
"sajiimori" <··········@hotmail.com> writes:
>> 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
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
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.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
"sajiimori" wrote:
> > 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).
So now you have a type system that allows functions to
have types like "'a -> 'a where 'a is 'b list or 'b vector"?
> > 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)?
Obviously because I'm so much cleverer than all the other
people who replied to you :-). Or, considerably more likely
(especially in view of who some of them are), because they
saw other problems that they regarded as more important.
> > 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?
Depends on what you mean by "based on", I suppose. If I say
(defclass foo ...)
then FOO is a new type which isn't exactly "based on" any
existing type. But it will be a subtype of STANDARD-OBJECT.
On the other hand (given a bit of MOP) I can define new
types that aren't subtypes of STANDARD-OBJECT. They'll
still be subtypes of T, but if you think that's useful
then you should reconsider your opinion that Erik's
reply to you was a joke.
> > 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).
In a H-M-ish type system, it's easy to allow arbitrary-length
homogeneous lists (a list-of-X is either a special object
called the empty-list-of-X, or (cons x y) where x is an X
and y is a list-of-X; with a bit of hackery you can make
all the empty lists the same) and easy to allow fixed-length
inhomogeneous lists (usually called tuples); it's combining
the two that you can't do. When you say "like Java", are you
thinking of something like casting to and from "object"?
Because then you get all those nasty evil wrong-type errors
that you presumably went static to avoid. I suppose they're
better localized.
> > 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.
For me, that's a biggie.
> > Next: I have trouble imagining how CLOS is going to carry
> > on working.
>
> It won't. Next! ;-)
That's another biggie.
> > 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.
My feeling is that if you want static typing, there are
plenty of good places to find it already. Why build it
into Lisp? The main things that make Lisp better than,
say, Haskell or O'Caml are things I'd expect you to have
to give up -- or at least to weaken considerably -- in
a "statically typed Lisp". So: What would a "statically
typed Lisp" have that Haskell and O'Caml don't have?
> > 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.
Right. It's a joke. But it's a joke that makes an important
point. (This sort of thing is sometimes called "ha ha only
serious".)
> > 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? =)
If your only reason for doing it is "because I feel like it",
then all I can say is: go ahead and try it; see how it feels.
Rather you than me.
--
Gareth McCaughan
.sig under construc
* Gareth McCaughan
> Erik Naggum observed that you can *already* consider CL to be
> strongly, statically, implicitly typed, with everything having type T.
* sajiimori
| Still sounds like a joke.
To see its truth, one needs a level of mathematical sophistication
that I take for granted. Hence my disappointment when so many people
evidently lack it. I keep wondering how they manage to live in our
modern world, but they just do, and never wonder about it. Puzzling,
this is.
| Implementing such a type system requires exactly 0 lines of code.
Repeatedly jumping to conclusions is really not a good way to stay in
mental shape.
There is a difference between having 0 types and having 1 type that
you have managed to overlook somehow. I do not understand how this is
possible, but it appears that you have somehow managed to believe that
a system with a single static type is equivalent to not knowing the
type at all. Since this is rather incredulous to me, let me at least
try to explain this so that those who understand both you and me can
explain it to you.
Suppose we have a machine with /n/ native types each with their set of
operations (which is how this whole type thing began). Values of each
disjoint type may freely share binary representation; operations only
work on untyped bits and it is the programmer's responsibility to give
them the right values to operate on. The fundamental observation was
that while memory is untyped, the operations are typed and yield bad
results if given values that were expected to be of a different type
than they actually are, but the computer was utterly unable to report
any of this as a problem because by the time the operations got their
values, the binary representation was assumed to be that of the type
the operations had advertised that they required. The reason for the
compile-time type analysis is precisely that the execution of the
program has no idea whatsoever which of the many types that map onto
to the binary representation the actual value in memory is of, and the
kind of mistakes that were made in the past when programmers had to
keep track of this thing by hand was very expensive. So instead of
the programmer having to keep the proper type in mind, the compiler
would ensure that a binary representation of an object only had one
meaning, and they did this by making the memory have type, too, not
just the operations, however fleetingly in the compiler's view.
Suppose further that all the values you could possibly think of are
representable using those /n/ types. In this perfect world, there
would be no need for any run-time type dispatch or checking at all,
and every programmer would instantly revere the static type analysis.
Now suppose you want to add an additional type to your programs, one
which is not supported by the hardware operations. Because of the
nature of the computer, it will necessarily require a both a binary
representation that could be mistaken for some of the native types and
a set of operations that work on this binary representation that are
now defined by the programmer. If you insist on the hardware view of
your computer, you will now create a virtual or abstract type, and you
will inform your compiler of your construction. It will use the exact
same methods it used to keep binary representations of native types
from being confused or conflated, and you will never give any of your
new, virtual values to an operation that requires a native type, nor
mistake a native value for your new, virtual type. Meanwhile, in the
memory of the computer running your program, there will be a binary
representation of an object that does not correspond to any of the
machine's own types and whose meaning it is now even more impossible
for anyone who looks only at the memory to determine than if they were
native types.
Now suppose you add two varieties of an abstract type upon which a
number of operations exhibit no variation, but at least one does.
This situation is qualitatively different from the native types, for
the hardware uses disjoint types. The solution to this problem that
is not qualitatively different is to duplicate the functionality for
the two varieties and continue to keep them disjoint. However, as you
realize that they are interchangeable in some respects, you have to
add code to support the interchangeability. This way of implementing
abstract types is extremely artificial, however, and breaks completely
with the old way of doing things -- any sane programmer would conflate
the two varieties and consciously break the type disjointness. And
so the run-time type dispatch is born as the qualitatively different
solution.
Since the compiler is now instructed to treat two types as the same,
which they actually are not, the language or the programmer must add
the type-distinguishing information to the binary representation one
way or another and add operations that are usedly only to distinguish
types from eachother. Building a harness for this meta-information is
not the trivial job you think it is with your �0 lines of code�. In
fact, meta-information fundamentally contradicts the hardware view of
native values, for in the hardware view, a value exists only as the
input parameter of some computational operation. In order for the
meta-information paradigm to work, we now have to attach meaning to
the fact that two innocuous native values subtract to zero. We must
never regard these values we use for this purpose as numeric -- they
are only to be used for their equality with known values, or identity.
It is vitally important at this point to realize that the
type-distinguishing meta-information is not used to /check/
the types of arguments, but is used to /dispatch/ on them,
selecting the operation according to the type of the value.
Suppose we have built the type-dispatching harness for our abstract
types such that we can freely add more abstract types, organize them
into hierarchies of supertypes and subtypes, and share (or inherit)
operations and properties alike in a web of types. All functions that
advertise that they accept values of a particular type know that they
may also receive values of any of its subtypes and that even if they
do not distinguish them from eachother, one of the functions it calls
may. So functions that need to make special provisions for the types
of its arguments are /generic/ and perform the exact same abstract
operation on the abstract types, but different /concrete/ operations
according to the types of the values. For instance, all programming
languages make the basic arithmetic operations generic over the whole
spectrum of numeric types supported by the hardware, usually all the
additional numeric types defined by the language and sometimes also
the user-defined numeric types. If we retain the type-checking of the
compiler that we built for the native types to keep from confusing
them, such as catching the obvious misuse of generic functions that
only work on any of the various types of numbers, but not on any other
supertypes, we now face both compile-time type checking and run-time
type dispatch. The compile-time restrictions on correct programs may
very well reduce the amount of run-time dispatching, but all functions
that /could/ accept any of the abstract types must be prepared to do
type dispatching.
(Of course, one way to cheat in this process is to optimize away the
type dispatching of a generic function and let the compiler call the
type-specific function directly if it can determine the types to a
useful degree at compile-time. However, the mechanics of cheating
tend to cloud the more central issues, so I just want to mention that
it is often more natural to cheat than to do the right thing, which in
no way reduces the responsibility to know what the right thing is.)
Now, since we have built this meta-information and type-dispatching
harness and forced every function in the entire programming language
into it, we face an engineering decision to retain the hardware-native
types or to regard them as a special case of the general concept. We
also face a theoretical decision, even a philosophical one, in that we
have to ask ourselves if there actually can exist disjoint types in
the real world, or if disjointness is an artifice of the hardware that
it is clearly easier to implement than one which wastes resources to
check the types of its arguments. The division of labor that is so
evidently very intelligent in the design of hardware and software, is
neither evident nor intelligent in the design of programming languages
that are intended more for humans than for machines.
If we make the philosophical leap from hardware values to values that
reflect the human view of the world, we immediately observe that there
can be no such thing as disjoint types in reality -- disjointness of
types is an artifice of our own desires and our own limitations in
approaching the mass of information that is the real world observed by
our brains. Any categorization serves a purpose, and while it takes a
genius most of the time to re-categorize for a different purpose, we
must be aware of the purpose to which our categorization was designed
if we are to avoid the extremely difficult problem of working at cross
purposes with our conceptualization of the world we work in and on.
Being exceedingly intelligent and remarkably introspective, we look at
our type systems and realize that there must exist a supertype of all
types such that what appears to be disjointness is only disjointness
for a particular purpose, and we realize intuitively that if there can
be supertypes of all types, there must be subtypes of all types, and
we invent the conceptual null type of which there are no values, but
which is a subtype of all types, if for nothing else, then for the
sake of mathematical completeness. Disjointness is now in the eyes of
the beholder, only, and any beholder is free to partition the value
space into any categories that fit his purpose. Our categorization is
now not free of purpose -- it will always continue to have /some/ --
but it is now possible for the programmer to partition the entire set
of machine-representable values into his own types any way he likes.
Common Lisp is not quite as abstract, but very close. In Common Lisp,
we observe that there is a supertype of all types, T, on which there
are no useful operations, but which means that every function that has
not advertised to the compiler that it only accepts a subset of the
type space, must be prepared to perform type dispatch to weed out the
types for which there exist no useful operation. This process is
evidenced in the construction of operations that branch out over the
type space, incidentally. COND, CASE, etc, all accept T as the final
branch, T being that which is always true, the supertype of all types,
etc. I delight in this mathematical elegance.
This way of thinking necessarily differs from the artificial, disjoint
thinking. We regard the generic operations we define as having well-
defined semantics for a subset of the available types, so if they are
invoked on values of any other types, we expect that this condition is
handled exceptionally. If we define operations that can only, ever,
accept values of an a priori set of types, we communicate this to the
compiler and expect it to help us avoid mistakes, but in general, we
regard the categorization that we employ to model and understand the
world we program in and for, as a posteriori, and we do not make the
common mistake of believing that what we already know is all that we
can possibly know. As a consequence, it is a design mistake in Common
Lisp to write functions that expect only very specific types to the
exclusion of other natural types and values.
To illustrate just how type-flexible Common Lisp is, the standard has
the concept of a designator for a type. Most Common Lisp functions
that take only string arguments are not defined merely on strings, but
on designators for strings, which means that they can be called with a
character which is a designator for a strong of length 1, or a symbol
which is a designator for the string that is its name. Whereas most
programming languages have rich libraries of string functions, Common
Lisp defines a rich library of functions that work on sequences of any
kind: lists, vectors, strings. A language in the disjoint tradition
may provide one function to search for a character in a string, one
function to search for substrings in strings, and another to search a
vector of characters for a character. Common Lisp defines the generic
function SEARCH which accepts sequences of any type and returns the
position of the match. This genericity is so common in Common Lisp
that the traditional meaning is regarded as ubiquitous and therefore
not in need of special mention. Instead, �generic function� is a new
kind of function which allows programmer-defined methods to be defined
on particular programmer-defined classes of arguments, but this should
not be interpreted to mean that normal Common Lisp functions are not
just as generic in the traditional sense.
A request for more static type checking in Common Lisp is regarded as
a throw-back to the times before we realized that disjointness is in
the eye of the beholder, or as a missing realization that disjointness
does not exist in the real world and therefore should not exist in the
virtual world we create with our software. Just because computers are
designed a particular way that makes certain types of values much more
efficient to compute with than others, does not mean that efficiency
is /qualitative/. Efficiency is only quantitative and subordinate to
correctness. It is a very serious error in the Common Lisp world to
write a function that returns the wrong result quickly, but does not
know that it was the wrong result. For this reason, type correctness
is considered to be the responsibility of the function that makes the
requirements, not of the caller or the compiler. If the programmer
who makes those requirements is sufficiently communicative, however,
the compiler should come to his assistance. The default behavior, on
the other hand, is that functions have to accept values of type T.
I trust that by now, you realize that your saying �Implementing such a
type system requires exactly 0 lines of code.� is evidence of a level
of ignorance that can only be cured by study and willingness to listen
to those who do not suffer from it, but if left uncured will lead to
numerous misguided if not completely wrong conclusions. If you really
want to understand instead of just telling us what you believe before
you understand what we already do, you will appreciate that there was
something you had not understood that adversely affected your ability
to have and express opinions that those who had understood it would be
willing to entertain. Ignorance can be cured, however, and everyone
who has once been ignorant knows that it is but a temporary condition,
but stupidity is not curable, because stupidity is evidence of the
more or less conscious decision to remain ignorant when faced with an
opportunity to learn. Your dismissal of all arguments from authority
sounded alarmingly stupid at the time, but you may yet decide that you
benefit from listening to people who understand more than you do.
--
Erik Naggum | Oslo, Norway 2004-028
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
From: Joe Marshall
Subject: Re: Static/Strong/Implicit Typing
Date:
Message-ID: <n087j4r4.fsf@comcast.net>
Erik Naggum <····@naggum.no> writes:
> Common Lisp is not quite as abstract, but very close. In Common Lisp,
> we observe that there is a supertype of all types, T, on which there
> are no useful operations,
You have overlooked EQ (and TYPE-OF). Intensional equality is
extremely important in common Lisp and it has always amazed me that it
is often omitted from statically typed languages.
I'd also argue that functions like PRINT are defined over type T, but
you could argue that they are a function composed of the union of the
specific type printers.
--
~jrm
* Joe Marshall
| You have overlooked EQ (and TYPE-OF).
No, I have not overlooked something just because you think of it.
I would much prefer if you accepted responsibility for your own
contributions instead of blaming me for not contributing them.
Had I claimed to be omniscient, your statement would have served a
much-needed purpose. I claim no such thing, however.
--
Erik Naggum | Oslo, Norway 2004-028
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
* Joe Marshall
| You have overlooked EQ (and TYPE-OF).
No, I have not overlooked something just because you think of it.
I would much prefer if you accepted responsibility for your own
contributions instead of blaming me for not contributing them.
Had I claimed to be omniscient, your statement would have served a
much-needed purpose. I claim no such thing, however.
--
Erik Naggum | Oslo, Norway 2004-028
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
From: Joe Marshall
Subject: Re: Static/Strong/Implicit Typing
Date:
Message-ID: <isiviyo6.fsf@comcast.net>
Erik Naggum <····@naggum.no> writes:
> I would much prefer if you accepted responsibility for your own
> contributions instead of blaming me for not contributing them.
I apologize. No slight was intended.
--
~jrm
From: Joe Marshall
Subject: Re: Static/Strong/Implicit Typing
Date:
Message-ID: <r7xjj4zu.fsf@comcast.net>
"sajiimori" <··········@hotmail.com> writes:
>> 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.
There is an important, but very subtle difference.
A type system involves setting up abstraction barriers between clients
of the type and the implementation of the type. The implementation
builds the abstract object from concrete objects with more basic
types. At some point, you have the primitive types supplied by the OS
or the hardware. These are usually binary words of a certain size.
At this very lowest level, Lispers and static typers diverge in a very
fundamental way, and I think this is what leads to the disagreements.
Static typers see the `raw seething bits' as the primitive object out
of which to create the basic abstractions of integers, floats,
strings, characters, etc. These underlying raw seething bits are
completely indistinguishable from each other: the bits that make up a
string look just like the bits that make up a integer. There is an
obvious solution here: everyone must agree beforehand on what set of
bits will be used for what purpose.
Static typers expect the OS to provide a single, uniform element out of
which everything can be created.
Lispers, however, take a radically different approach. We do not take
for granted that the fundamental primitive objects are those that OS
and hardware provide. We believe that the OS and hardware should
provide a *much* richer set of primitive objects than simple `raw
seething bits'. Frankly, raw seething bits is an abstraction on what
is really provided: a bunch of circuitry. If we can abstract out the
wires, we can abstract out the bits.
Lispers expect the OS to provide a huge periodic table of elements ---
numbers, strings, vectors, structures, symbols, etc. --- as the base
primitives out of which other types can be created.
Now the source of the disagreements can be seen: we're talking about
different things. For a Lisper, the function TYPE-OF is a useful
means of determining what element an object is made of. For a static
typer, such an operation would be useless: it's made of
bits.... everything is made of bits. And of course, since everyone
has to agree beforehand what the bits mean, a `type-of' function that
returned the abstract type would be just as useless.
For a static typer, it is *crucial* that no program anywhere
misunderstands the meaning of the raw bits. If a floating point
number were interpreted as an integer, the answer would be wildly
incorrect.
For a Lisper, however, misinterpreting a floating point number as an
integer is as easy to do as mistaking carbon for oxygen.
Now as we move to higher abstractions, static typers use their
universal agreement enforcer to distinguish between objects with the
same lower-level abstractions. The concrete number 12 will be
abstractly 12 feet or 12 dollars and the entire program will agree on
which 12 means which.
Lispers, on the other hand, are *often* lazy enough to not bother
creating `molecules' out of their elements. If a program deals with
social-security numbers and names, there is hardly a need to build an
abstraction barrier to prevent the two from being confused: a number
is a number and a string is a string and you really cannot confuse the
two.
Static typers wonder, though, how a Lisper would deal with 12 feet
vs. 12 dollars if they are both numbers. Well, not all of us are
completely lazy or idiotic: if there is potential for confusion it is
easy to wrap up the number in a more disciplined abstraction, perhaps
as a struct or a class.
Now as Erik pointed out, you can *already* consider CL to be strongly,
statically, implicitly typed, with everything having type T.
Far from being a no-op, this puts severe constraints on a static
typing system. If there exists anywhere in the system a place where
the `raw seething bits' have more than one interpretation (and for
something of type T, they could have *any* interpretation), then the
universal agreement enforcer has *much* more work to do to ensure that
no one misinterpret the bits.
--
~jrm