[28118] in Perl-Users-Digest
Perl-Users Digest, Issue: 9482 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Jul 16 14:10:13 2006
Date: Sun, 16 Jul 2006 11:10:05 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 16 Jul 2006 Volume: 10 Number: 9482
Today's topics:
Re: What is a type error? <cfc@shell01.TheWorld.com>
Re: What is a type error? <rvtol+news@isolution.nl>
Re: What is a type error? <marshall.spight@gmail.com>
Re: What is a type error? <marshall.spight@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 16 Jul 2006 12:01:54 -0400
From: Chris F Clark <cfc@shell01.TheWorld.com>
Subject: Re: What is a type error?
Message-Id: <sddwtadbkst.fsf@shell01.TheWorld.com>
"Marshall" <marshall.spight@gmail.com> wrote:
> In general, I feel that "records" are not the right conceptual
> level to think about.
Unfortunately, they are the right level. Actually,the right level
might even be lower, the fields within a record, but that's moving
even farther away from the direction you wish to go. The right level
is the lowest level at which the programmer can see and manipulate
values. Thus, since a programmer can see and manipulate fields within
records in SQL that is the level we need to concern ourselves with
when talking about aliasing in SQL. In other words, since a SELECT
(or UPDATE) statement can talk about specific fields of specific
records within the table (not directly, but reliably, which I'll
explain in a moment) then those are the "primitive objects" in SQL
that can be aliased.
What I meant by "not directly, but reliably":
If you have a fixed database, and you do two selects which specify the
same sets of fields to be selected and the same keys to select records
with, one expects the two selects to return the same values. You do
not necessarily expect the records to be returned in the same order,
but you do expect the same set of records to be returned and the
records to have the same values in the same fields. Further, if you
do an update, you expect certain fields of certain records to change
(and be reflected in subsequent selects).
However, therein lies the rub, if you do a select on some records, and
then an update that changes those records, the records you have from
the select have either changed or show outdated values. If there is
some way to refer to the records you first selected before the update,
then you have an aliasing problem, but maybe one can't do that. One
could also have an aliasing problem, if one were allowed to do two
updates simultaneously, so that one update could changed records in
the middle of the other changing the records. However, I don't know
if that's allowed in the relational algebra either. (I think I finally
see your point, and more on that later.)
> I do not see that they have
> any identity outside of their value. We can uniquely identify
> any particular record via a key, but a table may have more
> than one key, and an update may change the values of one
> key but not another. So it is not possible in general to
> definitely and uniquely assign a mapping from each record
> of a table after an update to each record of the table before
> the update, and if you can't do that, then where
> is the record identity?
I don't know if your point of having two keys within one table amkes a
difference. If one can uniquely identify a record, then it has
identity. The fact that there is another mapping where one may not be
able to uniquely identify the record is not necessarily relevant.
> But what you descrbe is certainly *not* possible in the
> relational algebra; alas that SQL doesn't hew closer
> to it. Would you agree? Would you also agree that
> if a language *did* adhere to relation semantics,
> then relation elements would *not* have identity?
> (Under such a language, one could not have two
> equal records, for example.)
Ok, here I think I will explain my understanding of your point. If we
treat each select statement and each update statements as a separate
program, i.e. we can't save records from one select statement to a
later one (and I think in the relational algebra one cannot), then
each single (individual) select statement or update statement is a
functional program. That is we can view a single select statement as
doing a fold over some incoming data, but it cannot change the data.
Similarly, we can view an update statement as creating a new copy of
the table with mutations in it, but the update statement can only
refer to the original immutable table that was input. (Well, that's
atleast how I recall the relational algebra.) It is the second point,
about the semantics of the update statement which is important. There
are no aliasing issues because in the relational algebra one cannot
refer to the mutated values in an update statement, every reference in
an update statement is refering to the unmutated input (again, that's
my recollection). (Note, if my recollection is off, and one can refer
to the mutated records in an update statement, perhaps they can
explain why aliasing is not an issue in it.)
Now for some minor points:
> For example, we might ask in C, if we update a[i], will
> the value of b[j] change? And we can't say, because
> we don't know if there is aliasing. But in Fortran, we
> can say that it won't, because they are definitely
> different variables.
Unfortunately, your statement about FORTRAN is not true, if a and b
are parameters to a subroutine (or members of a common block, or
equivalenced, or ...), then an update of a[i] might change b[j].
This is in fact, an important point, it is in subroutines (and
subroutine like things), where we have local names for things
(bindings) that are actually names for things which may or may not be
distinct, that aliasing is the primary issue. I don't recall the
relational algebra having subroutines, and even if it did they would
be unimportant, given that one could not refer within a single update
statement to the records that a subroutine changed (since one cannot
refer in an update statement to any record which has been changed, see
the caveats above).
Joachim Durchholz wrote: > >
> > Indeed.
> > Though the number of parameter passing mechanisms isn't that large
> > anyway. Off the top of my head, I could recite just three (by value, by
> > reference, by name aka lazy), the rest are just combinations with other
> > concepts (in/out/through, most notably) or a mapping to implementation
> > details (by reference vs. "pointer by value" in C++, for example).
Marshall again:
> Fair enough. I could only remember three, but I was sure someone
> else could name more. :-)
There actual are some more, but very rare, for example there was call-
by-text-string, which is sort of like call-by-name, but allows a
parameter to reach into the calling routine and mess with local
variables therein. Most of the rare ones have really terrible
semantics, and are perhaps best forgotten except to keep future
implementors from choosing them. For example, call-by-text-string is
really easy to implement in a naive interpreter that reparses each
statement at every invocation, but but it exposes the implementation
properties so blatantly that writing a different interpretor is nearly
impossible.
If I recall correctly, there are also some call-by- methods that take
into account networks and addressing space issues--call-by-reference
doesn't work if one cannot see the thing being referenced. Of coruse,
one must then ask whether one considers "remote-procedure-call" and/or
message-passing to be the same thing as a local call.
One last nit, Call-by-value is actually call-by-copy-in-copy-out when
generalized.
There are some principles that one can use to organize the parameter
passing methods. However, the space is much richer than people
commonly know about (and that is actually a good thing, that most
people aren't aware of the richness, simplicity is good).
-Chris
------------------------------
Date: Sun, 16 Jul 2006 18:51:02 +0200
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: What is a type error?
Message-Id: <e9e1t9.1do.1@news.isolution.nl>
Chris F Clark schreef:
> If you have a fixed database, and you do two selects which specify the
> same sets of fields to be selected and the same keys to select records
> with, one expects the two selects to return the same values.
When your "fixed" means read-only, or (fully) locked, then yes.
Modern databases also have modes without locks, so without special
attention (like maybe your "fixed") the two selects do not necessarily
return the same set of records.
> Further, if you
> do an update, you expect certain fields of certain records to change
> (and be reflected in subsequent selects).
Doesn't your "fixed" block updates?
> However, therein lies the rub, if you do a select on some records, and
> then an update that changes those records, the records you have from
> the select have either changed or show outdated values.
Not necessarily outdated: values can be fixed in time for a purpose.
Example: calculating interest is done once per day, but the whole
process takes more than a day.
Some systems implemented a lock plus requery just before the update, to
check for unacceptable changes in the stored data; this to prevent
having to keep locks while waiting.
> If there is
> some way to refer to the records you first selected before the update,
> then you have an aliasing problem, but maybe one can't do that. One
> could also have an aliasing problem, if one were allowed to do two
> updates simultaneously, so that one update could changed records in
> the middle of the other changing the records.
Some databases allow you to travel back in time: run this query on the
data of 1 year ago. All previous values are kept "behind" the current
value.
--
Affijn, Ruud
"Gewoon is een tijger."
------------------------------
Date: 16 Jul 2006 10:28:42 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is a type error?
Message-Id: <1153070922.854289.270130@75g2000cwc.googlegroups.com>
Joachim Durchholz wrote:
> Marshall schrieb:
>
> > But what you descrbe is certainly *not* possible in the
> > relational algebra; alas that SQL doesn't hew closer
> > to it. Would you agree?
>
> Yup, SQL (particularly its update semantics) aren't relational semantics.
> Still, it's SQL we've been talking about.
>
> > Would you also agree that
> > if a language *did* adhere to relation semantics,
> > then relation elements would *not* have identity?
> > (Under such a language, one could not have two
> > equal records, for example.)
>
> Any identity that one could define within relational semantics would be
> just equality, so no, it wouldn't be very helpful (unless as part of a
> greater framework).
> However, that's not really a surprise. Aliasing becomes relevant (even
> observable) only when there's updates, and relational algebra doesn't
> have updates.
Good point. Perhaps I should have said "relational algebra +
variables with assignment." It is interesting to consider
assignment vs. the more restricted update operators: insert,
update, delete. I think I see what you mean about the restricted
update operators working on identity.
> >>> Okay. At this point, though, the term aliasing has become extremely
> >>> general. I believe "i+1+1" is an alias for "i+2" under this definition.
> >> No, "i+1+1" isn't an alias in itself. It's an expression - to be an
> >> alias, it would have to be a reference to something.
> >>
> >> However, a[i+1+1] is an alias to a[i+2]. Not that this is particularly
> >> important - 1+1 is replacable by 2 in every context, so this is
> >> essentially the same as saying "a[i+2] is an alias of a[i+2]", which is
> >> vacuously true.
> >
> > To me, the SQL with the where clause is like i+2, not like a[2].
>
> I'd say WHERE is like [i+2]: neither is valid on its own, it's the
> "selector" part of a reference into a table.
Is it possible you're being distracted by the syntax? WHERE is a
binary operation taking a relation and a filter function. I don't
think of filters as being like array indexing; do they appear
analogous to you? (Always a difficult question because often
times A and B share some qualities and not others, and
what does one call that?)
> > However the situation in SQL strikes me as being different.
> > If one is speaking of base tables, and one has two queries,
> > one has everything one needs to know simply looking at
> > the queries. If views are involved, one must further examine
> > the definition of the view.
>
> Sure. Usually, SQL itself is enough abstract that no additional
> abstraction happens; so even if you have aliasing, you usually know
> about it.
> I.e. when compared to what you were saying about Java: "It is possible
> to have multiple references to a single Java mutable object and
> not know it.", the "and not know it" part is usually missing.
Yes!
> The picture changes as soon as the SQL statements get hidden behind
> layers of abstraction, say result sets and prepared query handles.
>
> ... Um... let me also restate the preconditions for aliasing become a
> problem. You need three elements for that:
> 1) Identities that can be stored in multiple places.
> 2) Updates.
> 3) Abstraction (of updatable entities).
>
> Without identities, there cannot be aliasing.
> Without updates, the operation that makes aliasing problematic is excluded.
> Without abstraction, you may have aliasing but can clearly identify it,
> and don't have a problem.
Aha! That description works very well for me.
> I admit that identity cannot be reliably established in SQL. The
> identity of a record isn't available (unless via OID extensions).
> However, it is there and it can have effect.
Yes, I think I see what you mean now. This is in part a consequence
of the restricted update operators.
Thanks,
Marshall
------------------------------
Date: 16 Jul 2006 10:35:47 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is a type error?
Message-Id: <1153071347.282931.203960@s13g2000cwa.googlegroups.com>
Chris F Clark wrote:
> "Marshall" <marshall.spight@gmail.com> wrote:
> > In general, I feel that "records" are not the right conceptual
> > level to think about.
>
> Unfortunately, they are the right level. Actually,the right level
> might even be lower, the fields within a record, but that's moving
> even farther away from the direction you wish to go. The right level
> is the lowest level at which the programmer can see and manipulate
> values.
But how is this not always "the bit"?
> > I do not see that they have
> > any identity outside of their value. We can uniquely identify
> > any particular record via a key, but a table may have more
> > than one key, and an update may change the values of one
> > key but not another. So it is not possible in general to
> > definitely and uniquely assign a mapping from each record
> > of a table after an update to each record of the table before
> > the update, and if you can't do that, then where
> > is the record identity?
>
> I don't know if your point of having two keys within one table amkes a
> difference. If one can uniquely identify a record, then it has
> identity. The fact that there is another mapping where one may not be
> able to uniquely identify the record is not necessarily relevant.
The issue with two keys is that the keys may not *agree* on the
mapping before vs. after the update.
> > For example, we might ask in C, if we update a[i], will
> > the value of b[j] change? And we can't say, because
> > we don't know if there is aliasing. But in Fortran, we
> > can say that it won't, because they are definitely
> > different variables.
>
> Unfortunately, your statement about FORTRAN is not true, if a and b
> are parameters to a subroutine (or members of a common block, or
> equivalenced, or ...), then an update of a[i] might change b[j].
Ah, common blocks. How that takes me back!
But your point is a good one; I oversimplified.
> Marshall again:
> > Fair enough. I could only remember three, but I was sure someone
> > else could name more. :-)
>
> There actual are some more, but very rare, for example there was call-
> by-text-string, which is sort of like call-by-name, but allows a
> parameter to reach into the calling routine and mess with local
> variables therein. Most of the rare ones have really terrible
> semantics, and are perhaps best forgotten except to keep future
> implementors from choosing them. For example, call-by-text-string is
> really easy to implement in a naive interpreter that reparses each
> statement at every invocation, but but it exposes the implementation
> properties so blatantly that writing a different interpretor is nearly
> impossible.
>
> If I recall correctly, there are also some call-by- methods that take
> into account networks and addressing space issues--call-by-reference
> doesn't work if one cannot see the thing being referenced. Of coruse,
> one must then ask whether one considers "remote-procedure-call" and/or
> message-passing to be the same thing as a local call.
>
> One last nit, Call-by-value is actually call-by-copy-in-copy-out when
> generalized.
>
> There are some principles that one can use to organize the parameter
> passing methods. However, the space is much richer than people
> commonly know about (and that is actually a good thing, that most
> people aren't aware of the richness, simplicity is good).
Fair enough.
Marshall
------------------------------
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 9482
***************************************
