Em Ter, 2010-04-06 às 22:19 -0700, Damian Conway escreveu:
> > I kinda hope we can get a bit further away from the machine code
> > level of reality one of these decades. Perl 6 should not be
> > optimized for C semantics.
> Agreed. But it should at least support those who need to work at
> the machine code level, but would prefer not to have to do so in C.
While I agree with all the reasoning...
I just like to point that currently they are not required to do so in C.
Using bitsets in Perl 6 is just as easy as using in Perl 5 -- which
happens to be the same as using in C, but it's not C...
constant PERM_WRITE = 0b0001;
constant PERM_READ = 0b0010;
constant PERM_EXEC = 0b0100;
constant PERM_NAMES = { PERM_WRITE => 'Write',
PERM_READ => 'Read',
PERM_EXEC => 'Exec' };
subset Perm of Int where * < 8;
my Perm $perm = PERM_WRITE +| PERM_READ;
if ($perm +& PERM_WRITE) { say 'can write' }
my @names =
map { PERM_NAMES{$_} },
grep { $_ +& $perm },
(PERM_WRITE, PERM_READ, PERM_EXEC);
> That said, I'd be perfectly happy to encourage the use of proper set
> abstractions for this purpose, so long as the long-suffering hardware
> engineers can still easily convert the final set to an appropriate
> bit-pattern when it's time to pump the results out to the hardware.
The thing that bugs me is that sets have way more uses then bitsets, and
we might be overspecializing sets to support that semantics.
Because proper set abstractions won't allow you to explicitly define how
the bitset is composed (which member has each value) -- at least I dont'
see it at this point -- since that's just an optimization because you're
dealing with a set of small integers.
If there's a strong case for bitsets, maybe it's worth having a
specialized declarator.
daniel
