develooper Front page | perl.perl5.porters | Postings from July 2011

Re: Why views are useful, and why their syntax doesn't matter much

Thread Previous | Thread Next
Nicholas Clark
July 7, 2011 05:31
Re: Why views are useful, and why their syntax doesn't matter much
Message ID:
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

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

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 = ... } # 
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 

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 

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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About