Re: A shorter long dot
On 5/1/06, Paul Johnson [EMAIL PROTECTED] wrote:
Maybe you all write your code differently to me, but looking through a
load of my OO code I had trouble finding three method calls in a row to
any methods on any objects, let alone six calls to the same method name
on different objects.
If I saw code like
$xyzzy.foo();
$fooz\.foo();
$foo\ .foo();
$fa\ .foo();
$and_a_long_one_I_still_want_to_align\
.foo();
$etc\ .foo();
I'd probably take that as a pretty strong clue that I should really have
written
$_.foo for @things_to_foo;
or something.
I like lining up my code as much as the next programmer, and probably a
lot more, but I just don't see the need for this syntax which seems
ugly, confusing and unnecessary.
But then again, as I said, I really don't see the problem that is being
solved.
This long-dot can be used for many things, not just method calls.
IMHO This example from S03 is a lot better:
quote
Whitespace is no longer allowed before the opening bracket of an array
or hash accessor. That is:
%monsters{'cookie'} = Monster.new; # Valid Perl 6
%people {'john'} = Person.new; # Not valid Perl 6
One of the several useful side-effects of this restriction is that
parentheses are no longer required around the condition of control
constructs:
if $value eq $target {
print Bullseye!;
}
while 0 $i { $i++ }
It is, however, still possible to align accessors by explicitly using
the long dot syntax:
%monsters.{'cookie'} = Monster.new;
%people\ .{'john'} = Person.new;
%cats\ .{'fluffy'} = Cat.new;
/quote
--
Markus Laire
Linking Synopses to corresponding pod-files?
When reading Synopses, I sometimes notice some mistakes or typos, which I'd like to submit a patch for, but it's not easy to do so as I don't know where to get the source. Could each Synopsis include a link to the corresponding .pod (if it's available in Internet, that is), so that submitting patches would be easier? -- Markus Laire
Re: Linking Synopses to corresponding pod-files?
Markus Laire skribis 2006-05-04 14:55 (+0300): When reading Synopses, I sometimes notice some mistakes or typos, which I'd like to submit a patch for, but it's not easy to do so as I don't know where to get the source. Have you tried s/html/pod/? :) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: A shorter long dot
On Thu, May 04, 2006 at 01:56:44PM +0300, Markus Laire wrote:
On 5/1/06, Paul Johnson [EMAIL PROTECTED] wrote:
But then again, as I said, I really don't see the problem that is being
solved.
This long-dot can be used for many things, not just method calls.
Thanks for taking the time to explain this. The long dot here does seem to be
solving more important problems. Now I'm not as up to date with Perl 6 syntax
as I once was, nor as much as I probably should be to be part of this thread,
but ...
IMHO This example from S03 is a lot better:
quote
Whitespace is no longer allowed before the opening bracket of an array
or hash accessor. That is:
%monsters{'cookie'} = Monster.new; # Valid Perl 6
%people {'john'} = Person.new; # Not valid Perl 6
What does Not valid Perl 6 mean? A syntax error? Is it not possible
to make it valid and to mean what would be meant without the whitespace?
Thinking about it a bit, I suppose the problem would be how to parse
something like
if $person eq %people {'john'} { ... }
which would be valid whichever way you parsed it, right?
One of the several useful side-effects of this restriction is that
parentheses are no longer required around the condition of control
constructs:
if $value eq $target {
print Bullseye!;
}
while 0 $i { $i++ }
It is, however, still possible to align accessors by explicitly using
the long dot syntax:
%monsters.{'cookie'} = Monster.new;
%people\ .{'john'} = Person.new;
%cats\ .{'fluffy'} = Cat.new;
/quote
I'm probably not seeing what the rest of the several useful
side-effects are, and I'm probably far too conservative, but given the
choice between the following I know which one I would choose.
if ($value eq $target) {
$monsters{cookie} = Monster-new;
$people {john } = Person -new;
$cats{fluffy} = Cat-new;
}
if $value eq $target {
%monsters.{'cookie'} = Monster.new;
%people\ .{'john' } = Person\.new;
%cats\ .{'fluffy'} = Cat\ .new;
}
if $value eq $target {
%monsters.cookie = Monster.new;
%people\ .john = Person\.new;
%cats\ .fluffy = Cat\ .new;
}
However, I'm really not looking to drive perl6-language round in circles, so if
there is some document somewhere explaining the rest of the several useful
side-effects I'd love a pointer to it (I couldn't find anything appropriate).
Otherwise I'll hope that, as has happened a number of times before, someone
will decide that this is too ugly to live and will create something nicer.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
RFC: Community education page
I was chatting with a P6 person the other day (who can remain nameless unless he chooses to identify himself). He made the following observation: Every time we're lambasted for how long Perl 6 is taking I remind myself that Short Term Thinking is the norm now. I think there are a couple of reasons for this lambasting, and the more important (and remediable) one is lack of education on the part of the baster. They don't understand : (A) how hard it is to design a language; and, (B) how much progress really has been made. I'd like to propose that there be a single web page (or maybe a small wiki, but one page might be preferable) somewhere that could be pointed at to show just how much has been done. It could list all the CPAN modules in the Bundle::Perl6 module (are those all Perl6 modules explicitly or are some of them support framework?), all the sites where Pugs has been deployed in production (I gather there are some?), any non-toy / non-arcane projects that are being worked on in Perl6, etc. I suppose it could also list the various language implementations that are targetting Parrot, but that's much less impressive to the common hacker who just wants to get work done, and not terribly relevant to the question Why is __Perl6__ taking time?. Also, the page should talk about why it is difficult to do what is being done. Ask the reader questions: You want to support continuations / have coroutines / embedd yacc in your language / whatever. How do you do it? Then offer up an analysis of various design choices that were considered and rejected and why. In particular, since the average person probably thought of the naïve answer, shoot big holes in that one. That way they sit up and say Oh. Hmm, I guess this really is kinda hard. I see this as a small effort towards community outreach, where community is both the existing Perl people and the wider Internet. I volunteer to create the page, host it, and maintain it, but I would need help gathering the information in the first place. And if the Perl6 community doesn't think it's a good idea, then I won't bother. Comments? --Dks
Re: RFC: Community education page
On Thu, May 04, 2006 at 10:44:29AM -0400, David K Storrs wrote:
Also, the page should talk about why it is difficult to do what is
being done. Ask the reader questions: You want to support
continuations / have coroutines / embedd yacc in your language /
whatever. How do you do it? Then offer up an analysis of various
design choices that were considered and rejected and why.
I think this will see a lot of use, not just in terms of people really
outside the perl6 project, looking at it, and wondering what's taking so
long, but also people on the semi-inside, trying to remember things like
I'm sure there's a reason other then C if condition_without_parens
{block} that we can't have C %foo {'bar'} DTRT, but I can't
remember it, which certianly happens to me fairly often.
Also, as a checklist for proposals. If you're thinking of proposing
something, go look there. If it's already there, do you have any new pros
to put against the existing cons?
-=- James Mastros
Re: RFC: Community education page
On May 4, 2006, at 10:59 AM, [EMAIL PROTECTED] wrote:
On Thu, May 04, 2006 at 10:44:29AM -0400, David K Storrs wrote:
Also, the page should talk about why it is difficult to do what is
being done. Ask the reader questions: You want to support
continuations / have coroutines / embedd yacc in your language /
whatever. How do you do it? Then offer up an analysis of various
design choices that were considered and rejected and why.
I think this will see a lot of use, not just in terms of people really
outside the perl6 project, looking at it, and wondering what's
taking so
long, but also people on the semi-inside, trying to remember things
like
I'm sure there's a reason other then C if condition_without_parens
{block} that we can't have C %foo {'bar'} DTRT, but I can't
remember it, which certianly happens to me fairly often.
Also, as a checklist for proposals. If you're thinking of proposing
something, go look there. If it's already there, do you have any
new pros
to put against the existing cons?
-=- James Mastros
That's an advantage I hadn't thought of.
We'd have to be careful to keep it brief, though. The whole point is
that this is supposed to be a single page that can be read in a
reasonable period of time (~10 mins). It's supposed to answer one
question: Why should I still be excited about Perl6 even though
it's taking longer than was expected?, not a horde of questions like
why were coroutines implemented that way? and such.
--Dks
Re: RFC: Community education page
On Thu, May 04, 2006 at 03:59:47PM +0100, [EMAIL PROTECTED] wrote:
but also people on the semi-inside, trying to remember things like
I'm sure there's a reason other then C if condition_without_parens
{block} that we can't have C %foo {'bar'} DTRT, but I can't
remember it, which certianly happens to me fairly often.
Well, I'd obviously quite like that ;-)
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Perl 6 Perl 6 Wiki Wiki (RFC: Community education page)
Not entirely related, but: it would be great if someone wrote usable wiki software (with revision control support) in Perl 6, and could maintain it so that it keeps up with Pugs. Because of the current state of Pugs, it will have to be written in a very simple way. Especially if it looks great on the outside, this will do Perl 6 much good. I've been meaning to do this myself, but I'm past the point where I give up waiting for sufficient sufficiently round tuits. Of course, feather can host it :) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Linking Synopses to corresponding pod-files?
On 5/4/06, Juerd [EMAIL PROTECTED] wrote: Markus Laire skribis 2006-05-04 14:55 (+0300): When reading Synopses, I sometimes notice some mistakes or typos, which I'd like to submit a patch for, but it's not easy to do so as I don't know where to get the source. Have you tried s/html/pod/? :) Thanks :) -- Markus Laire
Re: A shorter long dot
On 5/4/06, Paul Johnson [EMAIL PROTECTED] wrote:
On Thu, May 04, 2006 at 01:56:44PM +0300, Markus Laire wrote:
Thanks for taking the time to explain this. The long dot here does seem to be
solving more important problems. Now I'm not as up to date with Perl 6 syntax
as I once was, nor as much as I probably should be to be part of this thread,
but ...
IMHO This example from S03 is a lot better:
quote
Whitespace is no longer allowed before the opening bracket of an array
or hash accessor. That is:
%monsters{'cookie'} = Monster.new; # Valid Perl 6
%people {'john'} = Person.new; # Not valid Perl 6
What does Not valid Perl 6 mean? A syntax error? Is it not possible
to make it valid and to mean what would be meant without the whitespace?
Yep, I think it's syntax error.
Note that {} here is a postfix (actually postcircumfix) operator, and
the decision to never allow whitespace before postfix operators seems
to be quite fundamental in perl6.
Some relevant sections from Synopses:
(These sections are quite long, so I'm not copy-pasting them here.)
From Synopsis 2 at http://dev.perl.org/perl6/doc/design/syn/S02.html
See the section starting with In general, whitespace is optional in
Perl 6 except
From Synopsis 3 at http://dev.perl.org/perl6/doc/design/syn/S03.html
See the section starting with List operators are all parsed consistently.
And Synopsis 4 at http://dev.perl.org/perl6/doc/design/syn/S04.html
is also related to this.
However, I'm really not looking to drive perl6-language round in circles, so if
there is some document somewhere explaining the rest of the several useful
side-effects I'd love a pointer to it (I couldn't find anything appropriate).
Have you *recently* read the Synopses at
http://dev.perl.org/perl6/doc/synopsis.html
I'm currently re-reading them, and if you have some time (few days or
weeks :), I'd suggest reading them all.
--
Markus Laire
using the newer collection types
As I carry on in my spare time to implement a Relation type for Perl
6, I would like to use some of the simpler types that were added to
the Synopsis recently and seem to lack a lot of explanatory details
that older types have, and moreover they don't seem to be implemented
yet in Pugs.
So I have a few questions whose answers should clarify the intended
meaning and features of these newer types, as well as the syntax for
declaring them.
Some relevant example types from Synopsis 6:
Immutable types
Objects with these types behave like values, i.e. C$x === $y is true
if and only if their types and contents are identical.
ListLazy Perl list (composed of Seq and Range parts)
Seq Completely evaluated (hence immutable) sequence
Range Incrementally generated (hence lazy) sequence
Set Unordered Seqs that allow no duplicates
JunctionSets with additional behaviours
PairSeq of two elements that serves as an one-element Mapping
Mapping Pairs with no duplicate keys
Signature Function parameters (left-hand side of a binding)
Capture Function call arguments (right-hand side of a binding)
Mutable types
Objects with these types have distinct C.id values.
Array Perl array
HashPerl hash
The intended new Relation type could be described like this, if I
correctly understand the meaning of the existing types:
Immutable types
RelationSet of Mappings where all Mappings have the same keys
Speaking a little more technically, a Relation has 2 main components,
its heading and its body. The heading is a set of 0..N keys (called
attributes in relation-land), and the body is a set of 0..N
Mappings (called tuples in relation-land), where they set of keys
of each Mapping is identical to the Relation's heading. Its very
likely that a language-embedded Relation implementation would
actually not repeat the keys for each member Mapping, but we can
conceptualize as if they were present for simplicity.
The operations that you can do with a Relation are a proper super-set
of those you can do with a Set. So, the Relation type supports all
the same Set operators, with the same meanings, such as: equal(),
subset(), superset(), union(), intersection(), difference(),
symmetric_difference(), none(), any(), all(), member_exists(),
members(), member_count(). Moreover, the Relation type has these
operators that the Set type doesn't have: rename(), project(),
restrict(), extend(), join(), divide(), summarize(), group(),
ungroup(), wrap(), unwrap(), matching(), etc. Moreover, there would
probably be convenience wrapper functions over combinations of the
above operators such as insert(), update(), delete(), etc, though
they aren't essential (those examples are not mutators, despite their
name-sakes). Some extra operators like sort() would also be
provided, which convert Relations to Seqs or Arrays.
Now, some of the questions:
1. Are Sets or Junctions allowed to contain undefined elements? Can
undef be a key of a Mapping or Hash?
2. What actually is the practical distinction between a Set and a
Junction? Why would someone use one over the other? I recognize
that the use of Junctions is supposed to make parallelism easier, as
iterating through one is known to be order independent. But,
conceptually a Set and a Relation are exactly the same; you could
process their members in any order and/or in parallel as well. So is
the use of a Junction effectively like a compiler flag to make
certain kinds of Set ops faster at the expense of others?
3. Is a Signature like the keys of a Mapping but that it has extra
stuff like associated types and such? Can one declare and use a
Signature separately from declaring a function?
4. What is the syntax for declaring anonymous Sets and Mappings? I
am already aware of these syntax for other types (correct me if I'm
wrong):
$a = [1,2,3]; # Array
$b = {'x'=2,'y'=4}; # Hash
$c = (1=2); # Pair
$d = (1,2,3); # Seq
$e = 1..5;# Range
$f = all(1,2,3); # Junction
If this hasn't yet been decided, might I suggest the following?:
$g = set(1,2,3); # Set
$h = ('x'=2,'y'=4); # Mapping
If that works, then perhaps an anonymous Relation declartion could look like:
$r = relation( set( 'x', 'y' ): ('x'=2,'y'=4), ('x'=5,'y'=6) );
I'm not particular with the exact syntax; it just needs to be something good.
Note that a terse form of this could leave out the heading
declaration if at least one Mapping/tuple is provided, since that
contains the same key list.
$r = relation( ('x'=2,'y'=4), ('x'=5,'y'=6) );
Then the heading declaration is only needed if the Relation has no
Mappings/tuples.
$r = relation( set( 'x', 'y' ): );
5. What is the syntax for subscripting or extracting Mapping
components? Eg, can we use the same .keys, .values, .pairs, etc that
we use
Re: using the newer collection types
Darren Duncan wrote:
Speaking a little more technically, a Relation has 2 main components,
its heading and its body. The heading is a set of 0..N keys (called
attributes in relation-land), and the body is a set of 0..N
Mappings (called tuples in relation-land), where they set of keys
of each Mapping is identical to the Relation's heading. Its very
likely that a language-embedded Relation implementation would
actually not repeat the keys for each member Mapping, but we can
conceptualize as if they were present for simplicity.
I don't think this terminology or these restrictions are particularly
useful.
I do think that a Pair should be a sub-type of a more general Tuple
type, with the 'where' clause being { .items == 2 } or something like that.
I think that the most flexible arrangement is to define;
- a Collection as a Bag of Tuples
- a Relation as a Collection where the tuples have a shape and no
duplicate tuples are allowed (but Relation does not need to be a core type)
Then, Mappings, Sequences, etc, become sub-types of one of the above two
types. For instance, a sequence is a Collection of (Int, Any) where the
first Int is unique across the collection. Similarly a Mapping is a
Collection of (Any, Any) where Unique(0).
something like
role Tuple { has @.items };
role Collection { has Tuple @.tuples };
subset Pair of Tuple where { .items.items == 2 };
subset Bag of Collection where { ! .tuples.grep:{.items 1 } }
subset Set of Bag where {
all( .tuples.map:{ .items } ) == one( .tuples.map:{ .items } )
}
subset Mapping of Collection where { ! .tuples.grep:{ .items != 2 } }
subset Array of Mapping where { .tuples.grep:{ .items[0].isa(Int) } }
subset Hash of Mapping where { .tuples.grep:{ .items[0].does(Str) } }
The above should probably all be written in terms of parametric roles
(see S12), but for now the above run-time checking versions should
hopefully express the relationships between the core collection-like
types as I see them.
That sounds like it might bite, but you wouldn't normally access an
Array as a Collection of (Int, Any), you'd access it as an Array, so you
get the nice .post_circumfix:[ ] method that makes array access easy.
You don't care that it has this higher order type as a parent class, and
you certainly wouldn't care for the 'bare' Collection interface (as for
one, you don't want to have to deal with the Integer keys). And it is
probably all backed by native methods.
I'm prototyping much of this using Moose in Perl 5, however Hubris is
delaying its release :-)
Moreover, the Relation type has these
operators that the Set type doesn't have: rename(), project(),
restrict(), extend(), join(), divide(), summarize(), group(),
ungroup(), wrap(), unwrap(), matching(), etc.
Is there a reference for the meaning of these methods?
1. Are Sets or Junctions allowed to contain undefined elements? Can
undef be a key of a Mapping or Hash?
undef.isa(Object), so you should be able to use it as you would any
other object. I would definitely not think of it as the absence of a
value in this context.
2. What actually is the practical distinction between a Set and a
Junction? Why would someone use one over the other? I recognize
that the use of Junctions is supposed to make parallelism easier, as
iterating through one is known to be order independent. But,
conceptually a Set and a Relation are exactly the same; you could
process their members in any order and/or in parallel as well. So is
the use of a Junction effectively like a compiler flag to make
certain kinds of Set ops faster at the expense of others?
Well one side effect at the moment is that Junctions are immutable,
whilst Sets are mutable. This is perhaps a deficiency in my original
Set.pm design; all of the mutating functions should be in a seperate
role, really (or just not be mutators).
6. Can I declare with named Set (or Junction) and Mapping typed
variables and/or parameters that their members are restricted to
particular types, such as Str, as I can with Arrays and Hashes, so
that Perl itself will catch violations? Eg, can I say as a parameter
Set of Str :$heading? or Set of Mapping(Str) of Any :$body? so
Perl will check that arguments are suchwise correct?
These are variously called Generics (ada I think, Java 1.5+),
Parametric Types, Higher Order Types (Pierce et al), Generic
Algebraic Data Types (Haskell)
In Perl 6 they are parametric roles (as in S12 mentioned above)
7. Can we add some operators to Mapping that are like the Relation
ones, so that implementing a Relation over Mappings is easier (or,
see the end of #8)? Eg, these would be useful: rename(), project(),
extend(), join(). In particular, implementing join() into Mapping
would help save CPU cycles:
Again, a reference to a prototype of the behaviour would be useful.
Sam.
Re: using the newer collection types
At 10:51 AM +1200 5/5/06, Sam Vilain wrote:
Moreover, the Relation type has these
operators that the Set type doesn't have: rename(), project(),
restrict(), extend(), join(), divide(), summarize(), group(),
ungroup(), wrap(), unwrap(), matching(), etc.
Is there a reference for the meaning of these methods?
7. Can we add some operators to Mapping that are like the Relation
ones, so that implementing a Relation over Mappings is easier (or,
see the end of #8)? Eg, these would be useful: rename(), project(),
extend(), join(). In particular, implementing join() into Mapping
would help save CPU cycles:
Again, a reference to a prototype of the behaviour would be useful.
There are many written references to these methods; just type
relational algebra into Google.
That said, some of those search results may not explain things in the
same way, so I specifically prefer the definitions in Date and
Darwen's book Databases, Types, and The Relational Model;
equivalent definitions are probably on the 'net' but I'm not sure
where.
I also defined part of the join() operator in my last email. How
that definition, for Tuples, extends to a Relation is that you pair
every tuple in each relation being joined to every tuple in each of
the others, and apply my earlier definition with each pairing; the
output Relation contains a tuple where the earlier definition
returned a tuple, and no tuple where it returned undef.
Alternately, if you want to wait a week, I will be coding up
documented implementations as soon as possible within Pugs'
ext/Relation/ dir.
But in order for me to do this, I was needing some answers about the
nature of existing types like Set and Mapping and Junction etc, which
I asked in this email.
Regarding your other comments:
I don't think this terminology or these restrictions are particularly
useful.
I do think that a Pair should be a sub-type of a more general Tuple
type, with the 'where' clause being { .items == 2 } or something like that.
I think that the most flexible arrangement is to define;
- a Collection as a Bag of Tuples
- a Relation as a Collection where the tuples have a shape and no
duplicate tuples are allowed (but Relation does not need to be a core type)
Then, Mappings, Sequences, etc, become sub-types of one of the above two
types. For instance, a sequence is a Collection of (Int, Any) where the
first Int is unique across the collection. Similarly a Mapping is a
Collection of (Any, Any) where Unique(0).
You may be on to something here, but I'll withold comments for now.
My main concerns with this whole Relation thing are that I want an
efficient way in Perl 6 to represent what relation-land's concept of
tuples and relations are, as well as an efficient implementations of
relational algebra that are just as easy to use and fast in Perl 6 as
are the language's other collection types such as Sets.
If Perl 6 is to be the choice language of the singularity, it needs
to be easy and fast to do any common type of work with it, and
relational algebra is an extremely common kind of work being done.
-- Darren Duncan
Re: using the newer collection types
Actually, I'll add a few more things to my reply, which should be helpful ...
At 5:11 PM -0700 5/4/06, Darren Duncan wrote:
At 10:51 AM +1200 5/5/06, Sam Vilain wrote:
Moreover, the Relation type has these
operators that the Set type doesn't have: rename(), project(),
restrict(), extend(), join(), divide(), summarize(), group(),
ungroup(), wrap(), unwrap(), matching(), etc.
Is there a reference for the meaning of these methods?
There are many written references to these methods; just type
relational algebra into Google.
I will add that the first hit on such a search, the Wikipedia page on
relational algebra ( http://en.wikipedia.org/wiki/Relational_algebra
), is a perfectly good primer on what relational algebra is and what
its importance is.
The article's introduction says:
Relational algebra, an offshoot of first-order logic, is a
set of relations closed under operators. Operators operate on one or
more relations to yield a relation. Relational algebra is a part of
computer science.
Relation algebra in pure mathematics is an algebraic
structure, relevant to mathematical logic and set theory.
That article also explains many of the most important relational operators.
Note that there is a related set of operators comprising relational
calculus, and you can do everything in one that you can in the other,
though less or more verbosely as the case may be.
At 10:51 AM +1200 5/5/06, Sam Vilain wrote:
I do think that a Pair should be a sub-type of a more general Tuple
type, with the 'where' clause being { .items == 2 } or something like that.
I think that the most flexible arrangement is to define;
- a Collection as a Bag of Tuples
- a Relation as a Collection where the tuples have a shape and no
duplicate tuples are allowed (but Relation does not need to be a core type)
Then, Mappings, Sequences, etc, become sub-types of one of the above two
types. For instance, a sequence is a Collection of (Int, Any) where the
first Int is unique across the collection. Similarly a Mapping is a
Collection of (Any, Any) where Unique(0).
something like
role Tuple { has @.items };
role Collection { has Tuple @.tuples };
subset Pair of Tuple where { .items.items == 2 };
subset Bag of Collection where { ! .tuples.grep:{.items 1 } }
subset Set of Bag where {
all( .tuples.map:{ .items } ) == one( .tuples.map:{ .items } )
}
subset Mapping of Collection where { ! .tuples.grep:{ .items != 2 } }
subset Array of Mapping where { .tuples.grep:{ .items[0].isa(Int) } }
subset Hash of Mapping where { .tuples.grep:{ .items[0].does(Str) } }
While this may not actually change anything, I should point out that
every collection type can also be expressed in terms of a Relation
definition and/or they can all be implemented over a Relation (whose
members are actually always unique). For example:
1. A Set of Any is a Relation with one Any attribute.
2. A Bag of N Any attributes is a Relation of N+1 attributes, where
the extra attribute is an Int (constrained = 1) that counts
occurrances of the distinct other attributes.
3. A Mapping can be a Relation of 2 Any attributes.
4. A Hash is a Relation of 2 attributes, Str (key) and Any (value),
where the key has a unique constraint.
5. A Seq is a Relation of 2 attributes, typed Int (= 0) and Any,
where the first shows their ordinal position and the second is the
actual value; the first has a unique constraint.
6. An Array is the same, assuming it is a sparse; if it is not
sparse, there is an additional constraint that the greatest Int value
is the same / one less than the count of Relation members.
Suffice it to say that I'm sure you would implement a bag using some
other type, whether a relation or a hash or an array, where the
member is stored once with an occurrance count.
-- Darren Duncan
