[27976] in Perl-Users-Digest
Perl-Users Digest, Issue: 9340 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jun 22 06:10:14 2006
Date: Thu, 22 Jun 2006 03:10:05 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 22 Jun 2006 Volume: 10 Number: 9340
Today's topics:
Re: What is Expressiveness in a Computer Language <pc@p-cos.net>
Re: What is Expressiveness in a Computer Language <pc@p-cos.net>
Re: What is Expressiveness in a Computer Language ilitzroth@gmail.com
Re: What is Expressiveness in a Computer Language <rossberg@ps.uni-sb.de>
Re: What is Expressiveness in a Computer Language <rossberg@ps.uni-sb.de>
Re: What is Expressiveness in a Computer Language <pc@p-cos.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 22 Jun 2006 09:47:12 +0200
From: Pascal Costanza <pc@p-cos.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <4fv081F1jh4ifU1@individual.net>
David Hopwood wrote:
> Marshall wrote:
>> Chris Smith wrote:
>>> Marshall <marshall.spight@gmail.com> wrote:
>>>
>>>> I think what this highlights is the fact that our existing terminology
>>>> is not up to the task of representing all the possible design
>>>> choices we could make. Some parts of dynamic vs. static
>>>> a mutually exclusive; some parts are orthogonal.
>>> Really? I can see that in a strong enough static type system, many
>>> dynamic typing features would become unobservable and therefore would be
>>> pragmatically excluded from any probable implementations... but I don't
>>> see any other kind of mutual exclusion between the two.
>> Well, it strikes me that some of what the dynamic camp likes
>> is the actual *absence* of declared types, or the necessity
>> of having them.
>
> So why aren't they happy with something like, say, Alice ML, which is
> statically typed, but has a "dynamic" type and type inference? I mean
> this as a serious question.
Note: I haven't yet worked with such a language, but here is my take anyway.
A statically type language requires you to think about two models of
your program at the same time: the static type model and the dynamic
behavioral model. A static type system ensures that these two
_different_ (that's important!) perspectives are always in sync. This is
especially valuable in settings where you know your domain well and want
to rely on feedback by your compiler that you haven't made any mistakes
in encoding your knowledge. (A static type system based on type
inferencing doesn't essentially change the requirement to think in two
models at the same time.)
A dynamically typed language is especially well suited when you don't
(yet) have a good idea about your domain and you want to use programming
especially to explore that domain. Some static typing advocates claim
that static typing is still suitable for exploring domains because of
the compiler's feedback about the preliminary encoding of your
incomplete knowledge, but the disadvantages are a) that you still have
to think about two models at the same time when you don't even have
_one_ model ready and b) that you cannot just run your incomplete
program to see what it does as part of your exploration.
A statically typed language with a dynamic type treats dynamic typing as
the exception, not as the general approach, so this doesn't help a lot
in the second setting (or so it seems to me).
A language like Common Lisp treats static typing as the exception, so
you can write a program without static types / type checks, but later on
add type declarations as soon as you get a better understanding of your
domain. Common Lisp implementations like CMUCL or SBCL even include
static type inference to aid you here, which gives you warnings but
still allows you to run a program even in the presence of static type
errors. I guess the feedback you get from such a system is probably not
"strong" enough to be appreciated by static typing advocates in the
first setting (where you have a good understanding of your domain).
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
------------------------------
Date: Thu, 22 Jun 2006 09:47:58 +0200
From: Pascal Costanza <pc@p-cos.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <4fv09fF1jh4ifU2@individual.net>
Benjamin Franksen wrote:
> Pascal Costanza wrote:
>> There is, of course, room for research on performing static type checks
>> in a running system, for example immediately after or before a software
>> update is applied, or maybe even on separate type checking on software
>> increments such that guarantees for their composition can be derived.
>> However, I am not aware of a lot of work in that area, maybe because the
>> static typing community is too focused on compile-time issues.
>
> Not everyone is. For instance, Don Stewart has been enormously successful in
> deploying such a system for Haskell (very much a statically typed language)
> in a practically usable way. It is called hs-plugins (see
> http://www.cse.unsw.edu.au/~dons/hs-plugins/), a framework for run-time
> loading and re-loading of Haskell modules (in source form or already
> compiled, giving different levels of security). Far from being a purely
> academic exercise, there are interesting applications, including yi, an
> extensible editor, and lambdabot, an IRC bot, both available from the above
> same home page.
Thanks for the link, I will check this out.
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
------------------------------
Date: 22 Jun 2006 02:12:23 -0700
From: ilitzroth@gmail.com
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150967543.947096.72840@g10g2000cwb.googlegroups.com>
> A statically type language requires you to think about two models of
> your program at the same time: the static type model and the dynamic
> behavioral model. A static type system ensures that these two
> _different_ (that's important!) perspectives are always in sync.
I have trouble understanding your use of the wording "Model of a
program".
If it is a system that behaves according to the rules of your program
then
statements about your program should consider *all* possible models.
If it is a formal system that makes statements about properties of your
program
than the static type system is a simplified model that is suitable for
automatic
analysis and your runtime model is in most cases nonexistent.
Can you give a definition of a "model of a program"? Can you explain
why
Lisp doesn't have two (SBCL does do a lot of typechecking and gives
type errors)?
> This is
> especially valuable in settings where you know your domain well and want
> to rely on feedback by your compiler that you haven't made any mistakes
> in encoding your knowledge. (A static type system based on type
> inferencing doesn't essentially change the requirement to think in two
> models at the same time.)
It is also valuable when you don't know your domain very well and you
want to rely on feedback by your compiler that you haven't made any
mistakes in encoding your limited knowledge
> A dynamically typed language is especially well suited when you don't
> (yet) have a good idea about your domain and you want to use programming
> especially to explore that domain. our domain).
In the sense that you can start writing code without the compiler
pointing out
all but the most glaring holes in your program, I agree. Most of your
arguments
aren't very convincing and the thruth is that I have seem lisp
programmers using
the debugger to find out that you can't add a number and a hastable.
The static view
was not there and the dynamic view must have been too complicated so
they had
nothing to think about.
Immanuel
------------------------------
Date: Thu, 22 Jun 2006 11:31:19 +0200
From: Andreas Rossberg <rossberg@ps.uni-sb.de>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <e7do17$8v164$9@hades.rz.uni-saarland.de>
Marshall wrote:
>Andreas Rossberg wrote:
>>Chris Uppal wrote:
>>
>>>I have never been very happy with relating type to sets of values (objects,
>>>whatever).
>>
>>Indeed, this view is much too narrow. In particular, it cannot explain
>>abstract types, which is *the* central aspect of decent type systems.
>
> What prohibits us from describing an abstract type as a set of values?
If you identify an abstract type with the set of underlying values then
it is equivalent to the underlying representation type, i.e. there is no
abstraction.
>>There were papers observing this as early as 1970.
>
> References?
This is 1973, actually, but most relevant:
James Morris
Types Are Not Sets.
Proc. 1st ACM Symposium on Principles of Programming Languages, 1973
>>(There are also theoretic problems with the types-as-sets view, because
>>sufficiently rich type systems can no longer be given direct models in
>>standard set theory. For example, first-class polymorphism would run
>>afoul the axiom of foundation.)
>
> There is no reason why we must limit ourselves to "standard set theory"
> any more than we have to limit ourselves to standard type theory.
> Both are progressing, and set theory seems to me to be a good
> choice for a foundation. What else would you use?
I'm no expert here, but Category Theory is a preferred choice in many
areas of PLT.
- Andreas
------------------------------
Date: Thu, 22 Jun 2006 11:51:18 +0200
From: Andreas Rossberg <rossberg@ps.uni-sb.de>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <e7dp6m$8r8i0$1@hades.rz.uni-saarland.de>
Rob Warnock wrote:
>
> Here's what the Scheme Standard has to say:
>
> http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-4.html
> 1.1 Semantics
> ...
> Scheme has latent as opposed to manifest types. Types are assoc-
> iated with values (also called objects) rather than with variables.
> (Some authors refer to languages with latent types as weakly typed
> or dynamically typed languages.) Other languages with latent types
> are APL, Snobol, and other dialects of Lisp. Languages with manifest
> types (sometimes referred to as strongly typed or statically typed
> languages) include Algol 60, Pascal, and C.
Maybe this is the original source of the myth that static typing is all
about assigning types to variables...
With all my respect to the Scheme people, I'm afraid this paragraph is
pretty off, no matter where you stand. Besides the issue just mentioned
it equates "manifest" with static types. I understand "manifest" to mean
"explicit in code", which of course is nonsense - static typing does not
require explicit types. Also, I never heard "weakly typed" used in the
way they suggest - in my book, C is a weakly typed language (= typed,
but grossly unsound).
> To me, the word "latent" means that when handed a value of unknown type
> at runtime, I can look at it or perform TYPE-OF on it or TYPECASE or
> something and thereby discover its actual type at the moment[1], whereas
> "manifest" means that types[2] are lexically apparent in the code.
Mh, I'd say typecase is actually a form of reflection, which is yet a
different issue. Moreover, there are statically typed languages with
typecase (e.g. Modula-3, and several more modern ones) or related
constructs (consider instanceof).
- Andreas
------------------------------
Date: Thu, 22 Jun 2006 12:02:02 +0200
From: Pascal Costanza <pc@p-cos.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <4fv84rF1kp06kU1@individual.net>
ilitzroth@gmail.com wrote:
> > A statically type language requires you to think about two models of
>
>> your program at the same time: the static type model and the dynamic
>> behavioral model. A static type system ensures that these two
>> _different_ (that's important!) perspectives are always in sync.
>
> I have trouble understanding your use of the wording "Model of a
> program".
> If it is a system that behaves according to the rules of your program
> then
> statements about your program should consider *all* possible models.
> If it is a formal system that makes statements about properties of your
> program
> than the static type system is a simplified model that is suitable for
> automatic
> analysis and your runtime model is in most cases nonexistent.
> Can you give a definition of a "model of a program"? Can you explain
> why
> Lisp doesn't have two (SBCL does do a lot of typechecking and gives
> type errors)?
I wasn't talking about models that the language implementation may or
may not have, but the models that I as a programmer must have in order
to convince the compiler to let me program run.
Consider a simple expression like 'a + b': In a dynamically typed
language, all I need to have in mind is that the program will attempt to
add two numbers. In a statically typed language, I additionally need to
know that there must a guarantee that a and b will always hold numbers.
In a trivial example like this, this doesn't hurt a lot, but can be
problematic as soon as the program size grows.
>> This is
>> especially valuable in settings where you know your domain well and want
>> to rely on feedback by your compiler that you haven't made any mistakes
>> in encoding your knowledge. (A static type system based on type
>> inferencing doesn't essentially change the requirement to think in two
>> models at the same time.)
>
> It is also valuable when you don't know your domain very well and you
> want to rely on feedback by your compiler that you haven't made any
> mistakes in encoding your limited knowledge
I have more or less used exactly the same words in the paragraph that
followed the one you cited from my previous posting, and I have already
given a reply there.
>> A dynamically typed language is especially well suited when you don't
>> (yet) have a good idea about your domain and you want to use programming
>> especially to explore that domain. our domain).
>
> In the sense that you can start writing code without the compiler
> pointing out
> all but the most glaring holes in your program, I agree.
I don't know what language environments you are used to, but the Common
Lisp compilers I use always point out the most glaring holes in my
programs. But maybe I just have trouble understanding your use of the
wording "most glaring holes". Can you give a definition of "most glaring
holes"? ;)
> Most of your
> arguments
> aren't very convincing and the thruth is that I have seem lisp
> programmers using
> the debugger to find out that you can't add a number and a hastable.
> The static view
> was not there and the dynamic view must have been too complicated so
> they had
> nothing to think about.
We have all seen less-than-average programmers who would fail in all
kinds of languages. What they do is typically not very illuminating.
My goal is not to convince anyone, my goal is to illustrate for those
who are interested in getting a possibly different perspective.
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 9340
***************************************
