Re: Perl 6 Summary for 2005-01-31 through 2004-02-8
On Wed, 9 Feb 2005, Larry Wall wrote: roadblocks thrown in their way. That's true not only for LP, but also for FP, MP, XP, AOP, DBC, and hopefully several other varieties ^^ ^^^ ^^ ^^^ 1. 2. Ehmmm... sorry for the ignorance, but... 1. Functional Programming (right?) 2. Aspect Oriented Programming (right?) What about the others? Well, I know about Google (and I'll try ASAP in any case), but I fear those acronyms could be just a little bit too generic, although probably including also 'programming paradigm' as search keys would help. Michele -- Whoa! That is too weird! I asked around among the math faculty here and it turns out that _every one's_ wife is married to a mathematician! - Dave Rusin in sci.math, Re: Genetics and Math-Ability
Re: Perl 6 Summary for 2005-01-31 through 2004-02-8
MD == Michele Dondi [EMAIL PROTECTED] writes: MD On Wed, 9 Feb 2005, Larry Wall wrote: roadblocks thrown in their way. That's true not only for LP, but also for FP, MP, XP, AOP, DBC, and hopefully several other varieties MD ^^ ^^^ MD ^^ ^^^ MD 1. 2. MD Ehmmm... sorry for the ignorance, but... MD 1. Functional Programming (right?) MD 2. Aspect Oriented Programming (right?) i think so but i can't read larry's mind (nor would i want to! :) XP = extreme programming DBC = design by contract (or even designed by conway :) MP = ?? uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Junctive puzzles.
Matt Fowles wrote:
This is Just Wrong, IMO. How confusing is it going to be to find that
calling is_prime($x) modifies the value of $x despite it being a very
simple test operation which appears to have no side effects?
As far as I can see it, in the example, it's perfectly logical for
is_prime($x), is_even($x) and $x 2 to all be true, because an any()
junction was used. If an all() junction was used it would be quite a
different matter of course, but I would see is_prime() called on an
any() junction as returning true the moment it finds a value inside that
junction which is prime. It doesn't need to change $x at all.
In a way, you're sort of asking 'has $x got something that has the
characteristics of a prime number?' and of course, $x has - several of
them, in fact (but the count is not important).
Soemtimes, although frequently I will check for preconditions at the
begining of a function. After I finished checking for them, I expect
to be able to do stuff assuming them without anyworry of exceptions or
anything else. In these cases I am using conditionals to filter
input, which I imagine is a fairly common case...
Yes, it is fairly common, but I don't think it's common enough to attach
unexpected side-effects to innocent-seeming functions. If I want to
modify a junction to contain only values which satisfy a given
precondition, I'll be wanting to use something which states that explicitly.
Which reminds me that I'm not very aware of anything which can decompose
a junction once it's been created, which would be fairly necessary for
doing that sort of thing. If you can turn junctions into lists then
precondition filtering isn't bad at all. Something like
my $filtered = any($junction.list().grep({ satisfies_precondition }));
Of course, I just invented that out of nothing so I may be way off base.
I haven't found anything in any Apocalypse or Synopsis which says if you
can do things like this, but if Perl itself can pick junctions apart, we
should be able to as well.
My approach to this comes somewhat from my basis in liking Haskell a lot
and thus wanting to keep unusual side-effects to a minimum. However, if
junctions collapse and modify themselves as was in your example, what
happens when you don't want to have them collapse? Do you have to
explicitly make copies?
Re: Perl 6 Summary for 2005-01-31 through 2004-02-8
John Macdonald wrote: The basic problem is that a junction does not work well with boolean operations, because the answer is usually sometimes yes and sometimes no and until you resolve which of those is the one you want, you have to proceed with both conditions. Well, just patch the boolean operators to return one of (yes, no, sometimes) instead of plain (true, false) :) Anyway, what are the usual semantics with junctions boolean operators in some other languages? (This is so new concept to me, that I don't know of any language to compare against.) -- Markus Laire Jam. 1:5-6
Re: Perl 6 Summary for 2005-01-31 through 2004-02-8
Uri Guttman wrote: [...] i think so but i can't read larry's mind (nor would i want to! :) XP = extreme programming DBC = design by contract (or even designed by conway :) MP = ?? Modular Programming David
Re: = vs == [was: Perl 6 Summary for 2005-01-31 through 2004-02-8]
Aaron Sherman wrote: So hold on to your socks... what about: @x @y; This reminds me of AWK's string concatenation behaviour: print this $1 that $2 This was nice feature at the time, but caused problems down the track when they wanted to add functions to the language in a subsequent revision. See section 8.1 of The AWK Programming Language for more details. For that reason alone (future-proofing the grammar), I would be leery of going down this route. David
Re: [rbw3@cse.nau.edu: Re: Junctive puzzles.]
[EMAIL PROTECTED] wrote: Yes... but perhaps instead of the above transform we should just make sure that is transitive in the first place... so that no matter what if ab and bc then ac. OTOH... perhaps we are working with partially ordered sets (rather than completely ordered sets)? In that case maybe the above suggestion is useful after all. Partial ordering relations are also transitive by definition. Of course, you can overload '' to be something other than ordering relation, but I'd invoke PEBKAC on that. :) Miro
Re: Junctive puzzles.
[EMAIL PROTECTED] wrote:
What if junctions collapsed into junctions of the valid options under
some circumstances, so
my $x = any(1,2,3,4,5,6,7);
if(is_prime($x) # $x = any(2,3,5,7)
and is_even($x) # $x = any(2)
and $x 2) # $x = any()
This is Just Wrong, IMO. How confusing is it going to be to find that
calling is_prime($x) modifies the value of $x despite it being a very
simple test operation which appears to have no side effects?
As far as I can see it, in the example, it's perfectly logical for
is_prime($x), is_even($x) and $x 2 to all be true, because an any()
junction was used. If an all() junction was used it would be quite a
different matter of course, but I would see is_prime() called on an
any() junction as returning true the moment it finds a value inside
that junction which is prime. It doesn't need to change $x at all.
In a way, you're sort of asking 'has $x got something that has the
characteristics of a prime number?' and of course, $x has - several of
them, in fact (but the count is not important).
Well, yes, unexpected side-effects are not so great, however, in this
case they're sequestered behind junctions. In fact, the other post
suggested using implicit backtracking for this (something that can have
a real problem with *expected* side-effects). If you just think of
junctions as 'Just Works', side effects are implementation detail.
To address your idea, problem is, you generally don't know whether
you've been passed a junction (short of very specific type query), and
writing code without being able to rely on the fact that (is_prime($x)
!!is_prime($x)) == false is Just Plain Evil. For example, something
as simple as
if (is_prime($x)) { ... }
else { ... }
may be buggy if $x is a junction. To make it work correctly, you will
want to write
if (is_prime($x)) { ... }
if (!is_prime($x)) { ... }
Evil, no? :)
Miro
Re: Perl 6 Summary for 2005-01-31 through 2004-02-8
[EMAIL PROTECTED] wrote: i think so but i can't read larry's mind (nor would i want to! :) XP = extreme programming DBC = design by contract (or even designed by conway :) MP = ?? Modular Programming David I think it's Metaprogramming. :) Miro
Re: Perl 6 Summary for 2005-01-31 through 2004-02-8
On Thu, 10 Feb 2005, Miroslav Silovic wrote: Modular Programming David I think it's Metaprogramming. :) The only thing that sprung to my mind was MetaPost... Michele -- No one can ever predict all of the possible error conditions, of course; as soon as we write idiot-proof code, along comes a better idiot. But it's still worth making the attempt. - Sherm Pendley in clpmisc (edited)
Fwd: Junctive puzzles.
Sorry if you get this twice (and slightly different), but I posted it off list by mistake. -- Forwarded message -- From: Thomas Yandell [EMAIL PROTECTED] Date: Thu, 10 Feb 2005 10:22:44 + Subject: Re: Junctive puzzles. To: Matthew Walton [EMAIL PROTECTED] What if junctions collapsed into junctions of the valid options under some circumstances, so my $x = any(1,2,3,4,5,6,7); if(is_prime($x) # $x = any(2,3,5,7) and is_even($x) # $x = any(2) and $x 2) # $x = any() This is Just Wrong, IMO. How confusing is it going to be to find that calling is_prime($x) modifies the value of $x despite it being a very simple test operation which appears to have no side effects? As far as I can see it, in the example, it's perfectly logical for is_prime($x), is_even($x) and $x 2 to all be true, because an any() junction was used. If an all() junction was used it would be quite a different matter of course, but I would see is_prime() called on an any() junction as returning true the moment it finds a value inside that junction which is prime. It doesn't need to change $x at all. In a way, you're sort of asking 'has $x got something that has the characteristics of a prime number?' and of course, $x has - several of them, in fact (but the count is not important). Is it perhaps the comments that are wrong, rather than the code? my $x = any(1,2,3,4,5,6,7); if(is_prime($x) # expression evaluates to any(2,3,5,7) and is_even($x) # expresion evaluates to any(2, 4, 6) # at this point the boolean expression evaluates to any(2) - is this the same as 2? and $x 2) # expression evaluates to any(3,4,5,6,7) # so result is false # $x is still any(1,2,3,4,5,6,7) Is this right? Is the following comment correct? my $x = any(2,3,4,5) and any(4,5,6,7); # $x now contains any(4,5) Tom
Re: Fwd: Junctive puzzles.
On Thu, Feb 10, 2005 at 10:42:34AM +, Thomas Yandell wrote: Is the following comment correct? my $x = any(2,3,4,5) and any(4,5,6,7); # $x now contains any(4,5) Short answer: I don't think so. Long answer: I tend to get very lost when dealing with junctions, so I can be completely wrong. However, watch the precedence and meanings of the operators here -- I would think that my $x = any(2,3,4,5) and any(4,5,6,7); results in $x containing any(2,3,4,5), just as my $y = 2 and 3; results in $y containing 2 (since Cand has lower precedence than C=). Even if you fixed the =/and precedence with parens, to read my $x = (any(2,3,4,5) and any(4,5,6,7)); then I think the result is still that $x contains any(4,5,6,7). It gets interpreted as (from S09): $x = any( 2 and 4, # 4 2 and 5, # 5 2 and 6, # 6 2 and 7, # 7 3 and 4, # 4 3 and 5, # 5 # etc... 5 and 6, # 6 5 and 7, # 7 ); which ultimately boils down to any(4,5,6,7). Pm
Re: S04
Given that Perl 6 won't support an actual do-while loop a la C++ (and
yes, I know that Perl5 didn't either), how would you accomplish that?
That is, I'd like to have a loop that runs once, then checks its
condition to see if it should repeat and continues to repeat as long
as the condition is true.
I don't think this works, but here's what I'm look for:
{
$foo = readline;
...do stuff with $foo...
} while ( $foo );
--Dks
Re: S04
David Storrs writes:
Given that Perl 6 won't support an actual do-while loop a la C++ (and
yes, I know that Perl5 didn't either), how would you accomplish that?
That is, I'd like to have a loop that runs once, then checks its
condition to see if it should repeat and continues to repeat as long
as the condition is true.
I don't think this works, but here's what I'm look for:
{
$foo = readline;
...do stuff with $foo...
} while ( $foo );
There's been some discussion about bringing a syntax back for that
recently, but I haven't really been paying attention. Anyway, this is
pretty clear:
loop {
$foo = readline;
do { stuff :with($foo) };
last unless $foo;
}
Luke
Re: S04
On Thu, Feb 10, 2005 at 07:39:54AM -0800, David Storrs wrote:
: Given that Perl 6 won't support an actual do-while loop a la C++ (and
: yes, I know that Perl5 didn't either), how would you accomplish that?
: That is, I'd like to have a loop that runs once, then checks its
: condition to see if it should repeat and continues to repeat as long
: as the condition is true.
:
: I don't think this works, but here's what I'm look for:
:
: {
: $foo = readline;
: ...do stuff with $foo...
: } while ( $foo );
That's spelled
loop {
$foo = readline;
...do stuff with $foo...
} while ( $foo );
these days.
Larry
Re: Fwd: Junctive puzzles.
Patrick R. Michaud wrote:
Even if you fixed the =/and precedence with parens, to read
my $x = (any(2,3,4,5) and any(4,5,6,7));
then I think the result is still that $x contains any(4,5,6,7).
Funny. I thought $x would contain 'true' here, since Cand was a
boolean operator. But I could be very wrong.
The overall impression I'm getting here is that we need some syntax for
saying:
$x = any(1..1000) such_that is_prime($x);
where such_that acts as a form of junctive grep. so the above might
mean the same as:
$x = any(1..1000 == grep(is_prime($_)));
We then can say that any junction stored in a var stays constant, until
explicitly reassigned. Just like every other kind of thing we store.
Philosophy Question:
What's the difference between a junction and an array containing all the
possible values of the junction? Other than how they are used, of
course. So, on that train of thought, would this make sense:
if $x == @x.any {...}
if $x == @x.none {...}
If this is the case, then this entire discussion collapses into how to
best convert arrays into junctions and junctions into arrays. Perl's
existing abilities to edit arrays should be more than sufficient for
editing junctions.
-- Rod Adams
Re: Perl 6 Summary for 2005-01-31 through 2004-02-8
On Thu, Feb 10, 2005 at 12:32:21PM +0100, Miroslav Silovic wrote: : [EMAIL PROTECTED] wrote: : : i think so but i can't read larry's mind (nor would i want to! :) : : XP = extreme programming : DBC = design by contract (or even designed by conway :) : MP = ?? : : : Modular Programming : : David : : I think it's Metaprogramming. :) You win. Though it did occur to me at the time I wrote it that it could also stand for multiprocessing. Larry
Re: Test names/comments/whatever?
On Sun, 2005-02-06 at 20:16 -0600, Andy Lester wrote: I should NOT have applied that? It's already on my trunk. Half of it was good. The IPC::Open3 code is probably problematic, so it should revert. I really like the diagnostic-parsing code, but it's worth discussing whether to enable this by default. Doing so does change the interface a little bit, but the docs make no promises about the change. I'm happy to write a code and test patch with just that, if you like. -- c
Re: Native support for GNU R
At 01:40 PM 2/9/2005, Aaron Sherman wrote: On Wed, 2005-02-09 at 12:08, [EMAIL PROTECTED] wrote: I read that you can provide support (in Perl 6) for most languages that parsers have been written for. As it appears to me, however, the languages that you are mainly interested in are substitutes (competitors) to Perl. You're mistaken about a core item here. First off, Perl 6 may have This is the reason we should have changed the list name to parrot-internals years ago, or spawned a new one. Nowadays I'm not as interested in the Perl6 language as I am the potential to run a lot of languages on a common VM. -Melvin
Re: Test names/comments/whatever?
On Sun, Feb 06, 2005 at 01:46:14PM -0800, chromatic wrote: I don't know that that's a problem if you redirect STDERR to the same place as STDOUT. Is there any OS where the order of printing is that badly nondeterministic? If so, can I wave my hands at its users and suggest either upgrading or lobbying to add sequence numbers to output? Trouble is STDOUT is parsed while STDERR is not so T::H has to be able to disambiguate them while still displaying them in the correct ordering and not run afoul of any buffering issues. If you've pull that off and not hard-wired a dependency on IPC::Open3, which won't work without fork(), then ok. And no, users should not have to upgrade their OS nor add sequence numbers to output.
Re: Test names/comments/whatever?
On Thu, 2005-02-10 at 16:46 -0500, Michael G Schwern wrote: Trouble is STDOUT is parsed while STDERR is not so T::H has to be able to disambiguate them while still displaying them in the correct ordering and not run afoul of any buffering issues. I wave the Nope, the UNbiquitous Test::Harness::Straps flag in hopes that it staves off the backwards compatibility police. And no, users should not have to upgrade their OS nor add sequence numbers to output. Yeah, but they *should* upgrade to operating systems that implement *some* form of usable process control. I'm playing my idealist card here and checking that we're still only betting peanuts and marshmallows. -- c
Re: S04
On Thu, 2005-02-10 at 11:59, Luke Palmer wrote:
There's been some discussion about bringing a syntax back for that
recently, but I haven't really been paying attention. Anyway, this is
pretty clear:
loop {
$foo = readline;
do { stuff :with($foo) };
last unless $foo;
}
Well, yes it's clear, but then you run into the problem where your code
looks like:
while stuff() {
more_stuff();
}
loop {
other_more_stuff();
last unless other_stuff();
}
and then you want to add something like:
next if things();
to both... you have to do it in two ways. The Perl 6ish way of dealing
with this is:
while stuff() {
next if things();
more_stuff();
}
loop {
next if other_things();
other_more_stuff();
NEXT { last unless other_stuff(); }
}
I think Larry's contention has been that loop is all you really need,
and everything else is a macro. If you really want dowhile, then it's
something like (making up macro example on the fly, and probably wrong
here...):
macro infix:dowhile (Code $block, Bool $cond) {
loop { $block.(); NEXT { last unless $cond.() } }
}
{
next if other_things();
other_more_stuff();
} dowhile other_stuff();
Of course, that assumes that an expanded macro will, by default, handle
the case when you pass it code that invokes a loop control, expecting to
control the loop inside the macro first.
--
781-324-3772
[EMAIL PROTECTED]
http://www.ajs.com/~ajs
Re: Test names/comments/whatever?
On Thu, Feb 10, 2005 at 01:56:50PM -0800, chromatic wrote: On Thu, 2005-02-10 at 16:46 -0500, Michael G Schwern wrote: Trouble is STDOUT is parsed while STDERR is not so T::H has to be able to disambiguate them while still displaying them in the correct ordering and not run afoul of any buffering issues. I wave the Nope, the UNbiquitous Test::Harness::Straps flag in hopes that it staves off the backwards compatibility police. Err, I don't get it. And no, users should not have to upgrade their OS nor add sequence numbers to output. Yeah, but they *should* upgrade to operating systems that implement *some* form of usable process control. I'm playing my idealist card here and checking that we're still only betting peanuts and marshmallows. I reference RFC 1925, section 2.1 It Has To Work. If its a platform p5p considers supported, Test::Harness will work. Perhaps not all the fancy features, but it will parse and display test results. So as long as TH's basic functionality continues to work everywhere, that's fine.
Re: Test names/comments/whatever?
On Thu, 2005-02-10 at 17:30 -0500, Michael G Schwern wrote: Err, I don't get it. It's a patch to Test::Harness::Straps, the documentation of which disclaims backwards compatibility. I'd like it to work on Windows so as to avoid people complaining if it doesn't, but I'm just saying that 1) I don't feel any particular guilt about suggesting a change to the interface and 2) I suggested a change to the interface, with code and tests and stuff. Test::Harness itself? Read it. Didn't touch it. All functionality continues to work everywhere. -- c
Re: Test names/comments/whatever?
--- chromatic [EMAIL PROTECTED] wrote: It's a patch to Test::Harness::Straps, the documentation of which disclaims backwards compatibility. I'd like it to work on Windows so as to avoid people complaining if it doesn't, but I'm just saying that 1) I don't feel any particular guilt about suggesting a change to the interface and 2) I suggested a change to the interface, with code and tests and stuff. I have no problem with this. Is anyone even using THS? If anything, I suspect there are a tiny handful of people who have played with it, but haven't really used it since it's not as useful as it could be. Once it's made useful, it's a whole 'nuther ball game :) Cheers, Ovid = If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Fwd: Junctive puzzles.
Patrick Michaud wrote: On Thu, Feb 10, 2005 at 10:42:34AM +, Thomas Yandell wrote: Is the following comment correct? my $x = any(2,3,4,5) and any(4,5,6,7); # $x now contains any(4,5) Short answer: I don't think so. Long answer: decloak Patrick is right on the money here...as usual. (Don't you just *love* that in the guy who's job it is to actually make this stuff work! ;-) Damian recloak
Re: Fwd: Junctive puzzles.
Rod Adams wrote:
The overall impression I'm getting here is that we need some syntax for
saying:
$x = any(1..1000) such_that is_prime($x);
In standard Perl 6 that'd be:
$x = any(grep {is_prime $^x} 1..1000);
or, if you prefer your constraints postfixed:
$x = any( (1..1000).grep({is_prime $^x}) );
If you really wanted a such that operator you could certainly create one
yourself:
multi sub *infix:such_that (Junction $j, Code $constraint) {
return $j.type.new(grep $constraint, $j.values);
}
$x = any(1..1000) such_that {is_prime $^x};
Though, personally, I think a C.where method with an adverbial block might
be neater:
multi method Junction::where (Junction $j: *constraint) {
return $j.type.new(grep constraint, $j.values);
}
$x = any(1..1000).where:{is_prime $^x};
# or...
$x = where any(1..1000) {is_prime $^x};
We then can say that any junction stored in a var stays constant, until
explicitly reassigned. Just like every other kind of thing we store.
Yep. That's exactly what we'll be saying!
Philosophy Question:
What's the difference between a junction and an array containing all the
possible values of the junction?
Junctions have an associated boolean predicate that's preserved across
operations on the junction. Junctions also implicitly distribute across
operations, and rejunctify the results.
So, on that train of thought, would this make sense:
if $x == @x.any {...}
if $x == @x.none {...}
Probably. It's entirely possible that, in addition to being built-in list
operators, Call, Cany, Cone, and Cnone are also multimethods on
Scalar, Array, and List.
Damian
Re: Test names/comments/whatever?
Ovid wrote:
Is anyone even using THS?
/me raises his hand
If anything, I
suspect there are a tiny handful of people who have played with it, but
haven't really used it since it's not as useful as it could be.
I got Apache-Test to run .php scripts in under 10 lines by subclassing
straps. it could have been less if there weren't that silly call to
$Strap-{callback} in Test::Harness that I needed to regenerate in my
subclass to get verbose output working properly (hint hint).
--Geoff
Re: Test names/comments/whatever?
On Thu, Feb 10, 2005 at 02:49:55PM -0800, chromatic wrote: It's a patch to Test::Harness::Straps, the documentation of which disclaims backwards compatibility. I'd like it to work on Windows so as to avoid people complaining if it doesn't, but I'm just saying that 1) I don't feel any particular guilt about suggesting a change to the interface and 2) I suggested a change to the interface, with code and tests and stuff. Test::Harness itself? Read it. Didn't touch it. All functionality continues to work everywhere. THS is the internal parser for TH so changing THS can effect TH if you're not careful. OTOH if you're just adding things then it should be go.
Re: Test names/comments/whatever?
On Thu, Feb 10, 2005 at 03:02:03PM -0800, Ovid wrote: I have no problem with this. Is anyone even using THS? Yes. Everyone who uses Test::Harness.
Sets vs Junctions (was Junctive puzzles.)
Damian Conway wrote:
Rod Adams wrote:
The overall impression I'm getting here is that we need some syntax
for saying:
$x = any(1..1000) such_that is_prime($x);
In standard Perl 6 that'd be:
$x = any(grep {is_prime $^x} 1..1000);
or, if you prefer your constraints postfixed:
$x = any( (1..1000).grep({is_prime $^x}) );
Both of those seem way too brutal to me.
We then can say that any junction stored in a var stays constant,
until explicitly reassigned. Just like every other kind of thing we
store.
Yep. That's exactly what we'll be saying!
Good.
Philosophy Question:
What's the difference between a junction and an array containing all
the possible values of the junction?
Junctions have an associated boolean predicate that's preserved across
operations on the junction. Junctions also implicitly distribute
across operations, and rejunctify the results.
My brain is having trouble fully grasping that. Let me attempt a paraphrase:
Junctions exist to be tested for something.
When a test is performed, the junction is evaluated in terms of that
test. A result junction is created, which contains only the elements
of the original junction which will pass that given test. If the result
junction is empty, the test fails.
Looking at the S09 C substr(camel, 0|1, 23) example explains a lot.
So, on that train of thought, would this make sense:
if $x == @x.any {...}
if $x == @x.none {...}
Probably. It's entirely possible that, in addition to being built-in
list operators, Call, Cany, Cone, and Cnone are also
multimethods on Scalar, Array, and List.
okay.
--
Now that I've gotten some feedback from my original message (on list and
off), and have had some time to think about it some more, I've come to a
some conclusions:
Junctions are Sets. (if not, they would make more sense if they were.)
Sets are not Scalars, and should not be treated as such.
If we want Sets in Perl, we should have proper Sets.
Let's first define what a Set is:
- A Set is an unordered collection of elements in which duplicates are
ignored.
- There are really only two questions to ask of a Set: Is X a member of
you?, and What are all your member?
- Typically, all members of a set are of the same data type. (I'm in no
way committed to this being part of the proposal, but it makes sense if
it is)
Sets and Lists are two different things. Lists care about order and
allow duplicates. Iterating a Set produces a List, and one can convert a
List into a Set fairly easily.
Sets and Hashes are quite similar, but in other ways different. The keys
of a Hash are a Set of type String. In addition to the String
constraint, each element of the set has an additional scalar value
associated with it. Hashes can be multidimensioned. I have no idea what
a multidimensional Set is. It may be possible to represent Sets as
lightweight Hashes if the Strings for keys constraint is lifted or
altered, but I see several advantages to Sets being distinct, for
reasons I'll outline below.
So I propose making Sets a first class data type right up there with
Arrays, Hashes, and Scalars. For the purposes of this posting, I will
assume that they get a sigil of #. (to get a comment, you need
whitespace after the #). I harbor no expectations that it will stay as
this, but I needed something, and didn't feel like remapping my keyboard
at the moment. Interestingly, on US keyboards, @#$% is shift-2345.
With that, we can now make existing operators do nifty things:
#a = #b + #c;# Union (Junctive $b or $c)
#a = #b - #c;# Difference( $b and not $c)
#a = #b * #c;# Intersection ( $b and $c)
#a == #b;# Do sets contain the same values?
#a #b;# Is #a a subset of #b? likewise , =, =
$a ~~ #b;# Membership
#a += $b;# Add value to set
#a = @b; # Create a set from an array/list
#a = (1,2,3);
$ref = #{1..10}; # an anonymous Set reference
@a = #b; # One way to iterate the members.
It's probably best to define binary | and as Set Creation with
Union/Intersection, so we have:
#a = 1|3|7;
#a + @b == #a | @b;
We also add some methods here and there:
@a = #b.values;
#b = @a.as_set;
$a = #b.elems;
my str #a = %b.keys;
I also envision virtual sets, which cannot be iterated, but can be
tested for membership against. These would be defined by a closure or
coderef.
#natural_numbers = { $^a == int($^a) $^a 0 };
#primes = is_prime;
Set operations with virtual sets should be able to define new closures
based on the former ones:
#a = #b + #c; == #a = {$^a ~~ #b || $^a ~~ #c};
#a = #b * #c; == #a = {$^a ~~ #b $^a ~~ #c};
#a = #b - #c; == #a = {$^a ~~ #b $^a !~ #c};
#a = #b + 3; == #a = {$^a == 3 || $^a ~~ #b};
So now, some sample code:
$x = any( (1..1000).grep({is_prime $^x}) ); # Damian's example from above
vs
#x = (1..1000) * #primes;
if $x == 1|2|3 {...}
vs
if $x ~~ 1|2|3 {...}
or
if $x ~~ #{1,2,3} {...}
$x = (any(2,3,4,5) and any(4,5,6,7));
# where $x ==
