[27961] in Perl-Users-Digest
Perl-Users Digest, Issue: 9325 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Jun 20 14:10:15 2006
Date: Tue, 20 Jun 2006 11:10:08 -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 Tue, 20 Jun 2006 Volume: 10 Number: 9325
Today's topics:
Re: What is Expressiveness in a Computer Language <ketil+news@ii.uib.no>
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 <David.Squire@no.spam.from.here.au>
Re: What is Expressiveness in a Computer Language <dnew@san.rr.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 <rossberg@ps.uni-sb.de>
Re: What is Expressiveness in a Computer Language <cfc@shell01.TheWorld.com>
Re: What is Expressiveness in a Computer Language <robert.thorpe@antenova.com>
Re: What is Expressiveness in a Computer Language <robert.thorpe@antenova.com>
Re: What is Expressiveness in a Computer Language <dnew@san.rr.com>
Re: What is Expressiveness in a Computer Language <robert.thorpe@antenova.com>
Re: What is Expressiveness in a Computer Language <gneuner2/@comcast.net>
Re: What is Expressiveness in a Computer Language <eval.apply@gmail.com>
Re: What is Expressiveness in a Computer Language <pc@p-cos.net>
Re: What is Expressiveness in a Computer Language <robert.thorpe@antenova.com>
Re: What is Expressiveness in a Computer Language <robert.thorpe@antenova.com>
Re: What is Expressiveness in a Computer Language <dnew@san.rr.com>
Re: What is Expressiveness in a Computer Language <chris.uppal@metagnostic.REMOVE-THIS.org>
Re: What's ^$ mean? <tadmc@augustmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 20 Jun 2006 17:34:21 +0200
From: Ketil Malde <ketil+news@ii.uib.no>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <eghd2f264i.fsf@polarvier.ii.uib.no>
"Rob Thorpe" <robert.thorpe@antenova.com> writes:
> But it only gaurantees this because the variables themselves have a
> type, the values themselves do not.
I think statements like this are confusing, because there are
different interpretations of what a "value" is. I would say that the
integer '4' is a value, and that it has type Integer (for instance).
This value is different from 4 the Int16, or 4 the double-precision
floating point number. From this viewpoint, all values in statically
typed languages have types, but I think you use 'value' to denote the
representation of a datum in memory, which is a different thing.
-k
--
If I haven't seen further, it is by standing in the footprints of giants
------------------------------
Date: Tue, 20 Jun 2006 10:45:42 -0500
From: Matthias Blume <find@my.address.elsewhere>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <m1mzc7hluh.fsf@hana.uchicago.edu>
Pascal Costanza <pc@p-cos.net> writes:
> - In a dynamically typed language, you can run programs successfully
> that are not acceptable by static type systems.
This statement is false.
For every program that can run successfully to completion there exists
a static type system which accepts that program. Moreover, there is
at least one static type system that accepts all such programs.
What you mean is that for static type systems that are restrictive
enough to be useful in practice there always exist programs which
(after type erasure in an untyped setting, i.e., by switching to a
different language) would run to completion, but which are rejected by
the static type system.
By the way, the parenthetical remark is important: If a language's
definition is based on a static type system, then there are *no*
programs in that language which are rejected by its type checker.
That's trivially so because strings that do not type-check are simply
not considered programs.
> Here is an example in Common Lisp:
>
> ; A class "person" with no superclasses and with the only field "name":
> (defclass person ()
> (name))
>
> ; A test program:
> (defun test ()
> (let ((p (make-instance 'person)))
> (eval (read))
> (slot-value p 'address)))
>
> (slot-value p 'address) is an attempt to access the field 'address in
> the object p. In many languages, the notation for this is p.address.
>
> Although the class definition for person doesn't mention the field
> address, the call to (eval (read)) allows the user to change the
> definition of the class person and update its existing
> instances. Therefore at runtime, the call to (slot-value p 'adress)
> has a chance to succeed.
I am quite comfortable with the thought that this sort of evil would
get rejected by a statically typed language. :-)
------------------------------
Date: Tue, 20 Jun 2006 10:49:23 -0500
From: Matthias Blume <find@my.address.elsewhere>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <m1irmvhloc.fsf@hana.uchicago.edu>
David Squire <David.Squire@no.spam.from.here.au> writes:
> Andreas Rossberg wrote:
>> Rob Thorpe wrote:
>>>>
>>>>> No, that isn't what I said. What I said was:
>>>>> "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."
>>>>
>>>> "it [= a value] [...] can [...] represent values"?
>>>
>>> ???
>> I just quoted, in condensed form, what you said above: namely, that
>> a value represents values - which I find a strange and circular
>> definition.
>>
>
> But you left out the most significant part: "given it's type it can
> only represent values *defined by a certain class*" (my emphasis). In
> C-ish notation:
>
> unsigned int x;
>
> means that x can only represent elements that are integers elements of
> the set (class) of values [0, MAX_INT]. Negative numbers and
> non-integer numbers are excluded, as are all sorts of other things.
This x is not a value. It is a name of a memory location.
> You over-condensed.
Andreas condensed correctly.
------------------------------
Date: Tue, 20 Jun 2006 16:51:43 +0100
From: David Squire <David.Squire@no.spam.from.here.au>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <e795if$6hi$1@news.ox.ac.uk>
Matthias Blume wrote:
> David Squire <David.Squire@no.spam.from.here.au> writes:
>
>> Andreas Rossberg wrote:
>>> Rob Thorpe wrote:
>>>>>> No, that isn't what I said. What I said was:
>>>>>> "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."
>>>>> "it [= a value] [...] can [...] represent values"?
>>>> ???
>>> I just quoted, in condensed form, what you said above: namely, that
>>> a value represents values - which I find a strange and circular
>>> definition.
>>>
>> But you left out the most significant part: "given it's type it can
>> only represent values *defined by a certain class*" (my emphasis). In
>> C-ish notation:
>>
>> unsigned int x;
>>
>> means that x can only represent elements that are integers elements of
>> the set (class) of values [0, MAX_INT]. Negative numbers and
>> non-integer numbers are excluded, as are all sorts of other things.
>
> This x is not a value. It is a name of a memory location.
>
>> You over-condensed.
>
> Andreas condensed correctly.
I should have stayed out of this. I had not realised that it had
degenerated to point-scoring off someone typing "value" when it is clear
from context that he meant "variable".
Bye.
DS
------------------------------
Date: Tue, 20 Jun 2006 15:52:46 GMT
From: Darren New <dnew@san.rr.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <iRUlg.15161$Z67.14450@tornado.socal.rr.com>
Rob Thorpe wrote:
> Yes, but the point is, as the other poster mentioned: values defined by
> a class.
A value can only represent one value, right? Or can a value have
multiple values?
> For example, in lisp:
> "xyz" is a string,
"xyz" cannot represent values from the class of strings. It can only
represent one value.
I think that's what the others are getting at.
>>They all have - the whole purpose of a type system is to ensure that any
>>expression of type T always evaluates to a value of type T.
>
> But it only gaurantees this because the variables themselves have a
> type, the values themselves do not.
Sure they do. 23.5e3 is a "real" in Pascal, and there's no variable there.
("hello" % "there") is illegal in most languages, because the modulo
operator doesn't apply to strings. How could this be determined at
compile time if "hello" and "there" don't have types?
--
Darren New / San Diego, CA, USA (PST)
My Bath Fu is strong, as I have
studied under the Showerin' Monks.
------------------------------
Date: Tue, 20 Jun 2006 10:53:19 -0500
From: Matthias Blume <find@my.address.elsewhere>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <m1ejxjhlhs.fsf@hana.uchicago.edu>
"Rob Thorpe" <robert.thorpe@antenova.com> writes:
> Andreas Rossberg wrote:
>> Rob Thorpe wrote:
>> >>
>> >>>No, that isn't what I said. What I said was:
>> >>>"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."
>> >>
>> >>"it [= a value] [...] can [...] represent values"?
>> >
>> > ???
>>
>> I just quoted, in condensed form, what you said above: namely, that a
>> value represents values - which I find a strange and circular definition.
>
> Yes, but the point is, as the other poster mentioned: values defined by
> a class.
> For example, in lisp:
> "xyz" is a string, #(1 2 3) is an array, '(1 2 3) is a list, 45 is a
> fixed-point number.
> Each item that can be stored has a type, no item can be stored without
> one. The types can be tested. Most dynamic typed languages are like
> that.
Your "types" are just predicates.
> Compare this to an untyped language where types cannot generally be
> tested.
You mean there are no predicates in untyped languages?
>> They all have - the whole purpose of a type system is to ensure that any
>> expression of type T always evaluates to a value of type T.
>
> But it only gaurantees this because the variables themselves have a
> type, the values themselves do not.
Of course they do.
> Most of the time the fact that the
> variable they are held in has a type infers that the value does too.
> But the value itself has no type, in a C program for example I can take
> the value from some variable and recast it in any way I feel and the
> language cannot correct any errors I make because their is no
> information in the variable to indicate what type it is.
Casting in C takes values of one type to values of another type.
>> So when you
>> look at type systems formally then you certainly have to assign types to
>> values, otherwise you couldn't prove any useful property about those
>> systems (esp. soundness).
>
> Yes, but indirectly.
No, this is usually done very directly and very explicitly.
------------------------------
Date: Tue, 20 Jun 2006 10:55:02 -0500
From: Matthias Blume <find@my.address.elsewhere>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <m1ac87hlex.fsf@hana.uchicago.edu>
David Squire <David.Squire@no.spam.from.here.au> writes:
> Matthias Blume wrote:
>> David Squire <David.Squire@no.spam.from.here.au> writes:
>>
>>> Andreas Rossberg wrote:
>>>> Rob Thorpe wrote:
>>>>>>> No, that isn't what I said. What I said was:
>>>>>>> "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."
>>>>>> "it [= a value] [...] can [...] represent values"?
>>>>> ???
>>>> I just quoted, in condensed form, what you said above: namely, that
>>>> a value represents values - which I find a strange and circular
>>>> definition.
>>>>
>>> But you left out the most significant part: "given it's type it can
>>> only represent values *defined by a certain class*" (my emphasis). In
>>> C-ish notation:
>>>
>>> unsigned int x;
>>>
>>> means that x can only represent elements that are integers elements of
>>> the set (class) of values [0, MAX_INT]. Negative numbers and
>>> non-integer numbers are excluded, as are all sorts of other things.
>> This x is not a value. It is a name of a memory location.
>>
>>> You over-condensed.
>> Andreas condensed correctly.
>
> I should have stayed out of this. I had not realised that it had
> degenerated to point-scoring off someone typing "value" when it is
> clear from context that he meant "variable".
If he really had meant "variable" then he would have been completely wrong.
> Bye.
Bye.
------------------------------
Date: Tue, 20 Jun 2006 17:39:28 +0200
From: Andreas Rossberg <rossberg@ps.uni-sb.de>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <e794rg$8usvs$5@hades.rz.uni-saarland.de>
Rob Thorpe wrote:
>Andreas Rossberg wrote:
>>Rob Thorpe wrote:
>>
>>>>>"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."
>>>>
>>>>"it [= a value] [...] can [...] represent values"?
>>>
>>>???
>>
>>I just quoted, in condensed form, what you said above: namely, that a
>>value represents values - which I find a strange and circular definition.
>
> Yes, but the point is, as the other poster mentioned: values defined by
> a class.
I'm sorry, but I still think that the definition makes little sense.
Obviously, a value simply *is* a value, it does not "represent" one, or
several ones, regardless how you qualify that statement.
>>>Well I haven't programmed in any statically typed language where values
>>>have types themselves.
>>
>>They all have - the whole purpose of a type system is to ensure that any
>>expression of type T always evaluates to a value of type T.
>
> But it only gaurantees this because the variables themselves have a
> type,
No, variables are insignificant in this context. You can consider a
language without variables at all (such languages exist, and they can
even be Turing-complete) and still have evaluation, values, and a
non-trivial type system.
> But the value itself has no type
You mean that the type of the value is not represented at runtime? True,
but that's simply because the type system is static. It's not the same
as saying it has no type.
> in a C program for example I can take
> the value from some variable and recast it in any way I feel and the
> language cannot correct any errors I make because their is no
> information in the variable to indicate what type it is.
Nothing in the C spec precludes an implementation from doing just that.
The problem with C rather is that its semantics is totally
underspecified. In any case, C is about the worst example to use when
discussing type systems. For starters, it is totally unsound - which is
what your example exploits.
- Andreas
------------------------------
Date: 20 Jun 2006 12:18:37 -0400
From: Chris F Clark <cfc@shell01.TheWorld.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <sddu06f3in6.fsf@shell01.TheWorld.com>
Chris F Clark wrote:
> A static
> type system eliminates some set of tags on values by syntactic
> analysis of annotations (types) written with or as part of the program
> and detects some of the disallowed compuatations (staticly) at compile
> time.
Adreas relied:
> Explicit annotations are not a necessary ingredient of a type system,
> nor is "eliminating tags" very relevant to its function.
While this is true, I disagree at some level with the second part. By
eliminating tags, I mean allowing one to perform "type safe"
computations without requiring the values to be tagged. One could
argue that the tags were never there. However, many of the
interesting polymorphic computations reaquire either that the values
be tagged or that some other process assures that at each point one
can determine apriori what the correct variant of computation is which
applies.
To me a static type system is one which does this apriori
determination. A dynamic type system does not do a apriori and
instead includes explicit information in the values being computed to
select the corret variant computations.
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.
To put it another way, I consider the tags to be axiomatic. Most
computations involve some decision logic that is driven by distinct
values that have previously been computed. The separation of the
values which drive the compuation one-way versus another is a tag.
That tag can potentially be eliminated by some apriori computation.
In what I do, it is very valuable to move information from being
explicitly represented in the computed result into the tag, so that I
often have distinct "types" (i.e. tags) for an empty list, a list with
one element, a list with two elements, and a longer list. In that
sense, I agree with Chris Smith's assertion that "static typing" is
about asserting general properties of the algorithm/data. These
assertions are important to the way I am manipulating the data. They
are part of my type model, but they may not be part of anyone else's,
and to me toe pass a empty list to a function requiring a list with
two elements is a "type error", because it is something I expect the
type system to detect as incorrect. The fact that no one else may
have that expectation does not seem relevant to me.
Now, to carry this farther, since I expect the type system to validate
that certain values are of certain types and only be used in certain
contexts, I am happy when it does not require certain "tags" to be
actualy present in the data. However, because other bits of code are
polymorphic, I do expect certain values to require tags. In the end,
this is still a win for me. I had certain data elements that in the
abstract had to be represented explicitly. I have encoded that
information into the type system and in some cases the type system is
not using any bits in the computed representation to hold that
information. Whenever that happens, I win and that solves one of the
problems that I need solved.
Thus, a type system is a way for me to express certain axioms about my
algorithm. A dynamic type system encodes those facts as part of the
computation. A static type system pre-calculates certain "theorems"
from my axioms and uses those theorems to allow my algorithm to be
computed without all the facts being stored as part of the computation.
Hopefully, this makes my point of view clear.
-Chris
*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
------------------------------------------------------------------------------
------------------------------
Date: 20 Jun 2006 09:33:59 -0700
From: "Rob Thorpe" <robert.thorpe@antenova.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150821239.077242.236710@y41g2000cwy.googlegroups.com>
Ketil Malde wrote:
> "Rob Thorpe" <robert.thorpe@antenova.com> writes:
>
> > But it only gaurantees this because the variables themselves have a
> > type, the values themselves do not.
>
> I think statements like this are confusing, because there are
> different interpretations of what a "value" is. I would say that the
> integer '4' is a value, and that it has type Integer (for instance).
> This value is different from 4 the Int16, or 4 the double-precision
> floating point number. From this viewpoint, all values in statically
> typed languages have types, but I think you use 'value' to denote the
> representation of a datum in memory, which is a different thing.
Well I haven't been consistent so far :)
But I mean the value as the semantics of the program itself sees it.
Which mostly means the datum in memory.
------------------------------
Date: 20 Jun 2006 09:49:10 -0700
From: "Rob Thorpe" <robert.thorpe@antenova.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150822150.701434.296460@u72g2000cwu.googlegroups.com>
Matthias Blume wrote:
> "Rob Thorpe" <robert.thorpe@antenova.com> writes:
> > Andreas Rossberg wrote:
> >> Rob Thorpe wrote:
> >> >>
> >> >>>No, that isn't what I said. What I said was:
> >> >>>"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."
> >> >>
> >> >>"it [= a value] [...] can [...] represent values"?
> >> >
> >> > ???
> >>
> >> I just quoted, in condensed form, what you said above: namely, that a
> >> value represents values - which I find a strange and circular definition.
> >
> > Yes, but the point is, as the other poster mentioned: values defined by
> > a class.
> > For example, in lisp:
> > "xyz" is a string, #(1 2 3) is an array, '(1 2 3) is a list, 45 is a
> > fixed-point number.
> > Each item that can be stored has a type, no item can be stored without
> > one. The types can be tested. Most dynamic typed languages are like
> > that.
>
> Your "types" are just predicates.
You can call them predicates if you like. Most people programming in
python, perl, or lisp will call them types though.
> > Compare this to an untyped language where types cannot generally be
> > tested.
>
> You mean there are no predicates in untyped languages?
Well, no there aren't. That's what defines a language as untyped.
Of-course you can make them with your own code, in for example
assembler, but that's outside the language.
> >> They all have - the whole purpose of a type system is to ensure that any
> >> expression of type T always evaluates to a value of type T.
> >
> > But it only gaurantees this because the variables themselves have a
> > type, the values themselves do not.
>
> Of course they do.
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. Have a look in a C compiler if you
don't believe me. You store 56 in a location in memory then in most
compilers all that will be store is 56, nothing more. The compiler
relys entirely on the types of the variables to know how to correctly
operate on the values. The values themselves have no type information
associated with them.
> > Most of the time the fact that the
> > variable they are held in has a type infers that the value does too.
> > But the value itself has no type, in a C program for example I can take
> > the value from some variable and recast it in any way I feel and the
> > language cannot correct any errors I make because their is no
> > information in the variable to indicate what type it is.
>
> Casting in C takes values of one type to values of another type.
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.
> >> So when you
> >> look at type systems formally then you certainly have to assign types to
> >> values, otherwise you couldn't prove any useful property about those
> >> systems (esp. soundness).
> >
> > Yes, but indirectly.
>
> No, this is usually done very directly and very explicitly.
No it isn't.
If I say "4 is a integer" that is a direct statement about 4.
If I say "X is and integer and X is 4, therefore 4 is an integer" that
is a slightly less direct statement about 4.
The difference in directness is only small, and much more indirectness
is needed to prove anything useful about a system formally.
------------------------------
Date: Tue, 20 Jun 2006 17:02:23 GMT
From: Darren New <dnew@san.rr.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <zSVlg.19623$uy3.12503@tornado.socal.rr.com>
Rob Thorpe wrote:
> The compiler
> relys entirely on the types of the variables to know how to correctly
> operate on the values. The values themselves have no type information
> associated with them.
int x = (int) (20.5 / 3);
What machine code operations does the "/" there invoke? Integer
division, or floating point division? How did the variables involved in
the expression affect that?
>>Casting in C takes values of one type to values of another type.
> No it doesn't. Casting reinterprets a value of one type as a value of
> another type.
No it doesn't.
int x = (int) 20.5;
There's no point at which bits from the floating point representation
appear in the variable x.
int * x = (int *) 0;
There's nothing that indicates all the bits of "x" are zero, and indeed
in some hardware configurations they aren't.
--
Darren New / San Diego, CA, USA (PST)
My Bath Fu is strong, as I have
studied under the Showerin' Monks.
------------------------------
Date: 20 Jun 2006 10:08:17 -0700
From: "Rob Thorpe" <robert.thorpe@antenova.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150823297.816352.75370@u72g2000cwu.googlegroups.com>
Andreas Rossberg wrote:
> Rob Thorpe wrote:
> >Andreas Rossberg wrote:
> >>Rob Thorpe wrote:
> >>
> >>>>>"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."
> >>>>
> >>>>"it [= a value] [...] can [...] represent values"?
> >>>
> >>>???
> >>
> >>I just quoted, in condensed form, what you said above: namely, that a
> >>value represents values - which I find a strange and circular definition.
> >
> > Yes, but the point is, as the other poster mentioned: values defined by
> > a class.
>
> I'm sorry, but I still think that the definition makes little sense.
> Obviously, a value simply *is* a value, it does not "represent" one, or
> several ones, regardless how you qualify that statement.
You've clipped a lot of context. I'll put some back in, I said:-
> > Yes, but the point is, as the other poster mentioned: values defined by
> > a class.
> > For example, in lisp:
> > "xyz" is a string, #(1 2 3) is an array, '(1 2 3) is a list, 45 is a
> > fixed-point number.
> > Each item that can be stored has a type, no item can be stored without
> > one. The types can be tested. Most dynamic typed languages are like
> > that.
> > Compare this to an untyped language where types cannot generally be
> > tested.
I think this should make it clear. If I have a "xyz" in lisp I know it
is a string.
If I have "xyz" in an untyped language like assembler it may be
anything, two pointers in binary, an integer, a bitfield. There is no
data at compile time or runtime to tell what it is, the programmer has
to remember.
(I'd point out this isn't true of all assemblers, there are some typed
assemblers)
> >>>Well I haven't programmed in any statically typed language where values
> >>>have types themselves.
> >>
> >>They all have - the whole purpose of a type system is to ensure that any
> >>expression of type T always evaluates to a value of type T.
> >
> > But it only gaurantees this because the variables themselves have a
> > type,
>
> No, variables are insignificant in this context. You can consider a
> language without variables at all (such languages exist, and they can
> even be Turing-complete) and still have evaluation, values, and a
> non-trivial type system.
Hmm. You're right, ML is no-where in my definition since it has no
variables.
> > But the value itself has no type
>
> You mean that the type of the value is not represented at runtime? True,
> but that's simply because the type system is static. It's not the same
> as saying it has no type.
Well, is it even represented at compile time?
The compiler doesn't know in general what values will exist at runtime,
it knows only what types variables have. Sometimes it only has partial
knowledge and sometimes the programmer deliberately overrides it. From
what knowledge it you could say it know what types values will have.
> > in a C program for example I can take
> > the value from some variable and recast it in any way I feel and the
> > language cannot correct any errors I make because their is no
> > information in the variable to indicate what type it is.
>
> Nothing in the C spec precludes an implementation from doing just that.
True, that would be an interesting implementation.
> The problem with C rather is that its semantics is totally
> underspecified. In any case, C is about the worst example to use when
> discussing type systems. For starters, it is totally unsound - which is
> what your example exploits.
Yes. Unfortunately it's often necessary to break static type systems.
Regarding C the problem is, what should we discuss instead that would
be understood in all these newsgroups we're discussing this in.
------------------------------
Date: Tue, 20 Jun 2006 13:08:34 -0400
From: George Neuner <gneuner2/@comcast.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <oh9g92djdj8hpekdrmont4rg4jtnighoq1@4ax.com>
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.
George
--
for email reply remove "/" from address
------------------------------
Date: 20 Jun 2006 10:09:01 -0700
From: "Joe Marshall" <eval.apply@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150823341.079992.98350@y41g2000cwy.googlegroups.com>
Chris Smith wrote:
> Joe Marshall <eval.apply@gmail.com> wrote:
> >
> > Agreed. That is why there is the qualifier `dynamic'. This indicates
> > that it is a completely different thing from static types.
>
> If we agree about this, then there is no need to continue this
> discussion. I'm not sure we do agree, though, because I doubt we'd be
> right here in this conversation if we did.
I think we do agree.
The issue of `static vs. dynamic types' comes up about twice a year in
comp.lang.lisp It generally gets pretty heated, but eventually people
come to understand what the other person is saying (or they get bored
and drop out of the conversation - I'm not sure which). Someone always
points out that the phrase `dynamic types' really has no meaning in the
world of static type analysis. (Conversely, the notion of a `static
type' that is available at runtime has no meaning in the dynamic
world.) Much confusion usually follows.
You'll get much farther in your arguments by explaining what you mean
in detail rather than attempting to force a unification of teminology.
You'll also get farther by remembering that many of the people here
have not had much experience with real static type systems. The static
typing of C++ or Java is so primitive that it is barely an example of
static typing at all, yet these are the most common examples of
statically typed languages people typically encounter.
------------------------------
Date: Tue, 20 Jun 2006 19:14:33 +0200
From: Pascal Costanza <pc@p-cos.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <4fqonoF1kfkapU1@individual.net>
Matthias Blume wrote:
> Pascal Costanza <pc@p-cos.net> writes:
>
>> - In a dynamically typed language, you can run programs successfully
>> that are not acceptable by static type systems.
>
> This statement is false.
The example I have given is more important than this statement.
> For every program that can run successfully to completion there exists
> a static type system which accepts that program. Moreover, there is
> at least one static type system that accepts all such programs.
>
> What you mean is that for static type systems that are restrictive
> enough to be useful in practice there always exist programs which
> (after type erasure in an untyped setting, i.e., by switching to a
> different language) would run to completion, but which are rejected by
> the static type system.
No, that's not what I mean.
>> Here is an example in Common Lisp:
>>
>> ; A class "person" with no superclasses and with the only field "name":
>> (defclass person ()
>> (name))
>>
>> ; A test program:
>> (defun test ()
>> (let ((p (make-instance 'person)))
>> (eval (read))
>> (slot-value p 'address)))
>>
>> (slot-value p 'address) is an attempt to access the field 'address in
>> the object p. In many languages, the notation for this is p.address.
>>
>> Although the class definition for person doesn't mention the field
>> address, the call to (eval (read)) allows the user to change the
>> definition of the class person and update its existing
>> instances. Therefore at runtime, the call to (slot-value p 'adress)
>> has a chance to succeed.
>
> I am quite comfortable with the thought that this sort of evil would
> get rejected by a statically typed language. :-)
This sort of feature is clearly not meant for you. ;-P
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
------------------------------
Date: 20 Jun 2006 10:20:33 -0700
From: "Rob Thorpe" <robert.thorpe@antenova.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150824033.452278.45310@c74g2000cwc.googlegroups.com>
Darren New wrote:
> Rob Thorpe wrote:
> > The compiler
> > relys entirely on the types of the variables to know how to correctly
> > operate on the values. The values themselves have no type information
> > associated with them.
>
> int x = (int) (20.5 / 3);
>
> What machine code operations does the "/" there invoke? Integer
> division, or floating point division? How did the variables involved in
> the expression affect that?
In that case it knew because it could see at compile time. In general
though it doesn't.
If I divide x / y it only knows which to use because of types declared
for x and y.
> >>Casting in C takes values of one type to values of another type.
>
> > No it doesn't. Casting reinterprets a value of one type as a value of
> > another type.
>
> No it doesn't.
> int x = (int) 20.5;
> There's no point at which bits from the floating point representation
> appear in the variable x.
>
> int * x = (int *) 0;
> There's nothing that indicates all the bits of "x" are zero, and indeed
> in some hardware configurations they aren't.
I suppose some are conversions and some reinterpretations. What I
should have said it that there are cases where cast reinterprets.
------------------------------
Date: 20 Jun 2006 10:32:32 -0700
From: "Rob Thorpe" <robert.thorpe@antenova.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150824752.799997.206210@p79g2000cwp.googlegroups.com>
Pascal Costanza wrote:
> Matthias Blume wrote:
> > Pascal Costanza <pc@p-cos.net> writes:
> >> (slot-value p 'address) is an attempt to access the field 'address in
> >> the object p. In many languages, the notation for this is p.address.
> >>
> >> Although the class definition for person doesn't mention the field
> >> address, the call to (eval (read)) allows the user to change the
> >> definition of the class person and update its existing
> >> instances. Therefore at runtime, the call to (slot-value p 'adress)
> >> has a chance to succeed.
> >
> > I am quite comfortable with the thought that this sort of evil would
> > get rejected by a statically typed language. :-)
>
> This sort of feature is clearly not meant for you. ;-P
To be fair though that kind of thing would only really be used while
debugging a program.
Its no different than adding a new member to a class while in the
debugger.
There are other places where you might add a slot to an object at
runtime, but they would be done in tidier ways.
------------------------------
Date: Tue, 20 Jun 2006 17:38:15 GMT
From: Darren New <dnew@san.rr.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <boWlg.19627$uy3.179@tornado.socal.rr.com>
Rob Thorpe wrote:
> Darren New wrote:
>>Rob Thorpe wrote:
>>>The values themselves have no type information associated with them.
>>int x = (int) (20.5 / 3);
> In that case it knew because it could see at compile time.
Well, yes. That's the point of static typing.
> In general though it doesn't.
Sure it does. There are all kinds of formal rules about type promotions
and operator version selection.
In deed, in *general* every value has a type associated with it (at
compile time). Some values have a type associated with them due to the
declaration of the variable supplying the value, but that's far from the
general case.
Note that in
main() { char x = 'x'; foo(x); }
the value passed to "foo" is not even the same type as the declaration
of "x", so it's far from the general case that variables even determine
the values they provide to the next part of the calculation.
> If I divide x / y it only knows which to use because of types declared
> for x and y.
Yes? So? All you're saying is that the value of the expression "x" is
based on the declared type for the variable "x" in scope at that point.
That doesn't mean values don't have types. It just means that *some*
values' types are determined by the type of the variable the value is
stored in. As soon as you do anything *else* with that value, such as
passing it to an operator, a function, or a cast, the value potentially
takes on a type different from that of the variable from which it came.
> I suppose some are conversions and some reinterpretations. What I
> should have said it that there are cases where cast reinterprets.
There are cases where the cast is defined to return a value that has the
same bit pattern as its argument, to the extent the hardware can support
it. However, this is obviously limited to the values for which C
actually defines the bit patterns of its values, namely the scalar
integers.
Again, you're taking a special case and treating all the rest (which are
a majority) as aberations. For the most part, casts do *not* return the
same bit pattern as the value. For the most part
union {T1 x; T2 y;};
can be used to do transformations that
T2 y; T1 x = (T1) y;
does not. Indeed, the only bit patterns that don't change are when
casting from signed to unsigned versions of the same underlying scalar
type and back. Everything else must change, except perhaps pointers,
depending on your architecture. (I've worked on machines where char* had
more bits than long*, for example.)
(Funny that comp.lang.c isn't on this thread. ;-)
--
Darren New / San Diego, CA, USA (PST)
My Bath Fu is strong, as I have
studied under the Showerin' Monks.
------------------------------
Date: Tue, 20 Jun 2006 18:51:41 +0100
From: "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <4498356b$0$659$bed64819@news.gradwell.net>
Chris Smith wrote:
> > Easy, any statically typed language is not latently typed.
>
> I'm actually not sure I agree with this at all. I believe that
> reference values in Java may be said to be latently typed. Practically
> all class-based OO
> languages are subject to similar consideration, as it turns out.
Quite probably true of GC-ed statically typed languages in general, at least up
to a point (and provided you are not using something like a tagless ML
implementation). I think Rob is assuming a rather too specific implementation
of statically typed languages.
> I'm unsure whether to consider explicitly stored array lengths, which
> are present in most statically typed languages, to be part of a "type"
> in this sense or not.
If I understand your position correctly, wouldn't you be pretty much forced to
reject the idea of the length of a Java array being part of its type ? If you
want to keep the word "type" bound to the idea of static analysis, then --
since Java doesn't perform any size-related static analysis -- the size of a
Java array cannot be part of its type.
That's assuming that you would want to keep the "type" connected to the actual
type analysis performed by the language in question. Perhaps you would prefer
to loosen that and consider a different (hypothetical) language (perhaps
producing identical bytecode) which does do compile time size analysis.
But then you get into an area where you cannot talk of the type of a value (or
variable) without relating it to the specific type system under discussion.
Personally, I would be quite happy to go there -- I dislike the idea that a
value has a specific inherent type.
It would be interesting to see what a language designed specifically to support
user-defined, pluggable, and perhaps composable, type systems would look like.
Presumably the syntax and "base" semantics would be very simple, clean, and
unrestricted (like Lisp, Smalltalk, or Forth -- not that I'm convinced that any
of those would be ideal for this), with a defined result for any possible
sequence of operations. The type-system(s) used for a particular run of the
interpreter (or compiler) would effectively reduce the space of possible
sequences. For instance, one could have a type system which /only/ forbade
dereferencing null, or another with the job of ensuring that mutability
restrictions were respected, or a third which implemented access control...
But then, I don't see a semantically critically distinction between such space
reduction being done at compile time vs. runtime. Doing it at compile time
could be seen as an optimisation of sorts (with downsides to do with early
binding etc). That's particularly clear if the static analysis is /almost/
able to prove that <some sequence> is legal (by its own rules) but has to make
certain assumptions in order to construct the proof. In such a case the
compiler might insert a few runtime checks to ensure that it's assumptions were
valid, but do most of its checking statically.
There would /be/ a distinction between static and dynamic checks in such a
system, and it would be an important distinction, but not nearly as important
as the distinctions between the different type systems. Indeed I can imagine
categorising type systems by /whether/ (or to what extent) a tractable static
implementation exists.
-- chris
P.S Apologies Chris, btw, for dropping out of a conversation we were having on
this subject a little while ago -- I've now said everything that I /would/ have
said in reply to your last post if I'd got around to it in time...
------------------------------
Date: Tue, 20 Jun 2006 12:11:46 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: What's ^$ mean?
Message-Id: <slrne9gb2h.pik.tadmc@magna.augustmail.com>
Nick of course <mol10metal@hotmail.com> wrote:
> Mirco Wahab wrote:
[snip full-quote]
> A slightly shorter answer to the original question would have been "Yes"
That would have been a slightly shorter *wrong* answer.
(Since it will match when the string is "\n".)
The original (poorly phrased) question was:
Is ^$ mean a NULL line?
The OP didn't say where these characters are used. I'll guess they
are used with the pattern match operator.
What does "NULL line" mean?
I assume it means the "empty string" (in which case it cannot be
a "line" since it has no newline character).
So if a boolean response is required then "No" would be the accurate answer.
A more helpful answer would be:
/^$/ matches the empty string, or the 1-char long string where
the 1 char is a newline.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
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 9325
***************************************
