[28120] in Perl-Users-Digest
Perl-Users Digest, Issue: 9484 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Jul 16 21:10:11 2006
Date: Sun, 16 Jul 2006 18: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: 9484
Today's topics:
Re: What is a type error? <cdsmith@twu.net>
Re: What is a type error? <cdsmith@twu.net>
Re: What is a type error? <jo@durchholz.org>
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? <cdsmith@twu.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 16 Jul 2006 12:28:37 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is a type error?
Message-Id: <MPG.1f24333f84d7a29198968a@news.altopia.net>
We Chris's stick together, as always.
Marshall <marshall.spight@gmail.com> wrote:
> > 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"?
First of all, we should be consistent in speaking about the logical
language semantics, which may not include bits anyway.
That said, if bits were the primitive concept of data in a language,
then we'd be able to get away with talking about higher-level concepts
because we agree to always manipulate a larger structure (a byte, for
example) as a pure value. If we were using bitwise operators, then we
wouldn't be able to get away with it, for example. That said, it's also
quite possible to consider aliasing on higher levels as well; it's just
not possible to point out the lack of aliasing for higher levels of
abstraction, and thus conclude that no aliasing exists. Aliasing is
still possible for entities within those layers of abstraction.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
Date: Sun, 16 Jul 2006 12:44:41 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is a type error?
Message-Id: <MPG.1f2436ff5a3b6dec98968b@news.altopia.net>
Marshall <marshall.spight@gmail.com> wrote:
> 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?)
This is definitely a good question. Nevertheless, I think we're fooling
ourselves if we decide that we've made progress by defining part of the
problem out of existence. The original problem was that when there are
several ways of getting access to something that is identical (rather
than just equal), this causes problems for invariant checking. These
several ways of accessing data are being called 'aliasing' -- I have no
comment on whether that's standard usage or not, because I don't know.
I suspect that aliasing is normally used for something closer to the
physical level. The point is that whatever "aliasing" really means,
what we're discussing is having two paths by which one may access
identical data.
So there are infinitely complex ways in which this can occur. I can
have pointers that are aliased. I can have integers, which by
themselves are just plain values, but can alias each other as indices
into an array. I can have strings that do the same thing for an
associative array. I can, of course, have arbitrarily more complex data
structures with exactly the same issue. I can also have two different
WHERE clauses, which when applied to the same relation yield exactly the
same set of tuples. The problem arises when code is written to update
some value (or set of tuples, in the SQL case, since definitions differ
there) using one pointer/int/string/WHERE clause/etc, and at the same
time an invariant was written using the other pointer/int/WHERE/etc, the
result is that either of:
a) The compiler has to be able to prove that the two are not aliased
b) The compiler has to re-evaluate the invariant from scratch when this
operation is performed.
(Yeah, there's actually a whole continuum between a and b, based on more
limited abilities of the compiler to prove things. I'm oversimplifying,
and I think it's rather benign in this case.)
So in this sense, a WHERE clause is a binary operation in exactly the
same way that an array indexing expression is a binary operation, and
both are capable of aliasing in at least this logical sense.
Now it's certainly true that languages with unrestricted pointers are
less successful at limiting the scope of re-evaluation of invariants.
In the array or SQL relation cases, there's a limited set of value/tuple
modifications that might cause the invariant to need rechecking
(specifically those that point to the same array, or to the relation or
one of its views). A language with unrestricted untyped pointers, if it
doesn't get lucky with the capture analysis, may have to re-evaluate all
invariants in the application on any given assignment. Nevertheless,
the re-evaluation of the invariant still needs to be done.
--
Chris Smith - Lead Software Developer /Technical Trainer
MindIQ Corporation
------------------------------
Date: Sun, 16 Jul 2006 21:59:39 +0200
From: Joachim Durchholz <jo@durchholz.org>
Subject: Re: What is a type error?
Message-Id: <e9e64h$vsa$1@online.de>
Marshall schrieb:
>
> 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.
Actually I see it the other way round: assignment is strictly less
powerful than DML since it doesn't allow creating or destroying
variables, while UPDATE does cover assignment to fields.
(However, it's usually new+assignment+delete vs. INSERT+UPDATE+DELETE,
at which point there is not much of a difference.)
>>>>> 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?
I think that's very, very unlikely ;-)
> 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?
Yes.
Filters are just like array indexing: both select a subset of variables
from a collection. In SQL, you select a subset of a table, in a
programming language, you select a subset of an array.
(The SQL selection mechanism is far more flexible in the kinds of
filtering you can apply, while array indexing allows filtering just by
ordinal position. However, the relevant point is that both select things
that can be updated.)
>> 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.
I don't think so. You can update SQL records any way you want.
The unavailability of a record identity is due to the fact that, well,
it's unavailable in standard SQL.
Regards,
Jo
------------------------------
Date: 16 Jul 2006 16:08:15 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is a type error?
Message-Id: <1153091295.520674.287230@i42g2000cwa.googlegroups.com>
Joachim Durchholz wrote:
> Marshall schrieb:
> >
> > 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.
>
> Actually I see it the other way round: assignment is strictly less
> powerful than DML since it doesn't allow creating or destroying
> variables, while UPDATE does cover assignment to fields.
Oh, my.
Well, for all table variables T, there exists some pair of
values v and v', such that we can transition the value of
T from v to v' via assignment, but not by any single
insert, update or delete. The reverse is not true. I
would consider that a solid demonstration of which
one is more powerful. Further, it is my understanding
that your claim of row identity *depends* on the restricted
nature of DML; if the only mutator operation is assignment,
then there is definitely no record identity.
> (However, it's usually new+assignment+delete vs. INSERT+UPDATE+DELETE,
> at which point there is not much of a difference.)
I am not sure what this means. Delete can be expressed in
terms of assignment. (As can insert and update.) (Assignment
can also be expressed in terms of insert and delete.) I
don't know what "new" would be in a value-semantics, relational
world. So I would say it's assignment vs. INSERT+UPDATE+DELETE,
but perhaps I'm not understanding what you mean.
Assignment by itself is complete. Insert and delete together
are complete.
> >>>>> 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?
>
> I think that's very, very unlikely ;-)
Well, I just thought I'd ask. :-)
> > 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?
>
> Yes.
>
> Filters are just like array indexing: both select a subset of variables
> from a collection.
I can't agree with this wording. A filter produces a collection
value from a collection value. I don't see how variables
enter in to it. One can filter either a collection constant or
a collection variable; if one speaks of filtering a collection
variable, on is really speaking of filtering the collection value
that the variable currently contains; filtering is not an operation
on the variable as such, the way the "address of" operator is.
Note you can't update the result of a filter.
> In SQL, you select a subset of a table, in a
> programming language, you select a subset of an array.
>
> (The SQL selection mechanism is far more flexible in the kinds of
> filtering you can apply, while array indexing allows filtering just by
> ordinal position. However, the relevant point is that both select things
> that can be updated.)
When you have been saying "select things that can be updated"
I have been assuming you meant that one can derive values
from variables, and that some other operation can update that
variable, causing the expression, if re-evaluated, to produce
a different value. However the phrase also suggests that
you mean that the *result* of the select can *itself* be
updated. Which one do you mean? (Or is there a third
possibility?)
> >> 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.
>
> I don't think so. You can update SQL records any way you want.
> The unavailability of a record identity is due to the fact that, well,
> it's unavailable in standard SQL.
I disagree. The concept of record-identity is quite tenuous, and
depends on specifics of SQL semantics. (In fact I'm not entirely
convinced it's definitely there even in SQL.) It certainly does not
hold in, say, set theory. Set elements do not have identity; they
only have value. If we have a set-semantics language that
supports set variables with assignment, we still do not have
element-identity.
Marshall
------------------------------
Date: Sun, 16 Jul 2006 17:19:21 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is a type error?
Message-Id: <MPG.1f247767eefec77e989690@news.altopia.net>
David Hopwood <david.nospam.hopwood@blueyonder.co.uk> wrote:
> Chris Smith wrote:
> > 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.
Okay, my objection was misplaced, then, as I misunderstood the original
statement. I had understood it to mean that programs written in pure
functional languages carry no additional information except for their
postconditions.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
Date: Sun, 16 Jul 2006 18:23:50 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is a type error?
Message-Id: <MPG.1f24867143d04542989694@news.altopia.net>
Darren New <dnew@san.rr.com> wrote:
> I'm not sure what linear or uniqueness typing is. It's typestate, and if
> I remember correctly the papers I read 10 years ago, the folks at
> TJWatson that invented Hermes also invented the concept of typestate.
> They at least claim to have coined the term.
Coining the term is one thing, but I feel pretty confident that the idea
was not invented in 1986 with the Hermes language, but rather far
earlier. Perhaps they may have invented the concept of considering it
any different from other applications of types, though. I still have
trouble delineating how to consider "typestate" different from ordinary
types in formal terms, unless I make the formal model complex enough to
include some kind of programmer-defined identifiers such as variables.
The distinction is not at all relevant to common type system models
based on the lambda calculus.
While acknowledging, on the one hand, that the word "typestate" is used
to describe this, I also object that types have *always* been assigned
to expressions in differing type environments. Otherwise, it would be
impossible to assign types to lambda abstractions in the simply typed
lambda calculus, the simplest of all generally studied type systems.
What is being named here is the overcoming of a limitation that
programming language designers imposed upon themselves, whether from not
understanding the theoretical research or not believing it important, I
don't know.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
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 9484
***************************************
