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
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
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: [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 a 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)
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 C 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 C 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: 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: 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: 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
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: (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, C, C, C, and C are also multimethods on
Scalar, Array, and List.
Damian
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, 2&3) >> 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, C, C, C, and C 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,
