Front page | perl.perl5.porters |
Postings from July 2011
Yes, view is a better name than bind.
On Sun, Jul 03, 2011 at 03:26:06PM -0700, Chip Salzenberg wrote:
> However:
>
> What views offer are the ability to add semantics - filters - to the
> aliasing. The only current use case, perhaps the only ever, is adding
> read-only-ness. So after something like
I'm not sure if there is any other use case likely.
I'm also wondering whether it would make the implementation easier if all
views were read only. I don't think that there's any use case for read-write
views, given than the C APIs to all perl storage already permit direct
aliasing.
Also, right now, I think that only read-only views of read-write scalars
will work. SvREADONLY() doesn't currently mean anything on arrays, hashes
(typeglobs etc). Even worse, SVf_READONLY is hijacked on hashes to mean
"restricted hash", so they would have to be moved out of the way to allow
anything.
What does "read only" mean on an array or hash? Is it deep or shallow?
Does making a read only alias only stop you adding/removing entries
(effectively making the keys or indices read only), or does it treat the
entire structure as immutable?
I wondered what we can steal from Perl 6:
13:12 < moritz_> it's not recursive
13:12 < pmichaud> the readonly-ness is somewhat shallow, iiuc
13:13 < moritz_> to the best of my knowledge, sub f(@a) { @a = ... } #
forbidden
13:13 < moritz_> sub f(@a) { @a[0] = ... } # forbidden, but the compiler
doesn't have to enforce it
13:14 < moritz_> @a[0].some-rw-attrib = "foo"; # allowed
13:14 < jnthn> There's a bunch of open questions in this area
13:14 < moritz_> nwc10: in the end, it will boil down to a compromise between
performance and safety
13:15 < moritz_> nwc10: only experimenting with the implementations will show
what's feasible
13:15 * jnthn is hoping that we can do enough detection of these things at
compile time to cope
13:15 < jnthn> And not have to do any extra runtime checks
13:18 < jnthn> nwc10: If it's down to me, we'll do nothing about this at
runtime, and detect the obvious cases statically
13:18 < jnthn> nwc10: Here's the thing. Indexed access in Perl 6 is a method
call
13:18 < jnthn> And we agree that mutating method calls don't fall under the
heading of what ro enforces.
13:19 < jnthn> So in my book that means that @a[0] = 42 ==> @a.postcircumfix:<[
]>(0) = 42
13:19 < jnthn> Is a method call
13:20 < jnthn> Anyway, to me there's no difference between @x[0] = 42 and $x.y
= 42 in Perl 6 really, so any additional readonlyless is hard to
enforce.
Which suggests that "shallow" is a reasonable answer.
> For this reason I expect the first merged code for views will not have any
> syntax at all, but only an XS module with some utility functions.
On Mon, Jul 04, 2011 at 11:11:43PM +0200, Steffen Mueller wrote:
> As a matter of fact, it's one of those cases where in terms of syntax,
> if we provide hooks to XS modules, people can experiment on CPAN with
> all the crazy Devel::Declare they like until we eventually converge on a
> best of breed. Or not. We'll see.
Yes, for now I think what we need is the low level functionality that makes
the high level experimentation possible in the first place.
Nicholas Clark
Thread Previous
|
Thread Next