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
From:
Reini Urban
Date:
July 7, 2011 08:12
Subject:
Re: Why views are useful, and why their syntax doesn't matter much
Message ID:
CAHiT=DFN5=UmSNHFAmP1vzqTBSC3C+U=WR0f6TS+hsnHY7ntBg@mail.gmail.com
2011/7/7 Nicholas Clark <nick@ccl4.org>:
> 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.

Oh my. This is awful, as we don't have any more bits in the sv_flags left.
For my reading a readonly hash is a generalization of a restricted hash.
Any readonly hash is automatically restricted.
http://perldoc.perl.org/Hash/Util.html#Restricted-hashes

But then Hash::Util::lock_keys does not only lock the keys, also the values.
Which is not right as lock_value is used to lock them individually.
So a READONLY hash would need a deep lock, which is too slow to check.
Need to check every value for readonly.
Esp. for my use cases of compile-time optimizations and lock-free
hashes for threads.

Cannot we just change Hash::Util::lock_keys to use another flag for
shallow read-only?

> 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 would say both, keys and values. Otherwise it would be impossible to
do compile-time optimisations and threads implementations.

From my knowledge of other languages non-readonly hashes are the worst
problem for thread implementations.

Some of my ideas for readonly hashes are outlined in
http://blogs.perl.org/users/rurban/2011/02/use-types.html
and Sam Vilain would need it also for threads::tbb::concurrent
http://openparallel.com/2011/07/05/a-new-hope-for-efficient-safe-data-sharing-between-threads-in-perl/

> 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.
-- 
Reini Urban
http://phpwiki.org/           http://murbreak.at/

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About