Jonathan Lang wrote:
> Wouldn't that be C< = 0...* >?
Indeed. Thanks for the correction.
> That said, don't we already have a means of assigning specific values
> to individual members of an enum? I forget the exact syntax,
The exact syntax is:
enum Perms [Read => 1, Write => 2, Exec => 4, Fold => 8, Spindle
=> 16, Mutilate => 32]
or
enum Perms << :Read(1), :Write(2), :Exec(4), :Fold(8),
:Spindle(16), :Mutilate(32) >>
or any other variation that uses a list of pairs.
> Clumsy, sure;
The clumsiness isn't the main problem, in my view; the explicitness of
having to provide the values is.
Even the hyperoperated version (which isn't currently legal, BTW)
requires an explicit series to generate the values. Yet the whole point
of enums is to avoid explicitly enumerating the values (as far as
possible).
The secondary point here is that an enum type doesn't solve the original
problem, since it won't allow combinations of enumerated values:
enum Perms [Read => 1, Write => 2, Exec => 4, Fold => 8, Spindle
=> 16, Mutilate => 32];
my Perms $perms = Read +| Write; # Error
I'm now strongly convinced that a module is the right answer here. We
have the need for a datatype that is essential is a couple of domains,
but much better handled via Sets in most other contexts. So it's
inherently a special-purpose datatype, and hence not appropriate in the
core language. And Perl 6 already provides the macro mechanism needed to
allow such a datatype to be seamlessly added with a convenient and
"natural" syntax. Which is what I shall eventually do, I suspect.
In that sense this discussion *vindicates* the current design,
demonstrating that it provides the necessary flexibility and tools to
allow someone to implement a new datatype and declarator syntax and
integrate them seamlessly into the language, without having to redefine the
language itself...or modify the compiler.
Damian
