[28103] in Perl-Users-Digest
Perl-Users Digest, Issue: 9467 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jul 13 21:10:14 2006
Date: Thu, 13 Jul 2006 18:10:06 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 13 Jul 2006 Volume: 10 Number: 9467
Today's topics:
Re: What is a type error? <eval.apply@gmail.com>
Re: What is a type error? <cdsmith@twu.net>
Re: What is a type error? <cdsmith@twu.net>
Re: What is a type error? (Rob Warnock)
Re: What is a type error? <marshall.spight@gmail.com>
Re: What is a type error? <marshall.spight@gmail.com>
Re: What is a type error? <cdsmith@twu.net>
Re: What is a type error? <david.nospam.hopwood@blueyonder.co.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 13 Jul 2006 15:07:08 -0700
From: "Joe Marshall" <eval.apply@gmail.com>
Subject: Re: What is a type error?
Message-Id: <1152828428.281715.299050@p79g2000cwp.googlegroups.com>
Marshall wrote:
>
> Consider the following Java fragment:
>
> void foo() {
> int i = 0;
> int j = 0;
>
> // put any code here you want
>
> j = 1;
> i = 2;
> // check value of j here. It is still 1, no matter what you filled in
> above.
> // The assignment to i cannot be made to affect the value of j.
>
> }
True, but you have hidden the pointers. Semantically, the identifiers
i and j refer not to integers but to locations that hold integers. The
assignment modifies the location.
> Those two local primitive variables cannot be made to have the same
> identity. But you can update them, so this is an example of mutability
> without the possibility of identity.
The identity is temporal: You use the same variable name at two
different times. Do you intend for the second `i' to mean the same
variable as the first `i'?
------------------------------
Date: Thu, 13 Jul 2006 16:22:17 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is a type error?
Message-Id: <MPG.1f207586ed65f730989796@news.altopia.net>
Darren New <dnew@san.rr.com> wrote:
> Chris Smith wrote:
> > Unless I'm missing your point, I disagree with your disagreement.
> > Mutability only makes sense because of object identity (in the generic
> > sense; no OO going on here).
>
> Depends what you mean by "object".
>
> int x = 6; int y = 5; x = y;
>
> I'd say x was mutable, with no "identity" problems involved?
The variable x definitely has identity that's independent of its value.
Some might call that a problem in and of itself, as it complicates the
formal model of the language and makes it difficult to predict what
result will be produced by normal order evaluation.
On the other hand, this thread seems to be using "identity" to mean
"identity with potential for aliasing", in which case it is vacuously
true that eliminating identity also prevents the problems that arise
from aliasing. It is true, and I agree on this with Marshall, that
eliminating the potential for aliasing solves a lot of problems with
checking invariants. I also see, though, that the majority (so far, I'd
say all) of the potential uses for which it's worth introducing mutation
into an otherwise mutation-free language allow the possibility of
aliasing, which sorta makes me wonder whether this problem is worth
solving. I'd like to see an example of code that would be harder to
write without mutation, but which can obey any restriction that's
sufficient to prevent aliasing.
> Why is it problematic that variables have identity and are mutable?
> Certainly I can later "find" whatever value I put into x.
I simply found the language confusing. I said it would be nonsensical
for a language to have mutation without identity.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
Date: Thu, 13 Jul 2006 16:24:57 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is a type error?
Message-Id: <MPG.1f2076205513cf2a989797@news.altopia.net>
David Hopwood <david.nospam.hopwood@blueyonder.co.uk> wrote:
> This is true, but note that postconditions also need to be efficient
> if we are going to execute them.
If checked by execution, yes. In which case, I am trying to get my head
around how it's any more true to say that functional languages are
compilable postconditions than to say the same of imperative languages.
In both cases, some statement is asserted through a description of a
means of computing it. There may be a distinction worth making here,
but I'm missing it so far.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
Date: Thu, 13 Jul 2006 18:28:34 -0500
From: rpw3@rpw3.org (Rob Warnock)
Subject: Re: What is a type error?
Message-Id: <BJ-dnZPb69C_SivZnZ2dnUVZ_oydnZ2d@speakeasy.net>
Marshall <marshall.spight@gmail.com> wrote:
+---------------
| Joachim Durchholz wrote:
| > Actually SQL has references - they are called "primary keys", but they
| > are references nevertheless.
|
| I strongly object; this is quite incorrect. I grant you that from the
| 50,000 foot level they appear identical, but they are not.
+---------------
Agreed. The only thing different about "primary" keys from any other
key is uniqueness -- a selection by primary key will return only one
record. Other than that constraint, many databases treat them exactly
the same as non-primary keys [e.g., can form indexes on them, etc.].
+---------------
| To qualify as a reference, there need to be reference and dereference
| operations on the reference datatype; there is no such operation is SQL.
+---------------
Not in "ANSI SQL92", say, but there might be in most SQL databases!
[See below re OIDs. Also, SQL:1999 had a "REF" type that was essentially
and OID.]
+---------------
| Would you say the relational algebra has references?
+---------------
Don't confuse "SQL" & "relational algebra"!! You'll get real
relational algebraists *way* bent out of shape if you do that!
+---------------
| > (Some SQL dialects also offer synthetic "ID" fields that are
| > guaranteed to remain stable over the lifetime of a record.
|
| Primary keys are updatable; there is nothing special about them.
+---------------
I think he's probably talking about "OIDs" (object IDs). Most
current SQL-based databases provide them, usually as a normally-
invisible "system column" that doesn't show up when you say
"SELECT * FROM", but that *does* appear if you say "SELECT oid, *",
and may be used as a "primary" key even on tables with no actual
primary key:
rpw3=# select * from toy limit 4;
c1 | c2 | c3 | upd
--------+-------+--------------------------------+-----
fall | tape | My Favorite Thanksgiving | 16
xmas | book | My Favorite Christmas | 2
xmas | video | The Grinch who Stole Christmas | 4
summer | book | Unusual 4ths of July | 17
(4 rows)
rpw3=# select oid, * from toy limit 4;
oid | c1 | c2 | c3 | upd
-------+--------+-------+--------------------------------+-----
19997 | fall | tape | My Favorite Thanksgiving | 16
19998 | xmas | book | My Favorite Christmas | 2
19999 | xmas | video | The Grinch who Stole Christmas | 4
20000 | summer | book | Unusual 4ths of July | 17
(4 rows)
rpw3=# select * from toy where oid = 19998;
c1 | c2 | c3 | upd
------+------+-----------------------+-----
xmas | book | My Favorite Christmas | 2
(1 row)
rpw3=# insert into toy values ('fall','book','Glory Road');
INSERT 32785 1
rpw3=# select oid, * from toy where oid = 32785;
oid | c1 | c2 | c3 | upd
-------+------+------+------------+-----
32785 | fall | book | Glory Road | 21
(1 row)
rpw3=#
See <http://www.postgresql.org/docs/8.1/static/datatype-oid.html>
for how PostgreSQL treats OIDs [including some critical limitations].
-Rob
-----
Rob Warnock <rpw3@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
------------------------------
Date: 13 Jul 2006 16:28:36 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is a type error?
Message-Id: <1152833316.272422.257250@h48g2000cwc.googlegroups.com>
Joe Marshall wrote:
> Marshall wrote:
> >
> > Consider the following Java fragment:
> >
> > void foo() {
> > int i = 0;
> > int j = 0;
> >
> > // put any code here you want
> >
> > j = 1;
> > i = 2;
> > // check value of j here. It is still 1, no matter what you filled in
> > above.
> > // The assignment to i cannot be made to affect the value of j.
> >
> > }
>
> True, but you have hidden the pointers. Semantically, the identifiers
> i and j refer not to integers but to locations that hold integers. The
> assignment modifies the location.
What the implementation looks like shouldn't affect how we speak
of the logical model. In the above code, there are no pointers.
By your definition, "pointer" and "variable" are synonyms. That doesn't
seem like a good idea to me. (What if i and j end up in registers?
I have not heard it said that registers have addresses.)
> > Those two local primitive variables cannot be made to have the same
> > identity. But you can update them, so this is an example of mutability
> > without the possibility of identity.
>
> The identity is temporal: You use the same variable name at two
> different times. Do you intend for the second `i' to mean the same
> variable as the first `i'?
Okay, so "i" and "i" have the same identity. I suppose you could argue
that the language's namespace is an address-space, and variable names
are addresses. At this point, though, you've made the concept of
identity
so broad that it is now necessarily a property of all languages that
use
named values, whether updatable or not. I think you would also have
to call "3" a void pointer by this scheme.
Clearly there is *some* difference between a language which allows
explicit pointers and thus aliasing and one that doesn't. What term
would you use? First-class variables?
Marshall
------------------------------
Date: 13 Jul 2006 16:39:08 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is a type error?
Message-Id: <1152833948.111493.133950@i42g2000cwa.googlegroups.com>
Chris Smith wrote:
> Darren New <dnew@san.rr.com> wrote:
> > Chris Smith wrote:
> > > Unless I'm missing your point, I disagree with your disagreement.
> > > Mutability only makes sense because of object identity (in the generic
> > > sense; no OO going on here).
> >
> > Depends what you mean by "object".
> >
> > int x = 6; int y = 5; x = y;
> >
> > I'd say x was mutable, with no "identity" problems involved?
>
> The variable x definitely has identity that's independent of its value.
I'm not sure what you mean by that.
> I also see, though, that the majority (so far, I'd
> say all) of the potential uses for which it's worth introducing mutation
> into an otherwise mutation-free language allow the possibility of
> aliasing, which sorta makes me wonder whether this problem is worth
> solving.
What about my example of SQL? Mutation, no pointers, no aliasing.
Yet: useful.
Marshall
------------------------------
Date: Thu, 13 Jul 2006 18:33:39 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is a type error?
Message-Id: <MPG.1f20945225d45ea5989799@news.altopia.net>
Marshall <marshall.spight@gmail.com> wrote:
> Chris Smith wrote:
> > Darren New <dnew@san.rr.com> wrote:
> > > Chris Smith wrote:
> > > > Unless I'm missing your point, I disagree with your disagreement.
> > > > Mutability only makes sense because of object identity (in the generic
> > > > sense; no OO going on here).
> > >
> > > Depends what you mean by "object".
> > >
> > > int x = 6; int y = 5; x = y;
> > >
> > > I'd say x was mutable, with no "identity" problems involved?
> >
> > The variable x definitely has identity that's independent of its value.
>
> I'm not sure what you mean by that.
I mean, simply, that when you can assign a value to a variable, then you
care that it is that variable and not a different one. That's identity
in the normal sense of the word. The code elsewhere in the procedure is
able to access the value of 'x', and that has meaning even though you
don't know what value 'x' has. This has definite implications, and is a
useful concept; for example, it means that the pure lambda calculus no
longer sufficient to express the semantics of the programming language,
but instead something else is required.
What you are asking for is some subset of identity, and I've not yet
succeeded in understanding exactly what it is or what its limits are...
except that so far, it seems to have everything to do with pointers or
aliasing.
> > I also see, though, that the majority (so far, I'd
> > say all) of the potential uses for which it's worth introducing mutation
> > into an otherwise mutation-free language allow the possibility of
> > aliasing, which sorta makes me wonder whether this problem is worth
> > solving.
>
> What about my example of SQL? Mutation, no pointers, no aliasing.
> Yet: useful.
I'm not yet convinced that this is any different from a language with
standard pointer aliasing. If I have two tables A and B, and a foreign
key from A into B, then I run into the same problems with enforcing
constraints that I would see with a pointer model... when I update a
relation, I need to potentially check every other relation that contains
a foreign key into it, in order to ensure that its constraints are not
violated by that constraint. That's the same thing that is being
pointed out as a negative consequence of aliasing in other languages.
For example, executing:
UPDATE P SET x = 5 WHERE y = 43;
may result in the database having to re-evaluate the constraint that
says that for all P(x, y, z), x must be less than 4 when z = 17. One
difference is that while in general purpose programming languages this
appears to be a daunting task, databases are set up to do these kinds of
things all the time and contain optimizations for it... but the problem
is still the same, and it would still present the same difficulties in
doing formal proofs that running the above UPDATE statement doesn't
violate any invariants.
(If I'm wrong about that, please let me know; I'd very interested if
that's so.)
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
Date: Fri, 14 Jul 2006 01:00:57 GMT
From: David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
Subject: Re: What is a type error?
Message-Id: <d1Ctg.313440$8W1.311974@fe1.news.blueyonder.co.uk>
Chris Smith wrote:
> David Hopwood <david.nospam.hopwood@blueyonder.co.uk> wrote:
>
>>This is true, but note that postconditions also need to be efficient
>>if we are going to execute them.
>
> If checked by execution, yes. In which case, I am trying to get my head
> around how it's any more true to say that functional languages are
> compilable postconditions than to say the same of imperative languages.
A postcondition must, by definition [*], be a (pure) assertion about the
values that relevant variables will take after the execution of a subprogram.
If a subprogram is intended to have side effects, then its postcondition
can describe the results of the side effects, but must not reexecute them.
[*] E.g. see
<http://www.spatial.maine.edu/~worboys/processes/hoare%20axiomatic.pdf>,
although the term "postcondition" was introduced later than this paper.
--
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
------------------------------
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 9467
***************************************
