Front page | perl.perl5.porters |
Postings from July 2010
On Thu, Jul 15, 2010 at 10:31:51AM +0200, demerphq wrote:
> On 15 July 2010 01:12, Dave Mitchell <davem@iabyn.com> wrote:
> > On Wed, Jul 14, 2010 at 09:39:35AM +0200, demerphq wrote:
> >> Whomever decided that
> >>
> >> $a . $a
> >>
> >> is specified when $a is tied and returns a different value each fetch
> >> had forgotten this fact.
> >
> > You'll have to argue that with Hugo then!
> >
> > commit 8d6d96c1bf85fd984f18f84ea834be52b168c812
> > Author: Hugo van der Sanden <hv@crypt.org>
> > AuthorDate: Sat May 26 18:05:12 2001 +0100
> > Commit: Jarkko Hietaniemi <jhi@iki.fi>
> > CommitDate: Sat May 26 22:31:46 2001 +0000
> >
> > Re: 5.6.*, bleadperl: bugs in pp_concat
> > Message-Id: <200105261605.RAA12295@crypt.compulink.co.uk>
>
> I'm not sure what your point is? Simply because Hugo wrote/pushed a
> patch that somehow proves something?
I wasn't making a point, I was just providing information.
> I don't think so. Just because a
> commiter didn't think through the full ramifications of a patch, or
> even knew of the ramifications but still went through with it on the
> grounds of providing "least worst" behaviour doesn't make that patch
> law over long existing documentation.
>
> The documentation for ++ is pretty clear.
>
> If the concatenation of a tied variable that mutates is well
> specified, then it would mean that one can take a construct documented
> to have unspecified behaviour wrap it up in a tie to resolve the
> unspecifiedness, which seems to me to be simply absurd.
>
> Thus the onus is not on me to show why this is unspecified, as the
> docs say it is, the onus instead is on those who disagree with the
> documentation to find a way to get out of this logical absurdity.
>
> I have to say that I'm struggling to see why what you just posted
> doesn't essentially boil down to a position that the docs are
> meaningless and that whatever is committed is right. If so then you
> might as well stop fixing those "bugs" as they aren't really "bugs"
> then are they? I'm pretty sure you don't think this, so why do you
> think that this patch is different?
Just to make it clear, I didn't post that patch to prove a point one way
of another, I just dug it up as a point of info so that people could, if
interested, examine it, look at at the reasoning behind it (e.g. the p5p
discussion if any), and draw whatever conclusions they want. For the
record, I haven't read the original 2001 p5p thread, and haven't drawn any
conclusions.
However, for my opinions for the topic in hand...
as regards tiedness, there are actually two orthogonal issues of
correctness. The first is which order in which the two $a's in $a.$a are
evaluated; the second is how many times $a is evaluated. It is quite
possible for the order not to be defined, but still for the fact that $a
is evaluated twice to be defined. For example, someone might be using tie
to instrument the number of accesses to a variable. Having said that, tied
hash elements only have mg_get called once on them until reset by a
mg_set, and I recently extended that mechanism to tied arrays too.
On the other hand, it may not be documented or specified, but I think most
people would expect that in the following, f() is called before g():
$f() . $g()
Finally, my feeling is that any 'no magic;' scopes aren't really viable in
terms of providing enough guarantees of side-effects for aggressive
optimisation while still providing perly behaviour.
--
There's a traditional definition of a shyster: a lawyer who, when the law
is against him, pounds on the facts; when the facts are against him,
pounds on the law; and when both the facts and the law are against him,
pounds on the table.
-- Eben Moglen referring to SCO
Thread Previous
|
Thread Next