[27972] in Perl-Users-Digest
Perl-Users Digest, Issue: 9336 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Jun 21 18:10:15 2006
Date: Wed, 21 Jun 2006 15:10:07 -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 Wed, 21 Jun 2006 Volume: 10 Number: 9336
Today's topics:
Re: What is Expressiveness in a Computer Language <rvtol+news@isolution.nl>
Re: What is Expressiveness in a Computer Language <cdsmith@twu.net>
Re: What is Expressiveness in a Computer Language <cdsmith@twu.net>
Re: What is Expressiveness in a Computer Language <eval.apply@gmail.com>
Re: What is Expressiveness in a Computer Language <marshall.spight@gmail.com>
Re: What is Expressiveness in a Computer Language <marshall.spight@gmail.com>
Re: What is Expressiveness in a Computer Language <marshall.spight@gmail.com>
Re: What is Expressiveness in a Computer Language <marshall.spight@gmail.com>
Re: What is Expressiveness in a Computer Language <gneuner2/@comcast.net>
Re: What is Expressiveness in a Computer Language <david.nospam.hopwood@blueyonder.co.uk>
Re: What is Expressiveness in a Computer Language <sleepingsquirrel@yahoo.com>
Re: What is Expressiveness in a Computer Language <cfc@shell01.TheWorld.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 21 Jun 2006 20:02:21 +0200
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <e7c8sr.1fk.1@news.isolution.nl>
Rob Thorpe schreef:
> Dr.Ruud:
>> Marshall:
>>> "dynamic types." I don't have a firm definition for
>>> that term, but my working model is runtime type tags. In which
>>> case, I would say that among statically typed languages,
>>> Java does have dynamic types, but C does not. C++ is
>>> somewhere in the middle.
>>
>> C has union.
>
> That's not the same thing.
That is your opinion. In the context of this discussion I don't see any
problem to put C's union under "dynamic types".
> The value of a union in C can be any of a
> set of specified types. But the program cannot find out which, and
> the language doesn't know either.
>
> With C++ and Java dynamic types the program can test to find the type.
When such a test is needed for the program with the union, it has it.
--
Affijn, Ruud
"Gewoon is een tijger."
------------------------------
Date: Wed, 21 Jun 2006 12:33:16 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <MPG.1f033ed6670cd7239896d3@news.altopia.net>
Joachim Durchholz <jo@durchholz.org> wrote:
> Assume a language that
> a) defines that a program is "type-correct" iff HM inference establishes
> that there are no type errors
> b) compiles a type-incorrect program anyway, with an establishes
> rigorous semantics for such programs (e.g. by throwing exceptions as
> appropriate).
So the compiler now attempts to prove theorems about the program, but
once it has done so it uses the results merely to optimize its runtime
behavior and then throws the results away. I'd call that not a
statically typed language, then. The type-checking behavior is actually
rather irrelevant both to the set of valid programs of the language, and
to the language semantics (since the same could be accomplished without
the type checking). It is only relevant to performance. Obviously, the
language probably qualifies as dynamically typed for most common
definitions of that term, but I'm not ready to accept one definition and
claim to understand it, yet, so I'll be cautious about classsifying the
language.
> The compiler might actually refuse to compile type-incorrect programs,
> depending on compiler flags and/or declarations in the code.
Then those compiler flags would cause the compiler to accept a different
language, and that different language would be a statically typed
language (by which I don't mean to exclude the possibility of its also
being dynamically typed).
> Typed ("strongly typed") it is, but is it statically typed or
> dynamically typed?
So my answer is that it's not statically typed in the first case, and is
statically typed in the second case, and it intuitively appears to be
dynamically typed at least in the first, and possibly in the second as
well.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
Date: Wed, 21 Jun 2006 12:34:37 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <MPG.1f033f2c90b5a97e9896d4@news.altopia.net>
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.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
Date: 21 Jun 2006 11:46:54 -0700
From: "Joe Marshall" <eval.apply@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150915614.636327.233490@p79g2000cwp.googlegroups.com>
Marshall wrote:
>
> That's really coming home to me in this thread: the terminology is *so*
> bad. I have noticed this previously in the differences between
> structural
> and nominal typing; many typing issues associated with this distinction
> are falsely labeled as a static-vs-dynamic issues, since so many
> statically
> type languages are nominally typed.
>
> We need entirely new, finer grained terminology.
Agreed. That's why I've been biting my tongue and avoiding posting.
The discussion is going along the lines of the blind men and the
elephant. I've seen about seven different definitions of what a `type'
is, and most of the arguments seem to come from people misunderstanding
the other person's definition. I think that *most* of the people
arguing here would agree with each other (possibly in detail) if only
they understood each other.
Static type aficionados have a specialized jargon that has precise
meaning for a number of the terms being used. People that aren't into
that field of computer science use the same terms in a much looser
sense. But static type aficionados are definitely in the minority in
comp.lang.lisp, and probably in a few of the other comp.langs as well.
What we need is an FAQ entry for how to talk about types with people
who are technically adept, but non-specialists. Or alternatively, an
FAQ of how to explain the term `dynamic typing' to a type theorist.
------------------------------
Date: 21 Jun 2006 11:58:47 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150916327.332627.124400@g10g2000cwb.googlegroups.com>
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?
> There were papers observing this as early as 1970.
References?
> (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?
(Agree with the rest.)
Marshall
------------------------------
Date: 21 Jun 2006 12:05:37 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150916736.943255.131190@i40g2000cwc.googlegroups.com>
Dr.Ruud wrote:
> Marshall schreef:
>
> > "dynamic types." I don't have a firm definition for
> > that term, but my working model is runtime type tags. In which
> > case, I would say that among statically typed languages,
> > Java does have dynamic types, but C does not. C++ is
> > somewhere in the middle.
>
> C has union.
But it does not have tagged unions, so my point is unaffected.
Marshall
------------------------------
Date: 21 Jun 2006 12:19:23 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150917563.369958.250980@m73g2000cwd.googlegroups.com>
Matthias Blume wrote:
> "Marshall" <marshall.spight@gmail.com> writes:
>
> > Torben =C6gidius Mogensen wrote:
> >>
> >> That's not true. ML has variables in the mathematical sense of
> >> variables -- symbols that can be associated with different values at
> >> different times. What it doesn't have is mutable variables (though it
> >> can get the effect of those by having variables be immutable
> >> references to mutable memory locations).
> >
> > While we're on the topic of terminology, here's a pet peeve of
> > mine: "immutable variable."
> >
> > immutable =3D can't change
> > vary-able =3D can change
> >
> > Clearly a contradiction in terms.
>
> No, it is not a contradiction. See the mathematical usage of the word
> "variable".
I am not saying that this kind of terminology isn't common; what
I'm saying is that it isn't good. And I think I gave a pretty clear
and solid definition of the two words, and those definitions are
decidedly contradictory.
> Immutable variables can stand for different values at
> different times, even without mutation involved, usually because they
> are bound by some construct such as lambda.
Well, that's a good point actually. Parameters are variable
no matter how you look at it. I was speaking more in terms
of locals.
> > If you have a named value that cannot be updated, it makes
> > no sense to call it "variable" since it isn't *able* to *vary.*
>
> Mutation is not the only way for an expression to evaluate to
> different values over time.
I suppose the difficulty arises from the difference
between the connotation of "mutate" in a PLT context, which is
support for destructive assignment, and the meaning of the word
in the larger context.
Anyway, I don't see how your sentence above contradicts
my sentence. We do not use the term "update" to describe
the process of binding values to parameters upon function
invocation. (Am I wrong?)
Marshall
------------------------------
Date: 21 Jun 2006 12:37:09 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150918629.818145.143220@y41g2000cwy.googlegroups.com>
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. At the very least, requiring types vs. not requiring
types is mutually exclusive.
But again, my dynamic kung fu is very weak, so I may not know
what I'm talking about when I represent the dynamic side.
Marshall
------------------------------
Date: Wed, 21 Jun 2006 16:55:55 -0400
From: George Neuner <gneuner2/@comcast.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <34aj92h0g7tqi9amhh7k3ieq5n568t0e6f@4ax.com>
On Wed, 21 Jun 2006 16:12:48 +0000 (UTC), Dimitri Maziuk
<dima@127.0.0.1> wrote:
>George Neuner sez:
>> On Mon, 19 Jun 2006 22:02:55 +0000 (UTC), Dimitri Maziuk
>><dima@127.0.0.1> wrote:
>>
>>>Yet Another Dan sez:
>>>
>>>... Requiring an array index to be an integer is considered a typing
>>>> problem because it can be checked based on only the variable itself,
>>>> whereas checking whether it's in bounds requires knowledge about the array.
>>>
>>>You mean like
>>> subtype MyArrayIndexType is INTEGER 7 .. 11
>>> type MyArrayType is array (MyArrayIndexType) of MyElementType
>>>
>>
>> If the index computation involves wider types it can still produce
>> illegal index values. The runtime computation of an illegal index
>> value is not prevented by narrowing subtypes and cannot be statically
>> checked.
>
>My vague recollection is that no, it won't unless _you_ explicitly code an
>unchecked type conversion. But it's been a while.
You can't totally prevent it ... if the index computation involves
types having a wider range, frequently the solution is to compute a
wide index value and then narrow it. But if the wider value is out of
range for the narrow type you have a problem.
Using the illegal wide value in a checked narrowing conversion will
throw a CONSTRAINT_ERROR exception - it doesn't matter whether you
access the array directly using the wide value or try to assign the
value to a variable of the narrow index type. Using the wide value
unchecked will access memory beyond the array which is not what you
wanted and may cause a crash.
The point is really that the checks that prevent these things must be
performed at runtime and can't be prevented by any practical type
analysis performed at compile time. I'm not a type theorist but my
opinion is that a static type system that could, a priori, prevent the
problem is impossible.
George
--
for email reply remove "/" from address
------------------------------
Date: Wed, 21 Jun 2006 21:56:49 GMT
From: David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <Bgjmg.465671$xt.323602@fe3.news.blueyonder.co.uk>
Rob Thorpe wrote:
> Vesa Karvonen wrote:
>
>>In comp.lang.functional Anton van Straaten <anton@appsolutions.com> wrote:
>>
>>>Let me add another complex subtlety, then: the above description misses
>>>an important point, which is that *automated* type checking is not the
>>>whole story. I.e. that compile time/runtime distinction is a kind of
>>>red herring.
>>
>>I agree. I think that instead of "statically typed" we should say
>>"typed" and instead of "(dynamically|latently) typed" we should say
>>"untyped".
[...]
>>>It's certainly close enough to say that the *language* is untyped.
>>
>>Indeed. Either a language has a type system and is typed or has no
>>type system and is untyped. I see very little room for confusion
>>here. In my experience, the people who confuse these things are
>>people from the dynamic/latent camp who wish to see types everywhere
>>because they confuse typing with safety or having well-defined
>>semantics.
>
> No. It's because the things that we call latent types we use for the
> same purpose that programmers of static typed languages use static
> types for.
>
> Statically typed programmers ensure that the value of some expression
> is of some type by having the compiler check it. Programmers of
> latently typed languages check, if they think it's important, by asking
> what the type of the result is.
>
> The objection here is that advocates of statically typed language seem
> to be claiming the "type" as their own word, and asking that others use
> their definitions of typing, which are really specific to their
> subjects of interest.
As far as I can tell, the people who advocate using "typed" and "untyped"
in this way are people who just want to be able to discuss all languages in
a unified terminological framework, and many of them are specifically not
advocates of statically typed languages.
--
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
------------------------------
Date: 21 Jun 2006 15:04:23 -0700
From: "Greg Buchholz" <sleepingsquirrel@yahoo.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150927463.340542.65690@g10g2000cwb.googlegroups.com>
George Neuner wrote:
> You can't totally prevent it ... if the index computation involves
> types having a wider range, frequently the solution is to compute a
> wide index value and then narrow it. But if the wider value is out of
> range for the narrow type you have a problem.
>
...snip...
>
> The point is really that the checks that prevent these things must be
> performed at runtime and can't be prevented by any practical type
> analysis performed at compile time. I'm not a type theorist but my
> opinion is that a static type system that could, a priori, prevent the
> problem is impossible.
I haven't been following this thread too closely, but I thought the
following article might be of interest...
Eliminating Array Bound Checking through Non-dependent types.
http://okmij.org/ftp/Haskell/types.html#branding
"There is a view that in order to gain static assurances such as an
array index being always in range or tail being applied to a non-empty
list, we must give up on something significant: on data structures such
as arrays (to be replaced with nested tuples), on general recursion, on
annotation-free programming, on clarity of code, on well-supported
programming languages. That does not have to be the case. The present
messages show non-trivial examples involving native Haskell arrays,
index computations, and general recursion. All arrays indexing
operations are statically guaranteed to be safe -- and so we can safely
use an efficient unsafeAt provided by GHC seemingly for that purpose.
The code is efficient; the static assurances cost us no run-time
overhead. The example uses only Haskell98 + higher-ranked types. No new
type classes are introduced. The safety is based on: Haskell type
system, quantified type variables, and a compact general-purpose
trusted kernel."
------------------------------
Date: 21 Jun 2006 18:04:29 -0400
From: Chris F Clark <cfc@shell01.TheWorld.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <sdd7j3aupw2.fsf@shell01.TheWorld.com>
Chris F Clark schrieb:
> In that sense, a static type system is eliminating tags, because the
> information is pre-computed and not explicitly stored as a part of the
> computation. Now, you may not view the tag as being there, but in my
> mind if there exists a way of perfoming the computation that requires
> tags, the tag was there and that tag has been eliminated.
Joachim Durchholz replied:
> On a semantic level, the tag is always there - it's the type (and
> definitely part of an axiomatic definition of the language).
> Tag elimination is "just" an optimization.
I agree the tag is always there in the abstract.
However, for the work I do the optimization of the tag at runtime is
important, and we specifically change things into types when we know
the system can do that optimization, because then we are getting the
system to do the work we would have to do and validating that the job
is done correctly. So, I care that the tag is eliminated in practice
(and remains in theory--I have to have both).
In the end, I'm trying to fit things which are "too big" and "too
slow" into much less space and time, using types to help me reliably
make my program smaller and faster is just one trick. It's a really
great and non-obvious one though, and one I'm glad I learned. Any
algebra I can learn that helps me solve my problems better is
appreciated.
However, I also know that my way of thinking about it is fringe. Most
people don't think that the purpose of types is to help one write
reliably tighter code.
Still, knowing about dynmic typing (tagging) and static typing, helped
me understand this trick. Thus, conflating the two meanings may at
some level be confusing. However, for me, they aided understanding
something that I needed to learn.
-Chris
------------------------------
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 9336
***************************************
