[28127] in Perl-Users-Digest
Perl-Users Digest, Issue: 9491 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jul 17 18:10:12 2006
Date: Mon, 17 Jul 2006 15: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 Mon, 17 Jul 2006 Volume: 10 Number: 9491
Today's topics:
Re: What is a type error? <marshall.spight@gmail.com>
Re: What is a type error? <david.nospam.hopwood@blueyonder.co.uk>
Re: What is a type error? <cdsmith@twu.net>
Re: What is a type error? <marshall.spight@gmail.com>
Re: What is a type error? <cdsmith@twu.net>
Re: why is perl -e 'unlink(glob("*"))' so much faster t ewaguespack@gmail.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 17 Jul 2006 11:31:40 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is a type error?
Message-Id: <1153161100.650922.110630@h48g2000cwc.googlegroups.com>
Chris Smith wrote:
> Marshall <marshall.spight@gmail.com> wrote:
> > We seem to have slipped back from the hypothetical relation language
> > with only assignement back to SQL.
>
> [...]
> I don't see how such a language (limited to assignment of entire
> relations) is particularly helpful to consider.
I find it useful to consider various language features together and
individually, to see how these features interact. If nothing else,
it furthers my understanding of how languages work.
> If the relations are to
> be considered opaque, then there's clearly no aliasing going on.
Not certain I understand, but I think I agree.
> However, such a language doesn't seem to solve any actual problems. It
> appears to be nothing other than a toy language, with a fixed finite set
> of variables having only value semantics, no scope, etc.
No, such a language is entirely useful, since relational assignment
is *more* expressive than insert/update/delete. (How did you get "no
scope"
by the way? And fixed variables? All I said was to change ins/upd/del
to
assignment.)
Also note one could fairly easily write a macro for ins/upd/del if one
had assignement. (See below.)
Now, there are some significant issues with trying to produce a
performant implementation in a distributed environment with strictness.
In fact I will go so far as to say it's impossible. However on a single
machine I don't see any reason to think it would perform any worse,
(although I haven't thought about it deeply.)
> I assume that
> relational databases will have the equivalent of SQL's update statement;
> and if that's not the case, then I would need someone to explain how to
> accomplish the same goals in the new relational language; i.e. it would
> need some way of expressing transformations of relations, not just
> complete replacement of them with new relations that are assumed to
> appear out of thin air.
Consider:
i := i + 1;
Note that the new value of i didn't just appear out of thin air; it was
in fact based on the previous value of i.
Given:
variable T : relation of r;
update_fn : r -> r // takes one record and returns new, updated
record
filter_fn : r -> boolean // indicator function
insert(T, new_rows) => { T := T union new_rows; }
update(T, update_fn, filter_fn) => {
transaction {
let Tmp = filter(T, filter_fn); // select only those rows to
update
T := T minus Tmp;
T := T union update_fn(Tmp);
}
}
delete(T,filter_fn) => { T := T minus filter(T, filter_fn); }
So we can define insert, update and delete in terms of relational
assignment, relational subtraction, and relational union. Type
checking details omitted.
Marshall
------------------------------
Date: Mon, 17 Jul 2006 19:17:56 GMT
From: David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
Subject: Re: What is a type error?
Message-Id: <EnRug.7549$5B3.3215@fe2.news.blueyonder.co.uk>
Darren New wrote:
> From what I can determine, the authors seem to imply that typestate is
> dataflow analysis modified in (at least) two ways:
>
> 1) When control flow joins, the new typestate is the intersection of
> typestates coming into the join, where as dataflow analysis doesn't
> guarantee that. (They imply they think dataflow analysis is allowed to
> say "the variable might or might not be initialized here", while
> typestate would ensure the variable is uninitialized.)
Right, but this is a disadvantage of their typestate algorithm. It is why
the example in Figure 2 of
<http://www.cs.ubc.ca/local/reading/proceedings/spe91-95/spe/vol25/issue4/spe950wk.pdf>
fails to check, even though it "obviously" initializes all variables.
Consider the equivalent Java program:
public class LoopInitTest {
public static void main(String[] args) {
boolean b;
int i;
while (true) {
b = true;
if (b) {
v = 1;
}
v = v + 1;
}
}
}
As it happens, javac rejects this:
LoopInitTest.java:12: variable v might not have been initialized
v = v + 1;
^
but for a different and more trivial reason than the Hermes algorithm.
Change "if (b) { v = 1; }" to just "v = 1;", and the Java version will be
accepted by its definite assignment analysis (which is a dataflow analysis),
but the equivalent Hermes program still would not.
--
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
------------------------------
Date: Mon, 17 Jul 2006 13:25:13 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is a type error?
Message-Id: <MPG.1f259200b8db1bc09896a0@news.altopia.net>
Marshall <marshall.spight@gmail.com> wrote:
> > If the relations are to
> > be considered opaque, then there's clearly no aliasing going on.
>
> Not certain I understand, but I think I agree.
My condition, though, was that relations be opaque. Since you will be
violating that condition further on down, I just felt that it's useful
to point that out here.
> No, such a language is entirely useful, since relational assignment
> is *more* expressive than insert/update/delete.
Assignment is more powerful *as* assignment. However, it is less
powerful when the task at hand is deriving new relations from old ones.
Assignment provides absolutely no tools for doing that. I thought you
were trying to remove those tools from the language entirely in order to
remove the corresponding aliasing problems. I guess I was wrong, since
you make it clear below that you intend to keep at least basic set
operations on relations in your hypothetical language.
> Consider:
>
> i := i + 1;
>
> Note that the new value of i didn't just appear out of thin air; it was
> in fact based on the previous value of i.
Right. That's exactly the kind of thing I thought you were trying to
avoid.
> So we can define insert, update and delete in terms of relational
> assignment, relational subtraction, and relational union. Type
> checking details omitted.
Then the problem is in the step where you assign the new relation to the
old relational variable. You need to check that the new relation
conforms to the invariants that are expressed on that relational
variable. If you model this as assignment of relations (or relation
values... I'm unclear on the terminology at this point) then naively
this requires scanning through an entire set of relations in the
constraint, to verify that the invariant holds. You've may have avoided
"aliasing" in any conventional sense of the word by stretching the word
itself beyond breaking... but you've only done it by proactively
accepting its negative consequences.
It remains non-trivial to scan through a 2 GB database table to verify
that some attribute of every tuple matches some attribute of another
table, even if you call the entire thing one relational variable. The
implementation, of course, isn't at all going to make a copy of the
entire (possibly several GB) relation and rewrite it all every time it
makes a change, and it isn't going to give up and rescan all possible
invariants every time every change is made. In other words, you've
risen to a layer of abstraction where the aliasing problem does not
exist. The implementation is still going to deal with the aliasing
problem, which will resurface once you pass over to the other side of
the abstraction boundary.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
Date: 17 Jul 2006 14:00:53 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is a type error?
Message-Id: <1153170053.499642.14840@b28g2000cwb.googlegroups.com>
Chris Smith wrote:
> Marshall <marshall.spight@gmail.com> wrote:
> > > If the relations are to
> > > be considered opaque, then there's clearly no aliasing going on.
> >
> > Not certain I understand, but I think I agree.
>
> My condition, though, was that relations be opaque. Since you will be
> violating that condition further on down, I just felt that it's useful
> to point that out here.
>
> > No, such a language is entirely useful, since relational assignment
> > is *more* expressive than insert/update/delete.
>
> Assignment is more powerful *as* assignment. However, it is less
> powerful when the task at hand is deriving new relations from old ones.
At the implementation level, it makes some things harder, however
as a logical model, it is more powerful. While this is very much a real
world issue, it is worth noting that it is a performance issue *merely*
and not a semantic issue.
> Assignment provides absolutely no tools for doing that. I thought you
> were trying to remove those tools from the language entirely in order to
> remove the corresponding aliasing problems. I guess I was wrong, since
> you make it clear below that you intend to keep at least basic set
> operations on relations in your hypothetical language.
>
> > Consider:
> >
> > i := i + 1;
> >
> > Note that the new value of i didn't just appear out of thin air; it was
> > in fact based on the previous value of i.
>
> Right. That's exactly the kind of thing I thought you were trying to
> avoid.
I was under the impression tat Joachim, for example, did not
consider "i+1" as an alias for i.
> > So we can define insert, update and delete in terms of relational
> > assignment, relational subtraction, and relational union. Type
> > checking details omitted.
>
> Then the problem is in the step where you assign the new relation to the
> old relational variable. You need to check that the new relation
> conforms to the invariants that are expressed on that relational
> variable. If you model this as assignment of relations (or relation
> values... I'm unclear on the terminology at this point) then naively
> this requires scanning through an entire set of relations in the
> constraint, to verify that the invariant holds. You've may have avoided
> "aliasing" in any conventional sense of the word by stretching the word
> itself beyond breaking... but you've only done it by proactively
> accepting its negative consequences.
>
> It remains non-trivial to scan through a 2 GB database table to verify
> that some attribute of every tuple matches some attribute of another
> table, even if you call the entire thing one relational variable. The
> implementation, of course, isn't at all going to make a copy of the
> entire (possibly several GB) relation and rewrite it all every time it
> makes a change, and it isn't going to give up and rescan all possible
> invariants every time every change is made. In other words, you've
> risen to a layer of abstraction where the aliasing problem does not
> exist. The implementation is still going to deal with the aliasing
> problem, which will resurface once you pass over to the other side of
> the abstraction boundary.
Yes, these *performance* issues make assignment prohibitive for
real-world use, at least if we are talking about data management
in the large. This is not the same thing as saying the resulting
language is a toy language, though; its semantics are quite
interesting and possibly a better choice for *defining* the semantics
of the imperative operations than directly modelling the imperative
operations. (Or maybe not.) In any event, it's worth thinking about,
even if performance considerations make it not worth implementing.
Marshall
------------------------------
Date: Mon, 17 Jul 2006 15:48:00 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is a type error?
Message-Id: <MPG.1f25b37cb34eb3729896a1@news.altopia.net>
Marshall <marshall.spight@gmail.com> wrote:
> Yes, these *performance* issues make assignment prohibitive for
> real-world use, at least if we are talking about data management
> in the large. This is not the same thing as saying the resulting
> language is a toy language, though; its semantics are quite
> interesting and possibly a better choice for *defining* the semantics
> of the imperative operations than directly modelling the imperative
> operations. (Or maybe not.) In any event, it's worth thinking about,
> even if performance considerations make it not worth implementing.
My "toy language" comment was directed at a language that I mistakenly
thought you were proposing, but that you really weren't. You can ignore
it, and all the corresponding comments about assignment being less
powerful, etc. I was apparently not skilled at communication when I
tried to say that in the last message.
It is, perhaps, worth thinking about. My assertion here (which I think
I've backed up, but there's been enough confusion that I'm not surprised
if it was missed) is that the underlying reasons that performance might
be poor for this language are a superset of the performance problems
caused by aliasing. Hence, when discussing the problems caused by
aliasing for the performance of language implementations (which I
believe was at some point the discussion here), this isn't a
particularly useful example.
It does, though, have the nice property of hiding the aliasing from the
semantic model. That is interesting and worth considering, but is a
different conversation; and I don't know how to start it.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
Date: 17 Jul 2006 13:29:48 -0700
From: ewaguespack@gmail.com
Subject: Re: why is perl -e 'unlink(glob("*"))' so much faster than rm ?
Message-Id: <1153168188.414592.220420@m79g2000cwm.googlegroups.com>
>
> The find was spawning a new instance of 'rm' for each file - very inefficient.
>
> The equivalent to your Perl code would be to use find to get a list of files,
> and then use 'xargs' to pass that whole list to one instance of 'rm':
>
> find . -type f -print0 | xargs -0 rm -f
>
> sherm--
thanks for the info everyone.
-op
------------------------------
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 9491
***************************************
