>>>>> "Graham" == Graham Matthews <···············@maths.anu.edu.au> writes:
Daniel Wang wrote:
>> I think there is a real important difference between a "scripting"
>> and "systems programming" languages. "scripting" languages are
>> designed to let you *manipulate* a certain set of *fixed*
>> abstractions easily. "System languages" are desgined to let you
>> *create* new abstractions.
Graham> But the point is that a language (eg.Lisp) can do both -- ie:
Graham> let you manipulate the provided abstractions, and let you create
Graham> new ones.
But it doesn't provide any special builtin pre-packaged support for
manipulating a specific set of abstractions. (Special syntax for example)
It's designed to let you build your own. In any case I'm not claiming this
is a hard distinction. Just that Lisp is not designed to be like Perl5 or
vice versa, and that the design tradeoffs that Lisp and Perl5 make are
different because one has a "scripting" philosophy while the other a more
"systems" philosophy.
{stuff deleted}
Graham> Sorry but you have fallen for the warped Mathematica
Graham> mind-set. Lets say I have a polynomial whose coefficients are
Graham> "just numbers in the most abstract sense". Now I ask for this
Graham> polynomial to be factorised. The exact factorisation you get
Graham> depends on the precise types of those "abstract numbers" -- a
Graham> polynomial can factor over the complex numbers, but NOT over say
Graham> the real numbers, or the integers. Exactly how and whether the
Graham> polynomial factors depends on the precise type of the
Graham> numbers. This Mathematica line that everything is "just abstract
Graham> numbers" is baloney. What Mathematica actually assumes (by
Graham> default) is that everything is a complex number.
And in most cases if I want integer or real solution and Mathematica returns
a complex factoriziation I know there aren't any real or integer
solutions. The point being it's not worth my trouble to annotate the type of
each variable in this any many situations. In cases where I really care
Mathematica has factorization functions specified for specific types. You're
missing the point that in some situations when you have sufficently abstract
objects a type system isn't worth it. This is why Lisp doesn't have a type
system, even though I think it could really use it.
In article <···············@dynamic.CS.Princeton.EDU>,
·······@dynamic.CS.Princeton.EDU (Daniel Wang) wrote:
> But it doesn't provide any special builtin pre-packaged support for
> manipulating a specific set of abstractions. (Special syntax for example)
Symbolics Common Lisp with Genera does provide this.
It has a command interpreter substrate, infix parser, ...
> objects a type system isn't worth it. This is why Lisp doesn't have a type
> system, even though I think it could really use it.
Huh? Common Lisp has a type system. For quite a long time.
The CMU CL compiler takes advantage of this using type inference
for both optimization and type checking.
--
http://www.lavielle.com/~joswig/
Daniel Wang (·······@dynamic.CS.Princeton.EDU) wrote about Lisp:
> But it doesn't provide any special builtin pre-packaged support for
> manipulating a specific set of abstractions. (Special syntax for example)
Huh? Common Lisp provides syntax for characters, strings, integers, ratios,
several floating point types, complex numbers composed from these numeric
types, pairs/lists, structures, arrays, symbols, mostly-constant patterns
(i.e. the backquote mechanism), conditional input, evaluated sub-expressions,
embedded references to other parts of the input to form cyclic data, and
some more. In fact, I don't know any other programming language (and I know
quite a few) where such a variety of data structures can be directly written,
instread of composing them from several initialization statements. Then, as
you said, all this is easily extendable with the full expressiveness of the
language.
> This is why Lisp doesn't have a type system,
Common Lisp does have an expressive type system (and good implementations
use this plus considerable type inference both for optimization and for type
checking). What it doesn't have is _enforced_ statically decidable typing.
-- Marc Wachowitz <··@ipx2.rz.uni-mannheim.de>
Hello Marc
> > This is why Lisp doesn't have a type system,
>
> Common Lisp does have an expressive type system (and good implementations
> use this plus considerable type inference both for optimization and for type
> checking). What it doesn't have is _enforced_ statically decidable typing.
>
> -- Marc Wachowitz <··@ipx2.rz.uni-mannheim.de>
Your answer makes me interested in learning more on type systems
that do not enforce statically decidable typing.
Could You (or someone else) please point out some good books that
cover this topic?
Thank you very much
Stefan
>>>>> "Marc" == Marc Wachowitz <··@ipx2.rz.uni-mannheim.de> writes:
Marc> Daniel Wang (·······@dynamic.CS.Princeton.EDU) wrote about Lisp:
>> This is why Lisp doesn't have a type system,
{stuff deleted}
Marc> What it doesn't have is _enforced_ statically decidable typing.
This is my definition of a type system. I should be shot for forgetting some
people have very different ideas of what a type system is. **Statically
decidable** typing is what make "type systems" a win as it catches errors at
compile time rather than at runtime.
From: Paul Wilson
Subject: static vs. dynamic typing (was Re: Scripting vs. Systems)
Date:
Message-ID: <5jgo4b$dlc@roar.cs.utexas.edu>
[ Note: followups trimmed. ]
In article <···············@nordica.CS.Princeton.EDU>,
Daniel Wang <·······@nordica.CS.Princeton.EDU> wrote:
>>>>>> "Marc" == Marc Wachowitz <··@ipx2.rz.uni-mannheim.de> writes:
>
> Marc> Daniel Wang (·······@dynamic.CS.Princeton.EDU) wrote about Lisp:
>
> >> This is why Lisp doesn't have a type system,
> {stuff deleted}
> Marc> What it doesn't have is _enforced_ statically decidable typing.
>
>This is my definition of a type system. I should be shot for forgetting some
>people have very different ideas of what a type system is. **Statically
>decidable** typing is what make "type systems" a win as it catches errors at
>compile time rather than at runtime.
I'm not sure what you mean here, so perhaps some clarification is in
order.
What the Lispers are talking about is optional enforced
static typing. The idea is that you can statically type important
parts of your code, for all of the usual reasons, but you can also
use dynamic typing if you find it more convenient for rapid prototyping
or if there's something you believe is correct but can't express
to the static type system. Common Lisp and Dylan let you do some
of this sort of thing.
Common Lisp allows an implementation to completely ignore type
declarations, and some implementations do at higher optimization
levels. They assume that you'll get your program debugged with
extensive checking, and then compile it for speed rather than safety.
Some implementations always put in any checking if they can't optimize
it away, so that you don't lose safety at higher optimization levels,
and instead you may lose a little speed.
(My own preference is that a language should make it explict that
type declaratiosn are always repected and checked at compile-time
or run-time, but also provide for "trust me" type declarations
where you've proved to your own satisfaction you're right. This
is important in developing tweaked code, like an object system
implemented within the language. The typing of such things
can be very hard to explain to any compiler, because the
constraints aren't local.)
Dynamic typing is sometimes more convenient and expressive (in the
sense of "being able to express a computation" to the system concisely)
in general, and static typing is intentionaly more restrictive, but more
"expressive" in a different sense---you can express more *constraints*
on computations, and have the compiler "check your work."
I'm not trying to take a stand here on whether your program should
be mostly statically typed, or mostly dynamically typed. It is
clear that polymorphic static type systems are much more expressive than
earlier, monomorphic type type systems---they let you do more things
that you could in, say C's type system, without the compiler getting
confused and rejecting your program. This lets you do many of the things
that previously required a dynamic type system. However, most or all of
the advanced polymorphic type systems are awkward for some styles of
programming (particularly OOP programming with side effects.)
W.R.T. this thread, dynamic typing is attractive to many poeple
for scripting because it is very simple to implement, very simple to
understand, and supports wildly extensible langauges based on a tiny,
clean core language. The addition of optional strong typing can
help with programming in the large. However, static polymorphic type
systems have nice advantages, too, and some of the newer type systems
seem to combine many of the best featurees of both. (I believe
there are still limitations, such as typing things like eval,
and other metaleval code, which turns out to be quite relevant
to scripting languages.)
If people want to discuss advanced type systems, I suggest we do
it elsewhere, so I've set followups to comp.lang.misc.
--
| Paul R. Wilson, Comp. Sci. Dept., U of Texas @ Austin (······@cs.utexas.edu)
| Papers on memory allocators, garbage collection, memory hierarchies,
| persistence and Scheme interpreters and compilers available via ftp from
| ftp.cs.utexas.edu, in pub/garbage (or http://www.cs.utexas.edu/users/wilson/)
In article <···············@nordica.CS.Princeton.EDU>,
>This is my definition of a type system. I should be shot for forgetting some
>people have very different ideas of what a type system is.
Umm. Like everyone else who has ever studied programming languages?
> **Statically
>decidable** typing is what make "type systems" a win as it catches errors at
>compile time rather than at runtime.
It also "catches" correct code and says: "you can't do that." I'm not going to
get into an argument about which is better: I use both. But clearly runtime
typing is also "a win". Compare programming in a language with neither
static nor runtime type checking to one with either. Types are important
whenever they are checked.
I also wonder: what language do you program in that has completely statically
decidable type checking? I don't know of many modern languages that do not
allow you to cast up and down the class hierarchy, at least. Yes, I know
that such languages exist, but from your comment above I do not think that
you are using something like ML. In other words, most languages allow you
to do away with static type checking if you want to. Most Lisps will allow
you to add it if you want it.
Paul Prescod