Why typing?
Yonghao Chen
I am wondering why we really need typing in programming languages. I know
that typing information is beneficial for compiling, for example, error
checking. And there are some languages, such as Lisp, which are non typing or
weak typing. Besides these, are there any benefits?
Thanks for any response.
Kelly Hall
Yonghao> Hi, All: I am wondering why we really need typing in
Yonghao> programming languages. I know that typing information is
Yonghao> beneficial for compiling, for example, error
Yonghao> checking. And there are some languages, such as Lisp,
Yonghao> which are non typing or weak typing. Besides these, are
Yonghao> there any benefits?
Types also provide a partial specification of correctness. It's
generally blatantly wrong to try to index an array with a real number.
You usually want to specify a lot more about your code than just type
correctness, but it provides a useful *machine checkable* starting
location.
BTW, lisp usually has dynamic typing, not 'non typing'. Calling '+'
with two lists will indeed generate an error at runtime.
Kelly
--
Kelly Hall <ha...@lal.cs.byu.edu>
http://lal.cs.byu.edu/people/hall.html
(Bird Lives)
Dr. Richard Botting
: Hi, All:
: I am wondering why we really need typing in programming languages. I know
: that typing information is beneficial for compiling, for example, error
: checking. And there are some languages, such as Lisp, which are non typing or
: weak typing. Besides these, are there any benefits?
A fairly common question?
Consider the following facts. There exist languages that have
no types(LISP), weak typing(K&R C), strong typing(Pascally,Ada), automatic
dynamic typing(APL,BASIC)
Most language have evolved towards the strongest form of typing. For
example: CPL->BCPL->B->C->ANSI C->C++
Also the classic languages of FORTRAN and COBOL have very tight
typing systems.
It seems there are benefits therefore...
My favorite is that I don't have to have a different symbol for
adding integers, rationals, reals, etc. The type of the operands
selects the operation for me: 1+2, 1+1.5,...
--
di...@csci.csusb.edu=rbot...@wiley.csusb.edu.
Find out what's new at http://www.csci.csusb.edu/doc/www.sites.html
Disclaimer:`CSUSB may or may not agree with this message`.
Copyright(1995):Copy this freely but include the following link to the
<a href="http://www.csci.csusb.edu/dick/signature.html">author's signature</a>
Stefan Monnier
] I am wondering why we really need typing in programming languages. I know
] that typing information is beneficial for compiling, for example, error
] checking. And there are some languages, such as Lisp, which are non typing or
] weak typing. Besides these, are there any benefits?
Go read the amazing paper from Cardelli/Wegner in ...
it must be a issue of Computing Surveys, probably in 1984. I can't remember the
title, but it's a *must* if you have the slightest interest about types.
Stefan
Peter Hermann
: I am wondering why we really need typing in programming languages. I know
: that typing information is beneficial for compiling, for example, error
: checking. And there are some languages, such as Lisp, which are non typing or
: weak typing. Besides these, are there any benefits?
strong typing like e.g. in Ada is extremely beneficial for
a consistent abstraction of your problem (e.g. physical,
commercial, etc.). You wont like to add apples and oranges,
do you? The benefit pays off in a drastic(!) reduction of
programming errors. With strong typing you are even able to
introduce dimensioning of types. examples:
inch, centimeter cannot be added. Dollars and D-Mark etc. etc.
Mechanisms can be implemented with the features of a strongly
typed language, which
inhibit the multiplication of
kilometer*kilometer giving kilometer
but instead allow (only)
kilometer*kilometer giving squarekilometer
Mechanisms of that kind enforce your abstraction
for the sake of preventing lots of programming errors.
recommendation: Cardelli and Wegner "On abstraction,types,etc."
--
Peter Hermann Tel:+49-711-685-3611 Fax:3758 p...@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)
Dan Putnam
Cardelli and Wegner, so I went out and located it.
If anybody else is interested:
Luca Cardelli and Peter Wegner. On understanding types, data
abstraction, and polymorphism. Computing Surveys, 17(4):471-522, 1985.
Linkname: Papers
URL:
http://www.research.digital.com/SRC/personal/Luca_Cardelli/Papers.html
Marty Hall
ucaa...@iris2.csv.ica.uni-stuttgart.de (Peter Hermann) writes:
>
>strong typing like e.g. in Ada is extremely beneficial [...]
Note however, that if you have strong typing but no type variables
there are certain types of constructs that cannot be expressed.
For instance, First-of-List, which takes a list of Foo objects and
returns a Foo object, where Foo can be any type. Or the Identity
function which returns its argument unchanged. Or a generalized Sort
routine which takes a vector/list of Foo objects and a predicate
(which takes 2 Foos as input and returns a Boolean) and sorts the
vector/list based on the function. All of these examples are
completely type-safe, in that they can be used in a language that
guarantees to not have type errors at runtime. But you need type
variables. I think, however, that templates ala C++ can capture many
of the cases.
- Marty
(proclaim '(inline skates))
Konstantin Popow
: Go read the amazing paper from Cardelli/Wegner in ...
: it must be a issue of Computing Surveys, probably in 1984. I can't remember the
: title, but it's a *must* if you have the slightest interest about types.
@article{CW85,
x-key = {Cardelli},
author = {Luca Cardelli and Peter Wegner},
title = {On Understanding Types, Data abstraction, and
Polymorphism},
journal = {ACM Computing Surveys},
month = dec,
year = {1985},
volume = {17},
number = {4},
pages = {471--522}
}
--- Kostja.
--
--------------------------------------------------------------------------
Konstantin Popov DFKI (German Research Center for AI)
phone +49 (681) 302-5337, fax ...-5341 EMail: po...@dfki.uni-sb.de
Patrick D. Logan
>Consider the following facts. There exist languages that have
>no types(LISP)...
The usual misleading bull, er, baloney.
--
mailto:Patrick...@ccm.jf.intel.com
(503) 264-9309, FAX: (503) 264-3375
"Poor design is a major culprit in the software crisis...
..Beyond the tenets of structured programming, few accepted...
standards stipulate what software systems should be like [in] detail..."
-IEEE Computer, August 1995, Bruce W. Weide
Matthias Blume
[Peter Hermann]
| The benefit pays off in a drastic(!) reduction of programming errors.
the value is in early detection of programming errors, ideally causing a
reduction of programming errors in the running code, but this is not
necessarily the case as even those "errors" that there is no value in
detecting are detected, and "correcting" them only adds unnecessary
complexity to the program.
When I still was a Scheme addict I used to believe in this, too. But
after programming extensively in SML I now have to say that this is
not true at all. Early _complete_ error checking leads (at least for
me) to a huge decrease in development time.
further, as the number of types increases (as it is wont to do when users
are encouraged to create their own types) and the interactions between
types increase (as it is wont to do as users need to involve the type
system in all the semantics that previously were implicit in less specific
types), the ability of even very intelligent and highly experienced
programmers to keep track of them and obtain the desired result in the
presence of overloaded operators is decreasing dramatically.
This is a lot of hoopla here. I agree that lots of types with lots of
overloaded operators are a bad idea. That's why I do not favor
overloading. I could live without any overloading, but I know many
disagree with me here. However, having lots of types doesn't require
the programmer to mentally keep track of all of them provided that the
compiler and the type system do. I found it very convenient to make
extensive changes to SML programs, and I usually try to make sure that
such changes are reflected in changes to some types, because the
compiler will then very reliably tell me which parts of the program I
have missed in the course of keeping everything consistent. Abstact
types are the best for this purpose.
if you create types that are too narrow, you will
seriously limit the usefulness of the type system, _and_ create a
complexity from which you will find yourself wanting, but unable, to
escape. that's why less restrictive type systems win.
Yes and no. Less restrictive as in `no restriction at all' loses big
time. Less restrictive as in `polymorphic, while still strong and
safe' can win.
essentially, it is the a priori aspect of strongly typed systems that is
fundamentally unsuited to the process of acquiring the knowledge of the
types necessary to implement them and relate them correctly.
I don't know where you get the strong conviction that let's you
express your views with such emphasis. I have come a long way to
believe the opposite (starting about where you are now). In my
experience experimenting with programs in SML with its strong type
system turns out to be quite pleasant. And I found it to be true that
designing the right datatypes is the main task, once you have that you
get a lot of help from the compiler to fill in the rest.
--
-Matthias
Jeffrey Mark Siskind
Consider the following facts. There exist languages that have
no types(LISP), weak typing(K&R C), strong typing(Pascally,Ada), automatic
dynamic typing(APL,BASIC)
Most language have evolved towards the strongest form of typing. For
example: CPL->BCPL->B->C->ANSI C->C++
Also the classic languages of FORTRAN and COBOL have very tight
typing systems.
It seems there are benefits therefore...
My favorite is that I don't have to have a different symbol for
adding integers, rationals, reals, etc. The type of the operands
selects the operation for me: 1+2, 1+1.5,...
You are confused. Overloading or ad hoc polymorphism is orthogonal to whether
a language has manually declared types which is in turn orthogonal to whether
a language has implicit union types which is in turn orthogonal to whether or
not an implementation soundly checks types which is in turn orthogonal to
whether such type checking is done at compile-time or run-time. Most of this
space of orthogonal design criteria are actually populated by existing
implementations of existing languages. For example, *none* of the languages
that you mention above (Lisp, C, Pascal, Ada, APL, or Basic) require a
different symbol for addition of different types of numbers despite the
variety of design decisions along other axes.
Jeff (home page http://www.cs.toronto.edu/~qobi)
--
Jeff (home page http://www.cs.toronto.edu/~qobi)
John Kent
> Consider the following facts. There exist languages that have
^^^^^
> no types(LISP), weak typing(K&R C), strong typing(Pascally,Ada), automatic
> dynamic typing(APL,BASIC)
>
Sorry to rant on about a subject that has been raised here before,
but Lisp *DOES* have types !!!!
It differs from C++ etc in that it types the data items themselves,
rather than the variables that contain them (except when instructed to
do so for efficiency reasons). Lisp performs automatic run time
type-checking and also provides mechanisms (e.g. typecase) that
let a programmer determine the type of an object (such as an integer)
at run-time, and then perform type dependent behaviour as a result.
This is all in addition to the polymorphism associated with generic
functions (Common Lisp's answer to C++ virtual functions).
See "Common Lisp: The Language" by Guy Steele for a slightly more
detailed description of the type mechanism.
Run-time typing was one reason why Lisp machines such as the
Symbolics became popular - they added hidden tag bits to data
structures so that some type-related operations could be directly
supported by hardware, and therefore made very fast.
--
John Kent, Email: jk...@hi-q.demon.co.uk
Hi-Q Systems Limited, Tel : +44 (0)1252-815035
Hi-Q House, Ancells Court, Fax : +44 (0)1252-815022
Fleet, Hants GU13 8UZ UK These opinions are mine & not Hi-Q's
Erik Naggum
| The benefit pays off in a drastic(!) reduction of programming errors.
the value is in early detection of programming errors, ideally causing a
reduction of programming errors in the running code, but this is not
necessarily the case as even those "errors" that there is no value in
detecting are detected, and "correcting" them only adds unnecessary
complexity to the program.
further, as the number of types increases (as it is wont to do when users
are encouraged to create their own types) and the interactions between
types increase (as it is wont to do as users need to involve the type
system in all the semantics that previously were implicit in less specific
types), the ability of even very intelligent and highly experienced
programmers to keep track of them and obtain the desired result in the
presence of overloaded operators is decreasing dramatically.
| With strong typing you are even able to introduce dimensioning
| of types. examples: inch, centimeter cannot be added.
they should be, and the result should be convertible to any unit of length.
be careful not to make your type system too narrow, or you run into the
problems outlined above. if you have created a type system where "inch"
and "cm" are incommensurate types, you will have to write functions to add
functions of _some_ incommensurate types, but not others, i.e., manual work
to add such functions. if you instead had a type for length, and it knew
the original unit in addition to the value in terms of the least common
denominator, you could add inches and centimeters, but you would have to
request a particular unit before the result could be displayed.
| Dollars and D-Mark etc. etc.
but that is incredibly useful! you would of course need to know the date
associated with a currency amount, with function that returned exchange
rates for a given date, so you could add them and obtain a meaningful
value. also needed: future and indefinite dates with the ability to fix a
date (exchange rate) later. in fact, you need dates in any currency type
whether you deal with multiple currencies or not. in the presence of
inflation and interest, the value of a currency is time-dependent.
see the pattern? if you create types that are too narrow, you will
seriously limit the usefulness of the type system, _and_ create a
complexity from which you will find yourself wanting, but unable, to
escape. that's why less restrictive type systems win.
| Mechanisms can be implemented with the features of a strongly typed
| language, which inhibit the multiplication of kilometer*kilometer
| giving kilometer but instead allow (only) kilometer*kilometer giving
| squarekilometer Mechanisms of that kind enforce your abstraction for
| the sake of preventing lots of programming errors.
seems that you need a "unit" system, not separate types. may I suggest a
look at the HP 48 implementation of calculating with units? they have done
it right. it is unfortunately very complex to get it right.
this leads me to my second argument against strong typing. getting a type
system right requires so much detailed specification that the cost is so
high that mistakes are actively discouraged. this cost is not necessarily
offset by the benefits of using such types, especially not if the program
needs to adapt its speficiation to changing needs discovered only as the
program is being used in preliminary forms (often called "prototypes", but
I'm not sure building a prototype only to discard it and build "the real
thing" is a good idea. it seems the projects that go into a state of
completion such that they are no longer learning from the experience of use
are extremely rare. projects that no longer _can_ learn from the experience
of use is, however, quite common.
the cost of mistakes in type systems is often caused by poorly understood
or outright misunderstood relations between types.
my conclusion is that less strongly typed (i.e., dynamically typed) systems
are the ultimate type systems, because they allow growth and change, while
preserving the ability to use machine reasoning about types. strict type
systems, where every "object" is a type, do not scale well because the
computer is not involved in the typing decisions, only in checking them.
still, some of the lessons of "object-oriented" programming in the Algol
family can be fruitfully employed in dynamically typed systems. CLOS and
Dylan are both embracing the "inclusive object" where methods are added as
needed, instead of the "exclusive object" where methods must be known a
priori.
essentially, it is the a priori aspect of strongly typed systems that is
fundamentally unsuited to the process of acquiring the knowledge of the
types necessary to implement them and relate them correctly.
#<Erik 3020685778>
--
there's a car that has more computing power than it took to get man
to the moon: the BMW 750. but _you_ are stuck here on earth. haha.
Patrick D. Logan
>] And there are some languages, such as Lisp, which are non typing or
>] weak typing.
Bzzzzt. Wrong!
Next contestant, please...
Shriram Krishnamurthi
> Consider the following facts. There exist languages that have no
> types(LISP), weak typing(K&R C), strong typing(Pascally,Ada),
> automatic dynamic typing(APL,BASIC)
*Please*, let's get this RIGHT. The Lisp family of languages is *not*
devoid of types. In an untyped language, I would expect that an
operation such as
(+ 1 "foo")
(where + denotes addition, 1 is a number, and "foo" is a string, which
we assume is illegal for adding to) would proceed without pause. In
Lisp, however, this statement will produce an error. (The very fact
that I was able to say that 1 is a number and so forth immediately
suggests the presence of a typing system, does it not?)
There are, of course, differences between Lisp and a language like
Pascal. First of all, Pascal will flag this at compile-time, while
Lisp will only do so at run-time. (More on this below.) Second, in a
language like Lisp, the types are associated with values, not with
identifiers; the programmer must explicitly enforce any association of
the latter sort that he desires. Finally, of course, the set of
values (and hence of types) of the Lisp family is typically far richer
than that of a language like Pascal.
Note that there is no reason why types cannot be inferred for a Lisp
program (eg, Andrew Wright's SoftScheme). Of course, due to inherent
uncomputability reasons, such a system cannot determine the *exact*
set of types that will flow through an identifier. However, it can
provide a conservative approximation; and one could prevent any
program wherein there is some doubt about the correctness of types
from being executed. All this is possible, has been done, and is a
fertile research area. Traditionally, however, Lisp systems do not
provide such checking, and do not reject programs. There is no reason
a Lisp program cannot be treated in this manner, though.
Of course, in the opinion of some, the different "types" in a language
like Scheme are really variants of a single datatype: what an ML
person might write as
datatype theSchemeType =
Num of int
| String of string
| ...
in which case these should appropriately be called "variant errors",
not type errors. But this only further enforces the notion that the
Lisp family *is* typed.
So much for that "fact".
(It amazes me that a response about "types" mentions only one
programming language not developed before the eighties, and that one
being Ada.)
[Rest of message gently elided.]
'shriram
Phillip J. Windley
Go read the amazing paper from Cardelli/Wegner in ...
it must be a issue of Computing Surveys, probably in 1984. I can't remember
title, but it's a *must* if you have the slightest interest about types.
<URL: http://lal.cs.byu.edu/cs330/sources/cardelli-wagner.ps>
--
__________________________________________________________________________
Phillip J. Windley, Asst. Professor | win...@cs.byu.edu
Laboratory for Applied Logic | VOX: 801.378.3722
Brigham Young University | FAX: 801.378.7775
http://lal.cs.byu.edu/people/windley/windley.html |
Joseph H. Fasel
>>In article <43pl5a$f...@msunews.cl.msu.edu>, Yonghao Chen <chenyong> wrote:
>
>>] And there are some languages, such as Lisp, which are non typing or
>>] weak typing.
>
> Bzzzzt. Wrong!
>
> Next contestant, please...
>
>--
>mailto:Patrick...@ccm.jf.intel.com
>(503) 264-9309, FAX: (503) 264-3375
I'm sure you're aware that this is a perennial subject of contention.
There are those of us who maintain that "dynamic type" is an oxymoron.
The main problem with such a notion is that there is little, if any,
distinction between a type and a general predicate. I suppose you might
say that types are _total_ predicates, and this distinction might be
marginally useful for a language like Lisp, but I think it begins to
fall down for nonstrict languages.
This is not a value judgement, mind you. There are weird and wonderful
things you can do in Lisp or in the untyped lambda calculus, but I would
say that describing Lisp as "dynamically typed", rather than "untyped",
doesn't really say much.
--Joe
Joseph H. Fasel email: j...@lanl.gov
Computer Research and Applications phone: +1 505 667 7158
University of California fax: +1 505 667 1126 or 665 5220
Los Alamos National Laboratory postal: CIC-3 MS B256; Los Alamos, NM 87545
Marty Hall
bl...@atomic.cs.princeton.edu (Matthias Blume) writes:
[...]
>When I still was a Scheme addict I used to believe in this, too. But
>after programming extensively in SML I now have to say that this is
>not true at all. Early _complete_ error checking leads (at least for
>me) to a huge decrease in development time.
I have been and continue to do a majority of my professional
development work in Lisp (the remainder in C), and like the dynamic
typing aspect. But for those who haven't tried SML, it really is worth
looking at. I have considered the strongly typed aspect of other
strongly typed languages a pain, but SML has
(A) A very smart type inferencing system, so declarations are
surprisingly minimal.
(B) A very powerful type system (unlike other strongly typed languages
I've seen) so that the strong typing seems like much less of a
restriction once you get used to it.
When I first used it I thought the strong typing would get in the way
and was very pleasantly surprised. And unlike C++, you *really* cannot
have type errors at runtime.
I still prefer Lisp personally (for other reasons :-), but SML
convinced me that my "strong typing is never worth it" attitude was
wrong.
Shriram Krishnamurthi
> There are those of us who maintain that "dynamic type" is an oxymoron.
> The main problem with such a notion is that there is little, if any,
> distinction between a type and a general predicate.
Right. However, there are those of us who, in turn, view this as
being a benefit. I think there are two levels at which the typing of
a Lisp-like language should be viewed at: for safe execution and for
information extraction.
Safe execution here refers to the explicit or implicit tagging of
values and (implicit or explicit) checking of those tags before the
execution of primitives and at procedure application. For this, the
"type system" of Lisp, proper, works just fine (especially in the
explicit cases).
For information extraction, of course, this "type system" doesn't come
in very handy, at least not without the imposition of another system
of the conventional kind. This enables me to answer questions like,
"what is the type of this variable?". Hindley-Milner variants are
often used for this purpose, as you well know.
However, there is a flexible realm that lies betwixt these views,
which is covered by systems like set-based analysis (SBA), wherein I
answer the slightly different question, "what is the set of values
this variable takes on?", or, "what are the types of the values this
variable takes on?". In addition to technical considerations (such as
its flow-oriented nature), SBA might also be more appropriate for a
Lisp programmer since it provides "types" of the kind he is used to
reasoning to. Put differently, when I write
fun map f [] = []
| map f (a::d) = (f a) :: (map f d)
my mind automatically focuses in on its polymorphic nature; however,
when I write
(define map
(lamba (f)
(lambda (l)
(if (null? l)
'()
(cons (f (car l)) ((map f) (cdr l)))))))
I tend to think of the kinds of things I might be passing into map:
making sure they're all proper lists, or something of that sort. It
is, I concede, a perverse difference, and undoubtedly one brought on
by training and experience. Still, there it is.
'shriram
Erik Naggum
| When I still was a Scheme addict I used to believe in this, too. But
| after programming extensively in SML I now have to say that this is not
| true at all. Early _complete_ error checking leads (at least for me)
| to a huge decrease in development time.
I have to modify my previous comment. I was mainly addressing "manual
strong typing" (à la C++), which I still think is horribly inefficient in
terms of programmer time, has been oversold many times over, and is
unlikely to yield any actual benefits when all costs are tallied. the
"inferred strong typing" of SML, where the strong typing is not specified
by the programmer, therefore yielding the benefits previouly restricted to
dynamically typed languages (some compilers of which also do a healthy
amount of type inference), while relieving the programmer of the tedium of
spelling out things that will, of necessity, have to be changed later.
although I have been (lightly) exposed to SML, I must admit to considering
it as being in a wholly different ballpark. maybe that's wrong, but as
long as (cop-out alert!) the common understanding of strong typing is that
of "manual strong typing", the only difference I (think I) have to make is
to qualify my comments as applying to the "manual" aspect of strong typing.
| I don't know where you get the strong conviction that let's you express
| your views with such emphasis.
simple answer: by not differentiating "strong typing" from "lots of typing".
(sorry.)
#<Erik 3020898016>
--
computers -- the only field where knowing the past
will make you less able to appreciate the present.
Shriram Krishnamurthi
> (A) A very smart type inferencing system, so declarations are
> surprisingly minimal.
The problem is not what happens when the type checker accepts your
program, but rather when it doesn't. The issue is not that it will
reject some correct programs; I know it will, and accept than when I
use SML. Rather, I often find the Hindley-Milner algorithm
unintuitive in its type judgements. In particular, reverse flow
problems can make some type errors fairly hard to understand.
> And unlike C++, you *really* cannot have type errors at runtime.
No, but you can have variant errors.
'shriram
Fernando Martinez
advantages of ADA and LISP together. With classes you have the advantages of (
abstract data types ) ADT but joined with a non typed lenguage. If the
operator '+' give an error betwend two lists, I do a method '+' in the class
list to make the need operation. Is right that a typed lenguage have better
performance ( but it depends of the aplication ), but in a object oriented
lenguage with late binding you don't need typing at all.
--
---
Fernando Martinez E-mail: Fern...@celeborn.satlink.net
Buenos Aires - Argentina
Dr. Richard Botting
: >Consider the following facts. There exist languages that have
: >no types(LISP), ...
: Hmmmmm..... I suppose (type-of ...) returns none?
This gives me a chance to correct my error, after a few hot messages from
people who thought I was attacking LISP. As I understand it it went like
this
Theoretical LISP -> LISP 1.5 -> Many LISPS -> Common LISP -> etc.
The theoretical LISP gained a lot of power by making everything a 'list'
and distinguishing three kinds (types???) of list: atoms, pairs, NUL.
(This was one reason I and other liked it so much at the time).
At that time "The Theory of Types" was a lot more philosophical than
it became round about Algol 68.
Later LISPs distinguished different types of atoms: numeric, string,...
giving a dynamic typing system.
I will not risk saying anything about developments since then.
Key point: Again the type system evolved as the language developed.
: >Most language have evolved towards the strongest form of typing. For
: >example: CPL->BCPL->B->C->ANSI C->C++
: >
: >It seems there are benefits therefore...
: CPL->BCPL->B->C->ANSI C->C++ ... ->ANSI Common Lisp?
Nice idea, but, I can't see
for(...){....} evolving easily into (for .....).
The syntax, semantic, and philosphical differences mean that at they can't
mutate into each other. Perhaps one may die out, perhaps not. Perhaps
a hibrid?
Whatever... may the best approach win.
Stefan Monnier
R.S. Nikhil <nik...@mattapoisett.crl.dec.com> wrote:
] (define (x-coord pt) (car pt))
As far as I can see, this is just a function taking a list of integers.
] [Some may claim that my X-COORD reflects bad style: that I should have used an
] explicitly tagged data structure for points and checked the tag in X-COORD.
] Fine; I can, and do, write such type-safe programs in Lisp, and so can I, in C
] and assembler; but the LANGUAGE isn't type-safe.]
Sorry, but it's not just bad style. How do you want your compiler to check that
you passed a point to your function since points are just represented by a list
of integers. If you create a POINT type (with defstruct for instance), then you
give enough information to expect the compiler to check things corectly.
As far as I'm concerned, SML is type-safe. But defining
fun xcoord x::tail = x
Will just as well make a function taking a list of integers
and returning an integer.
And in any case, Lisp *is* type-safe whereas C++ isn't.
Stefan
Stefan Monnier
Shriram Krishnamurthi <shr...@europa.cs.rice.edu> wrote:
] The problem is not what happens when the type checker accepts your
] program, but rather when it doesn't. The issue is not that it will
] reject some correct programs; I know it will, and accept than when I
] use SML. Rather, I often find the Hindley-Milner algorithm
] unintuitive in its type judgements. In particular, reverse flow
] problems can make some type errors fairly hard to understand.
This is a serious problem and some research has been done that tries to keep
track of where which choices have been made so that when an error is detected,
the compiler can tell the user where he got some type from. I don't know how
well this works, tho.
] > And unlike C++, you *really* cannot have type errors at runtime.
] No, but you can have variant errors.
But the compiler can (and usually does) warn you of every place where you didn't
handle all the variants. And refinement types can even help you prove that some
variants cannot show up at some place. Admittedly, refinement-types are not part
of SML yet (and might very well never be), but it still shows that the way
SML is designed allows many more potential errors to be discovered at compile
time (as opposed to C which typically cannot warn you that a switch statement
doesn't deal with all cases)
Stefan
Jeff Dalton
>I'm sure you're aware that this is a perennial subject of contention.
>There are those of us who maintain that "dynamic type" is an oxymoron.
>The main problem with such a notion is that there is little, if any,
>distinction between a type and a general predicate. I suppose you might
>say that types are _total_ predicates, and this distinction might be
>marginally useful for a language like Lisp, but I think it begins to
>fall down for nonstrict languages.
>This is not a value judgement, mind you. There are weird and wonderful
>things you can do in Lisp or in the untyped lambda calculus, but I would
>say that describing Lisp as "dynamically typed", rather than "untyped",
>doesn't really say much.
I disagree.
1. You're doing too much violence to established usage. There's
more than one established notion ot types and of typing. This
needn't have much "cost" because and there's terminology for
identifying which notion(s) you're talking about. "Dynamic
typing", for example.
2. Saying "dynamically typed" rather than "untyped" says something
worth saying. There have been Lisps that were pretty much what I'd
call "untyped". For instance, you could take the car and cdr of
symbols and numbers. (I know this can be seen as not being about
types, but that's not the only worthwhile way to see it.) I think
calling Lisp "untyped" makes pretty much the same mistake as saying
"in Lisp, everything is a list".
-- jd
Jeff Dalton
>In article <BLUME.95S...@atomic.cs.princeton.edu>
>bl...@atomic.cs.princeton.edu (Matthias Blume) writes:
>[...]
>>When I still was a Scheme addict I used to believe in this, too. But
>>after programming extensively in SML I now have to say that this is
>>not true at all. Early _complete_ error checking leads (at least for
>>me) to a huge decrease in development time.
>I have been and continue to do a majority of my professional
>development work in Lisp (the remainder in C), and like the dynamic
>typing aspect. But for those who haven't tried SML, it really is worth
>looking at. I have considered the strongly typed aspect of other
>strongly typed languages a pain, but SML [...]
I agree that SML is a good language and that ML-style type
inference, and the power of the type system, make for a usaable
and flexible form of strong-typing.
However, I nonetheless find SML a pain to use. I don't think
it's the strong-typing _per se_, though I still find it too
restrictive. I hate having to write output routines (Lisp
typically provides enough automatically), pattern-matching
is often too "positional", ML's not object-oriented, it
doesn't have macros, the module system is in itself about
as complex as all of Scheme, ... -- stuff like that.
-- jeff
Erik Naggum
| Yes, in Lisp you cannot mis-apply a primitive but, for me, safety also
| implies never mis-applying user-defined functions. Without this
| guarantee, I'd be hard-pressed to concede that Lisp is a type-safe
| language.
this doesn't make sense.
| To take a specific example: if a point in space is represented as a
| pair of numbers, then the typical Lisp function that selects the
| x-coordinate:
|
| (define (x-coord pt) (car pt))
|
| will happily work with any list I give it, whereas in most statically
| typed languages, this mis-application is caught during type-checking.
sorry, you're seriously confused. first of all, the above code is Scheme,
not Lisp. second, if you use a primitive type to implement a higher-level
type and you don't tell the type system, you get exactly the same kind of
behavior in statically typed languages. the clue you missed is that you
have to tell the type system what you think. in the case of Common Lisp,
you use structures or classes, which become new types, which you can
properly declare. (it is not Lisp's fault that Scheme lacks structures and
classes. credit where credit is due, and blame where blame is due.)
| The fact that Lisp has a ``safety-net'' (not present in C and
| assembler) in that primitives are never mis-applied, is very useful and
| nice, but I still wouldn't call it a type-safe language.
that's because you have misunderstood Lisp's safety-net, confuse Scheme
with Lisp, and generally talk more than you should.
| [Some may claim that my X-COORD reflects bad style: that I should have
| used an explicitly tagged data structure for points and checked the tag
| in X-COORD. Fine; I can, and do, write such type-safe programs in
| Lisp, and so can I, in C and assembler; but the LANGUAGE isn't
| type-safe.]
yes, it's bad style, but not for the reason you think. the problem is that
_you_ aren't type-safe, because you have used the "Lisp" ambiguously. Lisp
is a class of languages, not a single language. properties of one of the
instances of that class are not necessarily properties of all instances,
nor of the class.
I strongly suspect you refer to Scheme, and not necessarily a functionally
useful implementation of Scheme, either.
#<Erik 3021035978>
--
tea, earl grey, industrial strength, hot.
Stephen J Bevan
In article <446dms$r...@quabbin.crl.dec.com> nik...@mattapoisett.crl.dec.com (R.S. Nikhil) writes:
To take a specific example: if a point in space is represented as a
pair of numbers, then the typical Lisp function that selects the
x-coordinate:
(define (x-coord pt) (car pt))
will happily work with any list I give it, whereas in most
statically typed languages, this mis-application is caught during
type-checking.
Why would the Lisp user define the point as a pair and not use say
defstruct/defclass in CommonLisp or something equivalent in another
dialect which does provide dynamic type checking?
Kees van Reeuwijk
[snip]
>(as opposed to C which typically cannot warn you that a switch statement
>doesn't deal with all cases)
Actually, if the switch() is on an enumerated type, it can. Some compilers,
for example the Gnu C compiler, do this.
--
Kees van Reeuwijk
Delft University of Technology, Faculty of Applied Physics, FI-CP
email: reeu...@cp.tn.tudelft.nl
URL: http://www.cp.tn.tudelft.nl/C.vanReeuwijk/
Kenneth Cline
|> In article <444h1m$3...@larry.rice.edu>,
|> Shriram Krishnamurthi <shr...@europa.cs.rice.edu> wrote:
|> ] The problem is not what happens when the type checker accepts your
|> ] program, but rather when it doesn't. The issue is not that it will
|> ] reject some correct programs; I know it will, and accept than when I
|> ] use SML. Rather, I often find the Hindley-Milner algorithm
|> ] unintuitive in its type judgements. In particular, reverse flow
|> ] problems can make some type errors fairly hard to understand.
|>
|> This is a serious problem and some research has been done that tries to keep
|> track of where which choices have been made so that when an error is detected,
|> the compiler can tell the user where he got some type from. I don't know how
|> well this works, tho.
As an ml programmer, I don't see this problem as very serious. It is
true that every once in a while the compiler prints a confusing type
mismatch error. However in the addition of a type constraint or two can
quickly yield better error messages. Only a tiny fraction of my time
programming in ml is spent tracking confusing type errors.
Ken
Chris Okasaki
>|> [stuff about how hard it can be to track down type errors in ML]
>
>As an ml programmer, I don't see this problem as very serious. It is
>true that every once in a while the compiler prints a confusing type
>mismatch error. However in the addition of a type constraint or two can
>quickly yield better error messages. Only a tiny fraction of my time
>programming in ml is spent tracking confusing type errors.
I both agree and disagree with Ken. I agree that for experienced ML
programmers, tracking down type errors is rarely a problem. In the rare
instance that you can't find the error fairly quickly, there are techniques
that will usually help, such as adding a few type constraints.
However, I disagree because I do believe it is a serious problem, not for
experienced ML programmers, but rather for novice ML programmers. The learning
curve for figuring out how to deal with these type errors is fairly steep,
and I think too many people give up in frustration. Without better tools and
techniques for *novices* to track down type errors, ML and its relatives
will never make a dent in mainstream programming.
I have a recurring friendly argument over these issues with a friend. She's
an experienced programmer, but hates ML because when she tried to learn it, she
found the type error messages too confusing. I maintain that however bad the
type error messages might be, they're better than the type error message that
C would give you in most cases ("Bus error - core dumped."). However, she
has over the years developed the skills to cope with that kind of error
(such as sprinkling the program with printf's) and is unwilling to invest
the significant chunk of time and effort that would be required to learn
the new set of skills for dealing with ML-style type errors.
Chris
--
-------------------------------------------------------------------------------
| Chris Okasaki | Life is NOT a zero-sum game! |
| coka...@cs.cmu.edu | http://foxnet.cs.cmu.edu/people/cokasaki/home.html |
-------------------------------------------------------------------------------
Fernando D. Mato Mira
|> Sorry but I'm shock because nobody talk about Smalltalk, it's have all the
|> advantages of ADA and LISP together.
Sorry, but I think all Lisp and Ada programmers around must agree that you're wrong.
|> but in a object oriented
|> lenguage with late binding you don't need typing at all.
Hm. Maybe in an OO language based on delegation (even then, types exist in some sense).
In any case, typing is always useful (typing =/= fascism or bureaucracy).
Saludos,
--
Fernando D. Mato Mira http://ligwww.epfl.ch/matomira.html
Computer Graphics Lab
Swiss Federal Institute of Technology (EPFL) Phone : +41 (21) 693 - 5248
CH-1015 Lausanne FAX : +41 (21) 693 - 5328
Switzerland E-mail : mato...@di.epfl.ch
Patrick D. Logan
>In article <002b...@celeborn.satlink.net>, fern...@celeborn.satlink.net (Fernando Martinez) writes:
>|> Sorry but I'm shock because nobody talk about Smalltalk, it's have all the
>|> advantages of ADA and LISP together.
>
>Sorry, but I think all Lisp and Ada programmers around must agree that you're wrong.
Indeed.
Smalltalk is more like a subset of Common Lisp.
A very powerful subset, but a subset nonetheless.
There are advantages to this fact, BTW. Being a subset
of Common Lisp is not necessarily a *bad* thing!
--
mailto:Patrick...@ccm.jf.intel.com
(503) 264-9309, FAX: (503) 264-3375
"Poor design is a major culprit in the software crisis...
R.S. Nikhil
|> ... first of all, the above code is Scheme,
|> not Lisp.
I stand suitably corrected, thank you. Yes, I was thinking Scheme. Most of the people I know
who use Scheme, including the inventors of Scheme, insist that Scheme is Lisp, but no doubt
they, like me, are seriously misinformed.
|> that's because you ... generally talk more than you should.
I apologize profusely for what is probably my first posting to this list this year, a total
of less than 20 lines of text. Obviously, it's too much.
|> I strongly suspect you refer to ... not necessarily a functionally
|> useful implementation of Scheme ...
You are utterly right, of course. I am in admiration of your ability to discern this from my
posting.
Now to go hide in my corner with some Earl Grey tea.
graham....@maths.anu.edu.au
distinguish between what is being denoted, and the syntax used
to denote it. For example '2' could be an integer, a rational,
a finite field element, a character, etc. In each of these denotations
the behaviour of '2' differs.
graham
--
A cat named Easter
He say "will you ever learn"
Its just an empty cage girl
If you kill the bird
A. Grant
>di...@silicon.csci.csusb.edu (Dr. Richard Botting) writes:
>>Most language have evolved towards the strongest form of typing. For
>>example: CPL->BCPL->B->C->ANSI C->C++
>Well, for one thing, C++ came before ANSI C.
And CPL had a strong Algol-60-like type system, even if BCPL doesn't.
It had real, integer, Boolean (sic capital), complex, list, string
and array types; machine registers and memory words were given their
own types, 'index' and 'logical' respectively. On at least one
machine 'integer' was represented internally as floating-point.
Thorsten Altenkirch
In article <19950925...@naggum.no> Erik Naggum <er...@naggum.no> writes:
nikhil> [R.S. Nikhil] | Yes, in Lisp you cannot mis-apply a primitive
nikhil> but, for me, safety also | implies never mis-applying
nikhil> user-defined functions. Without this | guarantee, I'd be
nikhil> hard-pressed to concede that Lisp is a type-safe | language.
erik> this doesn't make sense.
It does make sense to me. In LISP you make get a run-time error for
applying "+" to a list. In ML this can never happen.
nikhil> | To take a specific example: if a point in space is
nikhil> represented as a | pair of numbers, then the typical Lisp
nikhil> function that selects the | x-coordinate: | | (define (x-coord
nikhil> pt) (car pt)) | | will happily work with any list I give it,
nikhil> whereas in most statically | typed languages, this
nikhil> mis-application is caught during type-checking.
erik> sorry, you're seriously confused. first of all, the above code
erik> is Scheme, not Lisp.
I think rather you are confused. Scheme is a LISP dialect, there is
actually quite a number of them. Or do you confuse LISP and Common Lisp?
erik> second, if you use a primitive type to
erik> implement a higher-level type and you don't tell the type
erik> system, you get exactly the same kind of behavior in statically
erik> typed languages.
It is certainly a good idea to use structures but this wasn't the point.
nikhil> | The fact that Lisp has a ``safety-net'' (not present in C
nikhil> and | assembler) in that primitives are never mis-applied, is
nikhil> very useful and | nice, but I still wouldn't call it a
nikhil> type-safe language.
erik> that's because you have misunderstood Lisp's safety-net, confuse
erik> Scheme with Lisp, and generally talk more than you should.
I find the combination of arrogance and ignorance you display rather
shocking. I have to say that the discussion in comp.lang.functional is
usually on a higher level, but then this is a crossposting...
--
Thorsten Altenkirch LFCS, University of Edinburgh
Shriram Krishnamurthi
nik...@mattapoisett.crl.dec.com (R.S. Nikhil) writes:
> Yes, in Lisp you cannot mis-apply a primitive but, for me, safety
> also implies never mis-applying user-defined functions.
As some other responses have pointed out -- with, sadly, varying
degrees of vituperation -- the difficulty here is that you're not
making explicit the invariant you're trying to maintain with regard to
points (in this case). Tagging, mind, is not only no better than an
assembler-level solution, it still doesn't *solve the problem*.
However, there seems to be an increasing trend toward wanting the
addition of what some call "opaque" types (or structures); I think
"generative" might be a better name for them. For instance, we have
them in our local Scheme dialect (<http://www.cs.rice.edu/~scheme/>),
and I've seen some talk on the RnRS authors' mailing list about them.
(Unfortunately, the dialog there suggests some confusion between
opacity and "generativity"; I use quotes advisedly because it is both
less and more than ML's generative `datatype' declaration.) In fact,
I have more than a few times been lead into wild debugging romps
because of the current confusion of structures with vectors.
However, you know all this, and I think you're trying to make the more
interesting point that Scheme is insufficiently powerful to *express*
the constraints you want to place. This is true, and problematic. I
suspect Joe Fassel was trying to say the same thing, but I mangled the
point somewhat.
I recently discovered a similar issue with very "practical"
consequences. Say I'm writing something that inserts run-time checks
at primitives. What do I do with `force'? Well, I could re-write
(force <exp>)
as
((lambda args (if (and (= (length args) 1)
(procedure? (car args)))
(force (car args))
<error>))
<exp>)
but there's no way of determining the arity of that procedure. In
short, I can (as an annotator) never be certain that the object being
forced is a procedure of arity one. (In addition, there is the matter
of "What is a promise?", a question that so-called standard R4RS
leaves fairly open.)
'shriram
C Wright
> programming languages. I know that typing
> information is beneficial for compiling, for
> example, error checking. And there are some
> languages, such as Lisp, which are non typing
> benefits?
It has often been "quoted" that the development
times of large projects is significantly reduced
and the reliability of the result is much greater.
I haven't got any references to hand - can anyone
supply some hard evidence ??
Dr C.D. Wright,
personal opinions only.
Robert Bernecky
>di...@silicon.csci.csusb.edu (Dr. Richard Botting) writes:
>>dynamic typing(APL,BASIC)
>
>APL's dynamic typing is highly unusual in that it has syntactic consequences:
>a statement like "X <- F G Y" is *parsed* differently depending on whether
>F and G are unary functions or G is a binary function, and that can change
>at run time, so strictly speaking APL statements have to be reparsed whenever
>they are executed (at least according to the semantics in the APL2 draft
>standard I have floating around).
This is correct, but it is RARELY, if ever, used by anyone who wishes
to remain sane while maintaining an application. People write
functions with a specific valence (monadic or dyadic), and leave them
there.
The dynamic typing, by and large, is not a big deal, since you
can deduce the type of just about everything statically. APEX,
my parallel APL compiler, does just that.
The place where dynamic typing REALLY pays off [and my compiler
won't pick up on this one, sad to say] is when types change
underfoot:
In APL, if you (for example), add two integer arrays together: X+Y,
and the result won't fit in an integer format, you get an array of
doubles out, rather than an array of integers. Everything down the
line will then work on these floating values instead of the integer values.
This is why a large New York merchant bank running SHARP APL was
able to make money (fast 8^} ) on Black Monday when all the other
trading systems were either:
- dead, because integer overflow took them off the air
- slow or giving wrong answers[ignoring the overflow!] to
traders, letting them trade themselves into Really Big Losses
What happened was that trading volumes and total $$ were so large
that normally happy integer values went floating. APL kept humming
along. Other systems, coded in C, COBOL, or other languages,
did something else.
Now, having said that: Most APL programmers will claim that they
know the types and dimensionality of all the arrays in their code.
They are usually right.
Bob
Mike Mc Gaughey
>[Peter Hermann]
>| The benefit pays off in a drastic(!) reduction of programming errors.
>the value is in early detection of programming errors, ideally causing a
>reduction of programming errors in the running code, but this is not
>necessarily the case as even those "errors" that there is no value in
>detecting are detected, and "correcting" them only adds unnecessary
>complexity to the program.
It's only "unnecessary" if you didn't really want any help from the
type system in the first place (in which case, there are other
languages out there for you). Those of us that *like* strong types
feel that the occasional need to satisfy the type system is a small
price to pay for the detection of a large class of errors. Think of it
as a lifestyle choice - if you would like to get to work faster, you
might choose a motorcycle, rather than a car with seat belts.
A static type system is a subpart of a program specification which can
be checked at compile time. If you're dashing off a small program,
such checks may be unnecessary and unwelcome; write it in LISP. If
you're building a large one, they can be damned useful; write it in a
language that does (at least) some static type checking. As a side
effect, you usually get some optimisations.
The challenge is to devise more flexible type systems that still manage
to hold the programmer's hand at compile time (rather than crashing and
burning at runtime), while remaining reasonably intuitive. That's
hard, and, because some things are only semidecidable, there will always
be people for whom current "static type system technology" is too
restrictive to use.
These don't necessarily represent better or worse programmers - just
different styles. There are also "soft" type systems, for dynamically
typed languages, which don't impose type constraints but will issue
warnings (when they can) and optimise code.
>further, as the number of types increases [...]
>the ability of even very intelligent and highly experienced
>programmers to keep track of them and obtain the desired result in the
>presence of overloaded operators is decreasing dramatically.
Gotta agree. But this is the same as keeping track of the function
calls in a large dynamically typed system. It's precisely when systems
become large that you'd *like* the compiler to check some of the more
obvious potential errors for you.
>this leads me to my second argument against strong typing. getting a type
>system right requires so much detailed specification that the cost is so
>high that mistakes are actively discouraged.
Strong type systems discourage mistakes! And you're arguing *against* it? :)
Hmm. There's Haskell (actually, Gofer in particular). Pretty flexible
if you want it to be, but still reasonably safe. And you don't have to
*use* the extra stuff if you're comfortable with a subset of the type
system. Haskell/Gofer aren't the ultimate, of course (just reasonably
nifty and intuitive); they seem like a reasonable trade off.
For a better example of a powerful dynamic type system which allows
type constraints to be checked at compile time, there's Quest (Cardelli
et al; papers on the web, and well worth reading). Quest is
essentially explicitly typed (you mention type parameters to functions
when necessary), which allows its type system to be very general, but
still checkable. It supports parametric polymorphism, encapsulation,
overloading, record (and other) subsumption, etc; it also seems to
scale reasonably well between small, dashed off programs and very large
systems.
All of these languages are strongly typed, being based on similar styles
of typing technology, but go to different lengths to be flexible and/or
efficient. Different people will choose different languages. This is
how it should be.
Cheers,
Mike.
--
Mike McGaughey AARNET: mm...@molly.cs.monash.edu.au
"Thousands at his bidding speed,
And post o'er land and ocean without rest" - Milton.
Dr. Richard Botting
[good discussion of different typing systems delete]
: Think of it
: as a lifestyle choice - if you would like to get to work faster, you
: might choose a motorcycle, rather than a car with seat belts.
Does this choice effect your career? I'm thinking of
the truck driver who insists on using a motorbike for his
trucking! Or the cross-town messenger in a truck!
I guess my point is that it is *more* than a life-style choice.
A safety belt may have saved my life once, but it didn't stop the car
from crashing into somebody else's property. When my word processor
crashes I loose work. When a bridge on our network crashes
labs, memos, etc on campus are delayed. A type system or language
that lets a program crash may be a problem to others tho'
a solution to the programmer.
I'm redirecting followups to this posting to comp.soft-eng.
Cyber Surfer
mm...@cs.monash.edu.au "Mike Mc Gaughey" writes:
> All of these languages are strongly typed, being based on similar styles
> of typing technology, but go to different lengths to be flexible and/or
> efficient. Different people will choose different languages. This is
> how it should be.
What usually interests me far more than the stength of the typing system
(which can easily be debated, as this thread shows), is the size of the
compilation unit supported by the compiler. I like to compile small units
very fast, as I often change small (sometimes _very_ small) amounts of
code repeatedly.
Like with your description of typing as a "lifestyle" choice, I think that
the compilation unit size is another "lifestyle" choice. I'll happily go
without types altogether (e.g. using Forth) if it means I can develop
something quickly. After it works, I might ask myself if I should rewrite
it in another language, perhaps for more speed, or even for "delivery".
That's a personal choice, as the Forth implementation I've used is my
own, and its support for producing stand-alone code is currently limited.
This is one reason why I've been attracted to Lisp for the last 10 years.
Now I can get an implementation that'll allow me to produce stand-alone
code, and yet still develop in an interactive enviroment _and_ use an
incremental compiler.
--
<URL:http://www.demon.co.uk/community/index.html>
<URL:http://www.enrapture.com/cybes/namaste.html>
"You can never browse enough."