[27970] in Perl-Users-Digest
Perl-Users Digest, Issue: 9334 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Jun 21 14:10:20 2006
Date: Wed, 21 Jun 2006 11:10:10 -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: 9334
Today's topics:
Re: What is Expressiveness in a Computer Language <find@my.address.elsewhere>
Re: What is Expressiveness in a Computer Language <david.nospam.hopwood@blueyonder.co.uk>
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 <david.nospam.hopwood@blueyonder.co.uk>
Re: What is Expressiveness in a Computer Language <rvtol+news@isolution.nl>
Re: What is Expressiveness in a Computer Language <jo@durchholz.org>
Re: What is Expressiveness in a Computer Language <marshall.spight@gmail.com>
Re: What is Expressiveness in a Computer Language <dnew@san.rr.com>
Re: What is Expressiveness in a Computer Language <marshall.spight@gmail.com>
Re: What is Expressiveness in a Computer Language <find@my.address.elsewhere>
Re: What is Expressiveness in a Computer Language <find@my.address.elsewhere>
Re: What is Expressiveness in a Computer Language <robert.thorpe@antenova.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 <robert.thorpe@antenova.com>
Re: What is Expressiveness in a Computer Language <vesa.karvonen@cs.helsinki.fi>
Re: What is Expressiveness in a Computer Language <dima@127.0.0.1>
Re: What is Expressiveness in a Computer Language <robert.thorpe@antenova.com>
Re: What is Expressiveness in a Computer Language <rossberg@ps.uni-sb.de>
Re: What is Expressiveness in a Computer Language <vesa.karvonen@cs.helsinki.fi>
Re: What is Expressiveness in a Computer Language <robert.thorpe@antenova.com>
Re: What is Expressiveness in a Computer Language <rossberg@ps.uni-sb.de>
Re: What is Expressiveness in a Computer Language <dnew@san.rr.com>
Re: What is Expressiveness in a Computer Language <david.nospam.hopwood@blueyonder.co.uk>
Re: What is Expressiveness in a Computer Language <robert.thorpe@antenova.com>
Re: What is Expressiveness in a Computer Language <rossberg@ps.uni-sb.de>
Re: What is Expressiveness in a Computer Language <dnew@san.rr.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 21 Jun 2006 10:05:53 -0500
From: Matthias Blume <find@my.address.elsewhere>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <m1wtbaft0u.fsf@hana.uchicago.edu>
"Rob Thorpe" <robert.thorpe@antenova.com> writes:
>> >> > No it doesn't. Casting reinterprets a value of one type as a value of
>> >> > another type.
>> >> > There is a difference. If I cast an unsigned integer 2000000000 to a
>> >> > signed integer in C on the machine I'm using then the result I will get
>> >> > will not make any sense.
>> >>
>> >> Which result are you getting? What does it mean to "make sense"?
>> >
>> > Well the right one actually, bad example.
>> >
>> > But, if I cast an unsigned int 2500000000 to signed I get -1794967296.
>>
>> So, why do you think this "does not make sense"?
>
> Well, it makes sense in terms of the C spec certainly.
> It does not make sense in that it does not emit an error.
Why not?
------------------------------
Date: Wed, 21 Jun 2006 15:07:26 GMT
From: David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <Ogdmg.443406$tc.367810@fe2.news.blueyonder.co.uk>
Rob Thorpe wrote:
> Matthias Blume wrote:
>>"Rob Thorpe" <robert.thorpe@antenova.com> writes:
>>
>>>I think we're discussing this at cross-purposes. In a language like C
>>>or another statically typed language there is no information passed
>>>with values indicating their type.
>>
>>You seem to be confusing "does not have a type" with "no type
>>information is passed at runtime".
>>
>>>Have a look in a C compiler if you don't believe me.
>>
>>Believe me, I have.
>
> In a C compiler the compiler has no idea what the values are in the program.
> It knows only their type in that it knows the type of the variable they
> are contained within.
> Would you agree with that?
No. In any language, it may be possible to statically infer that the
value of an expression will belong to a set of values smaller than that
allowed by the expression's type in that language's type system. For
example, all constants have a known value, but most constants have a
type which allows more than one value.
(This is an essential point, not just nitpicking.)
--
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
------------------------------
Date: 21 Jun 2006 08:09:06 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150902546.400454.219430@i40g2000cwc.googlegroups.com>
Joachim Durchholz wrote:
>
> 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 see what you're saying, but the distinction is a bit fine for me.
If the language has no possible mechanism to observe the
it-was-only-eliminated-as-an-optimization tag, in what sense
is it "always there?" E.g. The 'C' programming language.
Marshall
------------------------------
Date: 21 Jun 2006 08:12:11 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150902731.828394.175560@m73g2000cwd.googlegroups.com>
David Hopwood wrote:
>
> Oh, but it *does* make sense to talk about dynamic tagging in a statically
> typed language.
>
> That's part of what makes the term "dynamically typed" harmful: it implies
> a dichotomy between "dynamically typed" and "statically typed" languages,
> when in fact dynamic tagging and static typing are (mostly) independent
> features.
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.
Marshall
------------------------------
Date: Wed, 21 Jun 2006 15:29:30 GMT
From: David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <uBdmg.464152$xt.338218@fe3.news.blueyonder.co.uk>
Chris Uppal wrote:
> It's worth noting, too, that (in some sense) the type of an object can change
> over time[*]. That can be handled readily (if not perfectly) in the informal
> internal type system(s) which programmers run in their heads (pace the very
> sensible post by Anton van Straaten today in this thread -- several branches
> away), but cannot be handled by a type system based on sets-of-values (and is
> also a counter-example to the idea that "the" dynamic type of an object/value
> can be identified with its tag).
>
> ([*] if the set of operations in which it can legitimately partake changes.
> That can happen explicitly in Smalltalk (using DNU proxies for instance if the
> proxied object changes, or even using #becomeA:), but can happen anyway in less
> "free" languages -- the State Pattern for instance, or even (arguably) in the
> difference between an empty list and a non-empty list).
Dynamic changes in object behaviour are not incompatible with type systems based
on sets of values (e.g. semantic subtyping). There are some tricky issues in
making such a system work, and I'm not aware of any implemented language that
does it currently, but in principle it's quite feasible.
For a type system that can handle dynamic proxying, see
<http://www.doc.ic.ac.uk/~scd/FOOL11/FCM.pdf>.
--
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
------------------------------
Date: Wed, 21 Jun 2006 17:17:22 +0200
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <e7bv9v.1f8.1@news.isolution.nl>
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.
--
Affijn, Ruud
"Gewoon is een tijger."
------------------------------
Date: Wed, 21 Jun 2006 17:34:19 +0200
From: Joachim Durchholz <jo@durchholz.org>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <e7botf$g92$1@online.de>
Andreas Rossberg schrieb:
> Chris Uppal wrote:
>
>> It's worth noting, too, that (in some sense) the type of an object can
>> change over time[*].
>
> No. Since a type expresses invariants, this is precisely what may *not*
> happen.
No. A type is a set of allowable values, allowable operations, and
constraints on the operations (which are often called "invariants" but
they are invariant only as long as the type is invariant).
I very much agree that the association of a type with a value or a name
should be constant over their lifetime - but that doesn't follow from
the definition of "type", it follows from general maintainability
considerations (quite strong ones actually).
Regards,
Jo
------------------------------
Date: 21 Jun 2006 08:35:34 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150904134.520639.71070@b68g2000cwa.googlegroups.com>
Nice post! One question:
Anton van Straaten wrote:
>
> 3. A really natural term to refer to types which programmers reason
> about, even if they are not statically checked, is "latent types". It
> captures the situation very well intuitively, and it has plenty of
> precedent -- e.g. it's mentioned in the Scheme reports, R5RS and its
> predecessors, going back at least a decade or so (haven't dug to check
> when it first appeared).
Can you be more explicit about what "latent types" means?
I'm sorry to say it's not at all natural or intuitive to me.
Are you referring to the types in the programmers head,
or the ones at runtime, or what?
Marshall
------------------------------
Date: Wed, 21 Jun 2006 15:42:05 GMT
From: Darren New <dnew@san.rr.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <hNdmg.19752$uy3.9114@tornado.socal.rr.com>
Chris Uppal wrote:
> doesn't fit with my intuitions very well -- most noticeably in that the sets
> are generally unbounded
Errr, not in Ada. Indeed, not in any machine I know of with a limited
address space.
Andreas Rossberg wrote:
> Indeed, this view is much too narrow. In particular, it cannot explain
> abstract types, which is *the* central aspect of decent type systems.
Well, it's Ada's view. I didn't say it was right for theoretical
languages or anything like that. As far as I know, LOTOS is the only
language that *actually* uses abstract data types - you have to use the
equivalent of #include to bring in the integers, for example. Everything
else uses informal rules to say how types work.
But Ada's definition gives you a very nice way of talking about things
like whether integers that overflow are the same type as integers that
don't overflow, or whether an assignment of an integer to a positive is
legal, or adding a CountOfApples to a CountOfOranges is legal, or
whether passing a "Dog" object to an "Animal" function parameter makes
sense in a particular context.
Indeed, the ability to declare a new type that has the exact same
underlying representation and isomorphically identical operations but
not be the same type is something I find myself often missing in
languages. It's nice to be able to say "this integer represents vertical
pixel count, and that represents horizontal pixel count, and you don't
get to add them together."
--
Darren New / San Diego, CA, USA (PST)
My Bath Fu is strong, as I have
studied under the Showerin' Monks.
------------------------------
Date: 21 Jun 2006 08:41:15 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150904475.363283.234730@y41g2000cwy.googlegroups.com>
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.
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.*
Let's call it a named constant.
Marshall
------------------------------
Date: Wed, 21 Jun 2006 10:53:25 -0500
From: Matthias Blume <find@my.address.elsewhere>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <m1zmg6ld3e.fsf@hana.uchicago.edu>
"Marshall" <marshall.spight@gmail.com> writes:
> Torben Ęgidius 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 = can't change
> vary-able = can change
>
> Clearly a contradiction in terms.
No, it is not a contradiction. See the mathematical usage of the word
"variable". 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.
> 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.
------------------------------
Date: Wed, 21 Jun 2006 10:56:22 -0500
From: Matthias Blume <find@my.address.elsewhere>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <m1vequlcyh.fsf@hana.uchicago.edu>
Darren New <dnew@san.rr.com> writes:
> [ ... ] As far as I know, LOTOS is the only
> language that *actually* uses abstract data types - you have to use
> the equivalent of #include to bring in the integers, for
> example. Everything else uses informal rules to say how types work.
There are *tons* of languages that "actually" facilitate abstract data
types, and some of these languages are actually used by real people.
------------------------------
Date: 21 Jun 2006 08:59:26 -0700
From: "Rob Thorpe" <robert.thorpe@antenova.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150905566.142680.246550@u72g2000cwu.googlegroups.com>
Matthias Blume wrote:
> "Rob Thorpe" <robert.thorpe@antenova.com> writes:
>
> >> >> > No it doesn't. Casting reinterprets a value of one type as a value of
> >> >> > another type.
> >> >> > There is a difference. If I cast an unsigned integer 2000000000 to a
> >> >> > signed integer in C on the machine I'm using then the result I will get
> >> >> > will not make any sense.
> >> >>
> >> >> Which result are you getting? What does it mean to "make sense"?
> >> >
> >> > Well the right one actually, bad example.
> >> >
> >> > But, if I cast an unsigned int 2500000000 to signed I get -1794967296.
> >>
> >> So, why do you think this "does not make sense"?
> >
> > Well, it makes sense in terms of the C spec certainly.
> > It does not make sense in that it does not emit an error.
>
> Why not?
Well it's really a matter of perspective isn't it. In some cases it
may even be what the programmer intends.
>From my perspective I don't expect a large positive number to turn into
a negative one just because I've requested that it be signed. The
behaviour I would expect is that either the variable being set gets the
right number, or an error occurs. I don't care if the reporting is at
runtime or compile time, so long as it can be seen.
--
Anyway, this is a small point. Does the fact that you only disagreed
with me on this point indicate that you agreed with everything else?
... Only joking :) I think you and I have irreconcilable views on this
subject.
I think we can agree that value mostly have some sort of type in a
statically typed language. You may say that they have directly have
types, but I can't see how that can be, as far as I can see they have
types only indirectly. This is only a minor point though.
The issue of typing of values vs variables is not practically
meaningless though.
The main problem I find with statically typed programs is that much of
the world outside the program is not statically typed. Library and API
writers in-particular seem to treat static typing carelessly. As a
result it's not generally possible to write a program meaningfully
inside the static type system, as the type systems designers intended.
You're force to break it all over the place with casts etc anyway. And
at every place you break it the possibility of error occurs and flow
from that place into the rest of the program. So, you end up actually
checking the values of variables rather than relying on their types
anyway. And this can be difficult because their values have no
associated information telling you their types.
It's different writing a function deep inside a large program, in this
case data can be cleaned up beforehand. And in this case the static
typing works are intended and becomes more useful.
Anyway, I don't think it would help either of us to continue this
sub-thread any more. Feel free to reply to this post, but I might not
reply back.
Static typing is rather off topic on most of the newsgroups this thread
is in anyway, and I suspect the people in them are getting rather sick
of it.
------------------------------
Date: Wed, 21 Jun 2006 17:45:18 +0200
From: Andreas Rossberg <rossberg@ps.uni-sb.de>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <e7bpie$8v164$4@hades.rz.uni-saarland.de>
Marshall wrote:
>
> While we're on the topic of terminology, here's a pet peeve of
> mine: "immutable variable."
>
> immutable = can't change
> vary-able = can change
>
> Clearly a contradiction in terms.
>
> 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.*
> Let's call it a named constant.
The name of a function argument is a variable. Its denotation changes
between calls. Still it cannot be mutated. Likewise, local "constants"
depending on an argument are not constant.
- Andreas
------------------------------
Date: Wed, 21 Jun 2006 17:52:54 +0200
From: Andreas Rossberg <rossberg@ps.uni-sb.de>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <e7bq0m$8v164$5@hades.rz.uni-saarland.de>
Joachim Durchholz wrote:
>>
>>> It's worth noting, too, that (in some sense) the type of an object
>>> can change over time[*].
>>
>> No. Since a type expresses invariants, this is precisely what may
>> *not* happen.
>
> No. A type is a set of allowable values, allowable operations, and
> constraints on the operations (which are often called "invariants" but
> they are invariant only as long as the type is invariant).
The purpose of a type system is to derive properties that are known to
hold in advance. A type is the encoding of these properties. A type
varying over time is an inherent contradiction (or another abuse of the
term "type").
- Andreas
------------------------------
Date: 21 Jun 2006 09:04:35 -0700
From: "Rob Thorpe" <robert.thorpe@antenova.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150905875.552388.44170@y41g2000cwy.googlegroups.com>
David Hopwood wrote:
> Rob Thorpe wrote:
> > Matthias Blume wrote:
> >>"Rob Thorpe" <robert.thorpe@antenova.com> writes:
> >>
> >>>I think we're discussing this at cross-purposes. In a language like C
> >>>or another statically typed language there is no information passed
> >>>with values indicating their type.
> >>
> >>You seem to be confusing "does not have a type" with "no type
> >>information is passed at runtime".
> >>
> >>>Have a look in a C compiler if you don't believe me.
> >>
> >>Believe me, I have.
> >
> > In a C compiler the compiler has no idea what the values are in the program.
> > It knows only their type in that it knows the type of the variable they
> > are contained within.
> > Would you agree with that?
>
> No. In any language, it may be possible to statically infer that the
> value of an expression will belong to a set of values smaller than that
> allowed by the expression's type in that language's type system. For
> example, all constants have a known value, but most constants have a
> type which allows more than one value.
>
> (This is an essential point, not just nitpicking.)
Yes, I agree. That does not apply in general though.
In general the value of the variable could be, for example, read from a
file, in which case the compiler may know it's type, but not any more.
I was talking about the general case.
------------------------------
Date: 21 Jun 2006 16:04:44 GMT
From: Vesa Karvonen <vesa.karvonen@cs.helsinki.fi>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <e7bqms$pb8$1@oravannahka.helsinki.fi>
In comp.lang.functional Anton van Straaten <anton@appsolutions.com> wrote:
[...]
This static vs dynamic type thing reminds me of one article written by
Bjarne Stroustrup where he notes that "Object-Oriented" has become a
synonym for "good". More precisely, it seems to me that both camps
(static & dynamic) think that "typed" is a synonym for having
"well-defined semantics" or being "safe" and therefore feel the need
to be able to speak of their language as "typed" whether or not it
makes sense.
> 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".
> In a statically-checked language, people tend to confuse automated
> static checking with the existence of types, because they're thinking in
> a strictly formal sense: they're restricting their world view to what
> they see "within" the language.
That is not unreasonable. You see, you can't have types unless you
have a type system. Types without a type system are like answers
without questions - it just doesn't make any sense.
> Then they look at programs in a dynamically-checked language, and see
> checks happening at runtime, and they assume that this means that the
> program is "untyped".
Not in my experience. Either a *language* specifies a type system or
not. There is little room for confusion. Well, at least unless you
equate "typing" with being "well-defined" or "safe" and go to great
lengths to convince yourself that your program has "latent types" even
without specifying a type system.
> 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.
> But a program as seen by the programmer has types: the programmer
> performs (static) type inference when reasoning about the program, and
> debugs those inferences when debugging the program, finally ending up
> with a program which has a perfectly good type scheme. It's may be
> messy compared to say an HM type scheme, and it's usually not proved to
> be perfect, but that again is an orthogonal issue.
There is a huge hole in your argument above. Types really do not make
sense without a type system. To claim that a program has a type
scheme, you must first specify the type system. Otherwise it just
doesn't make any sense.
> Mathematicians operated for thousands of years without automated
> checking of proofs, so you can't argue that because a
> dynamically-checked program hasn't had its type scheme proved correct,
> that it somehow doesn't have types. That would be a bit like arguing
> that we didn't have Math until automated theorem provers came along.
No - not at all. First of all, mathematics has matured quite a bit
since the early days. I'm sure you've heard of the axiomatic method.
However, what you are missing is that to prove that your program has
types, you first need to specify a type system. Similarly, to prove
something in math you start by specifying [fill in the rest].
> 1. "Untyped" is really quite a misleading term, unless you're talking
> about something like the untyped lambda calculus. That, I will agree,
> can reasonably be called untyped.
Untyped is not misleading. "Typed" is not a synonym for "safe" or
"having well-defined semantics".
> So, will y'all just switch from using "dynamically typed" to "latently
> typed"
I won't (use "latently typed"). At least not without further
qualification.
-Vesa Karvonen
------------------------------
Date: Wed, 21 Jun 2006 16:12:48 +0000 (UTC)
From: Dimitri Maziuk <dima@127.0.0.1>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <slrne9is00.fr.dima@yellowtail.bmrb.wisc.edu>
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.
HTH
Dima
--
I have not been able to think of any way of describing Perl to [person]
"Hello, blind man? This is color." -- DPM
------------------------------
Date: 21 Jun 2006 09:27:23 -0700
From: "Rob Thorpe" <robert.thorpe@antenova.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150907242.960017.79600@r2g2000cwb.googlegroups.com>
Rob Thorpe wrote:
> Chris Smith wrote:
> > Torben =C6gidius Mogensen <torbenm@app-3.diku.dk> wrote:
> > > That's not really the difference between static and dynamic typing.
> > > Static typing means that there exist a typing at compile-time that
> > > guarantess against run-time type violations. Dynamic typing means
> > > that such violations are detected at run-time. This is orthogonal to
> > > strong versus weak typing, which is about whether such violations are
> > > detected at all. The archetypal weakly typed language is machine code
> > > -- you can happily load a floating point value from memory, add it to
> > > a string pointer and jump to the resulting value. ML and Scheme are
> > > both strongly typed, but one is statically typed and the other
> > > dynamically typed.
> >
> > Knowing that it'll cause a lot of strenuous objection, I'll nevertheless
> > interject my plea not to abuse the word "type" with a phrase like
> > "dynamically typed". If anyone considers "untyped" to be perjorative,
> > as some people apparently do, then I'll note that another common term is
> > "type-free," which is marketing-approved but doesn't carry the
> > misleading connotations of "dynamically typed." We are quickly losing
> > any rational meaning whatsoever to the word "type," and that's quite a
> > shame.
>
> I don't think dynamic typing is that nebulous. I remember this being
> discussed elsewhere some time ago, I'll post the same reply I did then
> ..
> A language is statically typed if a variable has a property - called
> it's type - attached to it, and given it's type it can only represent
> values defined by a certain class.
>
> A language is latently typed if a value has a property - called it's
> type - attached to it, and given it's type it can only represent values
> defined by a certain class.
>
> Some people use dynamic typing as a word for latent typing, others use
> it to mean something slightly different. But for most purposes the
> definition above works for dynamic typing also.
>
> Untyped and type-free mean something else: they mean no type checking
> is done.
Since people have found some holes in this definition I'll have another
go:-
Firstly, a definition, General expression (gexpr) are variables
(mutable or immutable), expressions and the entities functions return.
A statically typed language has a parameter associated with each gexpr
called it's type. The code may test the type of a gexpr. The language
will check if the gexprs of an operator/function have types that match
what is required, to some criteria of sufficiency. It will emit an
error/warning when they don't. It will do so universally.
A latently typed language has a parameter associated with each value
called it's type. The code may test the type of a value. The language
may check if the gexprs of an operator/function have types that match
what is required, to some criteria of sufficiency. It will not
necessarily do so universally.
An untyped language is one that does not possess either a static or
latent type system. In an untyped language gexprs possess no type
information, and neither do values.
--
These definitions still have problems, they don't say anything about
languages that sit between the various categories for example. I don't
know where HM type system would come in them.
------------------------------
Date: Wed, 21 Jun 2006 18:01:29 +0200
From: Andreas Rossberg <rossberg@ps.uni-sb.de>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <e7bqgp$8v164$6@hades.rz.uni-saarland.de>
Darren New wrote:
>
> As far as I know, LOTOS is the only
> language that *actually* uses abstract data types
Maybe I don't understand what you mean with ADT here, but all languages
with a decent module system support ADTs in the sense it is usually
understood, see ML for a primary example. Classes in most OOPLs are
essentially beefed-up ADTs as well.
> Indeed, the ability to declare a new type that has the exact same
> underlying representation and isomorphically identical operations but
> not be the same type is something I find myself often missing in
> languages. It's nice to be able to say "this integer represents vertical
> pixel count, and that represents horizontal pixel count, and you don't
> get to add them together."
Not counting C/C++, I don't know when I last worked with a typed
language that does *not* have this ability... (which is slightly
different from ADTs, btw)
- Andreas
------------------------------
Date: 21 Jun 2006 16:36:10 GMT
From: Vesa Karvonen <vesa.karvonen@cs.helsinki.fi>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <e7bshq$pqk$1@oravannahka.helsinki.fi>
In comp.lang.functional Andreas Rossberg <rossberg@ps.uni-sb.de> wrote:
> Darren New wrote:
[...]
> > Indeed, the ability to declare a new type that has the exact same
> > underlying representation and isomorphically identical operations but
> > not be the same type is something I find myself often missing in
> > languages. It's nice to be able to say "this integer represents vertical
> > pixel count, and that represents horizontal pixel count, and you don't
> > get to add them together."
> Not counting C/C++, I don't know when I last worked with a typed
> language that does *not* have this ability... (which is slightly
> different from ADTs, btw)
Would Java count?
-Vesa Karvonen
------------------------------
Date: 21 Jun 2006 09:55:52 -0700
From: "Rob Thorpe" <robert.thorpe@antenova.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150908952.804184.218990@r2g2000cwb.googlegroups.com>
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".
>
> > In a statically-checked language, people tend to confuse automated
> > static checking with the existence of types, because they're thinking in
> > a strictly formal sense: they're restricting their world view to what
> > they see "within" the language.
>
> That is not unreasonable. You see, you can't have types unless you
> have a type system. Types without a type system are like answers
> without questions - it just doesn't make any sense.
>
> > Then they look at programs in a dynamically-checked language, and see
> > checks happening at runtime, and they assume that this means that the
> > program is "untyped".
>
> Not in my experience. Either a *language* specifies a type system or
> not. There is little room for confusion. Well, at least unless you
> equate "typing" with being "well-defined" or "safe" and go to great
> lengths to convince yourself that your program has "latent types" even
> without specifying a type system.
The question is: What do you mean by "type system"?
Scheme and Lisp both define how types work in their specifications
clearly, others may do too, I don't know.
Of-course you may not consider that as a type system if you mean "type
system" to mean a static type system.
> > 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. This doesn't help advocates of static languages/
latently typed languages, or anyone else. It doesn't help because
no-one else is likely to change their use of terms, there's no reason
why they would. All that may happen is that users of statically typed
languages change the words they use. This would confuse me, for one. I
would much rather understand what ML programmers, for example, are
saying and that's hard enough as it is.
There's also my other objection, if you consider latently typed
languages untyped, then what is assembly?
------------------------------
Date: Wed, 21 Jun 2006 18:50:35 +0200
From: Andreas Rossberg <rossberg@ps.uni-sb.de>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <e7btcr$8v164$7@hades.rz.uni-saarland.de>
Vesa Karvonen wrote:
>
>>>Indeed, the ability to declare a new type that has the exact same
>>>underlying representation and isomorphically identical operations but
>>>not be the same type is something I find myself often missing in
>>>languages. It's nice to be able to say "this integer represents vertical
>>>pixel count, and that represents horizontal pixel count, and you don't
>>>get to add them together."
>
>>Not counting C/C++, I don't know when I last worked with a typed
>>language that does *not* have this ability... (which is slightly
>>different from ADTs, btw)
>
> Would Java count?
Yes, you are right. And there certainly are more in the OO camp.
But honestly, I do not remember when I last had to actively work with
one of them, including Java... :-)
- Andreas
------------------------------
Date: Wed, 21 Jun 2006 17:12:40 GMT
From: Darren New <dnew@san.rr.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <c6fmg.15242$Z67.7053@tornado.socal.rr.com>
Andreas Rossberg wrote:
> Maybe I don't understand what you mean with ADT here, but all languages
> with a decent module system support ADTs in the sense it is usually
> understood, see ML for a primary example.
OK. Maybe some things like ML and Haskell and such that I'm not
intimately familiar with do, now that you mention it, yes.
> Classes in most OOPLs are essentially beefed-up ADTs as well.
Err, no. There's nothing really abstract about them. And their values
are mutable. So while one can think about them as an ADT, one actually
has to write code to (for example) calculate or keep track of how many
entries are on a stack, if you want that information.
> Not counting C/C++, I don't know when I last worked with a typed
> language that does *not* have this ability... (which is slightly
> different from ADTs, btw)
Java? C#? Icon? Perl? (Hmmm... Pascal does, IIRC.) I guess you just work
with better languages than I do. :-)
--
Darren New / San Diego, CA, USA (PST)
My Bath Fu is strong, as I have
studied under the Showerin' Monks.
------------------------------
Date: Wed, 21 Jun 2006 17:24:42 GMT
From: David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <uhfmg.445208$tc.122076@fe2.news.blueyonder.co.uk>
Marshall wrote:
> Torben =C6gidius Mogensen wrote:
>=20
>>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).
>=20
> While we're on the topic of terminology, here's a pet peeve of
> mine: "immutable variable."
>=20
> immutable =3D can't change
> vary-able =3D can change
>=20
> Clearly a contradiction in terms.
But one that is at least two hundred years old [*], and so unlikely to be=
fixed now.
In any case, the intent of this usage (in both mathematics and programmin=
g)
is that different *instances* of a variable can be associated with differ=
ent
values.
[*] introduced by Leibniz, according to <http://members.aol.com/jeff570/v=
=2Ehtml>,
but that was presumably in Latin. The first use of "variable" as a no=
un
recorded by the OED in written English is in 1816.
--=20
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
------------------------------
Date: 21 Jun 2006 10:29:36 -0700
From: "Rob Thorpe" <robert.thorpe@antenova.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150910976.455179.55870@r2g2000cwb.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.
That's not the same thing. 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.
------------------------------
Date: Wed, 21 Jun 2006 19:24:15 +0200
From: Andreas Rossberg <rossberg@ps.uni-sb.de>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <e7bvbv$8v164$8@hades.rz.uni-saarland.de>
Darren New wrote:
>
>> Maybe I don't understand what you mean with ADT here, but all
>> languages with a decent module system support ADTs in the sense it is
>> usually understood, see ML for a primary example.
>
> OK. Maybe some things like ML and Haskell and such that I'm not
> intimately familiar with do, now that you mention it, yes.
Well, Modula and CLU already had this, albeit in restricted form.
>> Classes in most OOPLs are essentially beefed-up ADTs as well.
>
> Err, no. There's nothing really abstract about them. And their values
> are mutable. So while one can think about them as an ADT, one actually
> has to write code to (for example) calculate or keep track of how many
> entries are on a stack, if you want that information.
Now you lost me completely. What has mutability to do with it? And the
stack?
AFAICT, ADT describes a type whose values can only be accessed by a
certain fixed set of operations. Classes qualify for that, as long as
they provide proper encapsulation.
>> Not counting C/C++, I don't know when I last worked with a typed
>> language that does *not* have this ability... (which is slightly
>> different from ADTs, btw)
>
> Java? C#? Icon? Perl? (Hmmm... Pascal does, IIRC.) I guess you just work
> with better languages than I do. :-)
OK, I admit that I exaggerated slightly. Although currently I'm indeed
able to mostly work with the more pleasant among languages. :-)
(Btw, Pascal did not have it either, AFAIK)
- Andreas
------------------------------
Date: Wed, 21 Jun 2006 17:43:37 GMT
From: Darren New <dnew@san.rr.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <dzfmg.3585$MF6.270@tornado.socal.rr.com>
Andreas Rossberg wrote:
> AFAICT, ADT describes a type whose values can only be accessed by a
> certain fixed set of operations.
No. AFAIU, an ADT defines the type based on the operations. The stack
holding the integers 1 and 2 is the value (push(2, push(1, empty()))).
There's no "internal" representation. The values and operations are
defined by preconditions and postconditions.
Both a stack and a queue could be written in most languages as "values
that can only be accessed by a fixed set of operations" having the same
possible internal representations and the same function signatures.
They're far from the same type, because they're not abstract. The part
you can't see from outside the implementation is exactly the part that
defines how it works.
Granted, it's a common mistake to write that some piece of C++ code
implements a stack ADT.
For example, an actual ADT for a stack (and a set) is shown on
http://www.cs.unc.edu/~stotts/danish/web/userman/umadt.html
Note that the "axia" for the stack type completely define its operation
and semantics. There is no other "implementation" involved. And in LOTOS
(which uses ACT.1 or ACT.ONE (I forget which)) as its type, this is
actually how you'd write the code for a stack, and then the compiler
would crunch a while to figure out a corresponding implementation.
I suspect "ADT" is by now so corrupted that it's useful to use a
different term, such as "algebraic type" or some such.
> Classes qualify for that, as long as they provide proper encapsulation.
Nope.
> OK, I admit that I exaggerated slightly. Although currently I'm indeed
> able to mostly work with the more pleasant among languages. :-)
Yah. :-)
> (Btw, Pascal did not have it either, AFAIK)
I'm pretty sure in Pascal you could say
Type Apple = Integer; Orange = Integer;
and then vars of type apple and orange were not interchangable.
--
Darren New / San Diego, CA, USA (PST)
My Bath Fu is strong, as I have
studied under the Showerin' Monks.
------------------------------
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 9334
***************************************
