date:20030401

 Luke Palmer [EMAIL PROTECTED] writes:
 
  However, my problem remains.  What does the poor generic programmer do
  when he needs generic equality!?
 
 unfortunetly, no such thing exists.
 
 see:
 
 http://xrl.us/fdz
 
 and 
 
 http://www.nhplace.com/kent/PS/EQUAL.html
 
 although the specifics are common lisp related the underlying ideas
 are equally valid to perl.

Thanks! I was pondering what generic equality meant, thinking I know
something I don't.

However, I'm taking from C++ (my favorite language for generic
programming, but not much else) in which std::map requires the keyed
type to define  and == (or provide them in the template arguments).
And indeed, a binary-tree map can't work without those operations.

But C++ has it easy, because every variable must have exactly one
type, at compile time.  And all types in the map are the same.  It's a
tough call which == you would call when you have one for (Str,Str) and
one for (Int,Int) and are given (Str,Int).  In fact, an ambiguous call
that ought to be an error.

So generic equality is^H^Hmust be overloaded in order to function.
It's the one that the user wants his/her classes to obey when put in
generic containers and algorithms.  And it may differ from application
to application.  (It may differ from container to container, and
that's why there's parameterized types.  But we can't expect the lazy
Perl programmer to specify explicitly each time a container is used.)

So, I guess what I'm saying is that this generic equality isn't the
super-operator that always knows what you mean, it's the default
operator that does whatever you think the best thing is.  And you tell
it what the best thing is.  That's the idea.

And what happens if it's given two incompatible types?  It would call
the multimethod that matched them, or it would just return false.  No,
a Cat isn't a String, no matter what's inside them.

Maybe smart-match Iis what we want, and maybe it shouldn't be quite
so dwimmy.  For instance:

given 13 {
when (12,13,14) {...}
}

Why would you say that when you could say:

given 13 {
when any(12,13,14) {...}
}

Say What You Mean.  The former just wouldn't match, because 13 isn't
equal to the list (12,13,14).  

This comes back to many kinds of equality.  Who says that two arrays
should match if there is some intersection of their values?  Somebody
might want them to match if *all* of the values of the second are
contained in the first.  Again:

given any(1,2,3,5,6) {
when all(2,3) ~~ $_ {...}
}

(The ~~ $_ is necessary because of junction nesting, I think)

or

given (1,2,3,5,6) {
when all(2,3) ~~ any([EMAIL PROTECTED]) {...}
}

Say What You Mean again.

Plus, then you could do things like indexing into containers with
regexen, and getting out objects that match.  Junctions make the
complex cases that ~~ addresses rather trivial.  They make them read
better, too.

Luke

Re: == vs. eq

 --- Michael Lazzaro [EMAIL PROTECTED] wrote:
  Note if we are truly strict about C== always meaning compare 
  numerically, I imagine that the line:
  
  [EMAIL PROTECTED] == [EMAIL PROTECTED];
  
  would in fact be identical to _this_ line:
  
  @a.length == @b.length;# or whatever it's called
 
 Whoa!! I read
 
  [EMAIL PROTECTED] == [EMAIL PROTECTED];
 
 as does the [EMAIL PROTECTED] compare numerically as equal to the
 [EMAIL PROTECTED], which is definitely NOT the same as 
 
 @a.length == @b.length;# or whatever it's called
 
 which I read as does @a have the same number of elements as @b?

As much as I don't want to refute my own operator, I agree with you
here.  I don't know what the official (this week) policy is, but I
think it's a bad idea for references to auto-dereference.  The other
way around is fine, though (arrays auto-referencizing).

C[EMAIL PROTECTED] == [EMAIL PROTECTED] seems fine, provided references stay as 
references.

Hey, guess what Apocalypse 8 is about!  :)

Luke

Re: == vs. eq

2003-04-01 Thread Miko O'Sullivan

Luke Palmer wrote:
 However, my problem remains.  What does the poor generic programmer do
 when he needs generic equality!?

Well, I'm a pretty generic programmer.  I spend lots of time glued to the
monitor, I have poor social skills, sometimes my boss has to tell me to
dress neater...

Anyway, maybe I'm just repeating what was already said in bigger words,
but let me propose a concept:

=:= is a generic comparison operator that simply calls the
value_for_comparison method of the objects on left and right.  If they
both return the same string, then the expression returns true, else it
returns false. If they don't have that method, that's a fatal error.
Their value_for_comparison() methods must have been defined in the same
class, otherwise you're comparing apples and oranges.  (Yes, I'm sure we
can think of a better name than value_for_comparison.)

Of course, you can also cast the objects to change what type of comparison
you want.  So, for example, C$a =:= $b compares the outputs of the
value_for_comparison methods, but C~$a =:= ~$b compares the numification
of the objects, or, to get into the guts of the matter, the objects are
evaluated in numeric context, which causes them to run their overflow
methods for numification, which returns number objects, which then call
their value_for_comparison methods, which return the numbers as
represented by some string which is formatted according to some
unambiguous rule (we already have those unabiguou rules).

==, then, becomes just an alias for C~$a =:= ~$b and eq becomes an alias
for C+$a =:= +$b.  To find out if the two variables reference the same
object, you simply cast them as the fundamental class from which all
objects extend.  Um, I don't remember the cast operator to do that (is
there one?) but say it's simply ob, you just say Cob $a =:= $ob $b.

-Miko


Miko O'Sullivan
Programmer Analyst
Rescue Mission of Roanoke

Re: == vs. eq

Luke Palmer wrote:
As much as I don't want to refute my own operator, I agree with you
here.  I don't know what the official (this week) policy is, but I
think it's a bad idea for references to auto-dereference.  The other
way around is fine, though (arrays auto-referencizing).
I'm pretty darn sure they autodereference... we last talked about this 
when we were trying to determine how an arrayref would behave when 
interpolated into a string literal (answer: just like the original 
array would).

Here's the relevant message:

On Fri, Dec 06, 2002, Larry Wall wrote:
On Fri, Dec 06, 2002, Dan Sugalski wrote:
: If an aggregate and a reference to an aggregate are going to behave
: the same, which is what Larry's indicated in the past, then
: stringifying a reference should be the same as stringifying its
: referent.
This is a bit of an oversimplification.  $foo and @foo do not always
behave the same, even if $foo and @foo refer to the same array object.
In particular, $foo doesn't behave like @foo in a list context.
snip
But it's probably fair to say that $foo and @foo always behave
identically in a scalar context.
So I *really* don't think comparing the equality of references will be 
a good idea, in P6.  :-)

John Williams wrote:
You're right, but personally, I have come to trust eq more that == when
comparing things-which-might-not-be-numbers, such as references.
 [EMAIL PROTECTED] eq [EMAIL PROTECTED];# true, for the reason I think
# (the string-representation of the refs are equal)
I'm pretty sure that breaks too, for the same reason.  It puts both 
sides in string context, which causes both sides to return the string 
representation of the underlying array, _not_ the string representation 
of the references themselves.

MikeL

Re: == vs. eq

On Tue, 1 Apr 2003, Miko O'Sullivan wrote:

 =:= is a generic comparison operator that simply calls the
 value_for_comparison method of the objects on left and right.  If they
 both return the same string, then the expression returns true, else it
   ^^
 returns false. If they don't have that method, that's a fatal error.
 Their value_for_comparison() methods must have been defined in the same
 class, otherwise you're comparing apples and oranges.  (Yes, I'm sure we
 can think of a better name than value_for_comparison.)

I propose the name str for the value_for_comparison method, and eq for
the generic comparison operator.

That's how my objects will work, anyway.

~ John Williams

Re: == vs. eq

One thing we should clear up is that we already *have* a generic 
comparator, C~~, depending on what you mean by generic.  It can be 
made to compare things however you like, according to whatever standard 
of similarness you decide you want to enforce, and can even compare 
objects of disparate types (if you tell it how.)

The way I personally have been envisioning this working is:

   $a == $b;   # compares numerifications of $a and $b
   $a eq $b;   # compares stringifications of $a and $b
   $a ~~ $b;   # tests equality of $a and $b
   $a =:= $b;  # tests identity of $a and $b
Of these, I would expect that ==, eq, and =:= would almost never be 
overloaded, because they have very specific meanings.[*]

You _could_ choose to override those == and eq for a particular custom 
class, and use those for comparing equality of objects.  But since some 
people will tend to want to override ==, and some will want to override 
eq, it's not clear that the Perl6 community will converge on using only 
one or the other, which might make things quite confusing if you're 
using a library that has standardized on the opposite convention from 
your own.

~~, on the other hand, is meant to be overloaded to a 
possibly-excruciating extent, and I've been assuming that it will be 
the thing that classes most often overload when they want to test 
equality of two arbitrary objects, without resorting to serializing 
them via num/str.  (Using num/str comparisions to test for object 
equality obviously only works if num/stringifying _completely_ 
serializes the object -- which very often is _not_ what you want the 
num/stringification of an object to do, by default.)

The proposed =:=, however, merely tests that two objects are identical 
-- that is, _that they are bound to the same underlying thing_.  It's 
possible for two objects to be equal, ~~wise, without actually being 
identical, identitywise.  I don't see ever wanting to overload =:=, and 
it's unclear if it should even be allowed.

Note also that == and eq comparisions are naturally accompanied by 
greater-than, less-than variants.  But ~~ and =:= don't really have 
those variants, because they wouldn't make much sense.

Having said all that, it should be noted that I'm completely making 
this stuff up.

MikeL

[*] By 'overloading', I mean multimethod variants.  The comparision 
operators are almost certainly accomplished via multimethods, $a and $b 
being the two invocants.

Short-circuiting user-defined operators

2003-04-01 Thread Joe Gottman

   Is there any way to write a user-defined operator so that it
short-circuits, like  and || ?  This might be function trait, for
instance,

  sub infix:!! ($lhs, $rhs) is short_circuit {...}

Alternatively, there might be a new parameter type that indicates that the
parameter is not evaluated immediately:

sub infix:!! ($lsh, $rhs is deferred) {...}

   In this case, it might be possible to make ordinary functions
short-circuit also

sub conditional(bool $condition, $trueCase is deferred, $falseCase is
deferred)
{
return ($condition) ?? $trueCase :: $falseCase;
}

   I have no idea how difficult it would be to implement either of these
concepts.   Also, if a parameter is deferred, would we need a new keyword to
say when to actually evaluate it?

Joe Gottman

Re: Funding the design team

2003-04-01 Thread Damian Conway

Thanks to everybody for your patience and support.

Here's where things currently stand wrt TPF and funding for Perl 6 related 
activities:

* TPF is now active again. Special thanks to Nat Torkington for being
  so responsive when I conveyed the list's concerns to him.
* An on-line survey of the Perl community will be made available in
  the very near future. It will be an opportunity for the whole
  community -- including those of us primarily concerned with
  Perl 6 -- to offer guidance to TPF as regards funding priorities.
* A number of new grants will be announced soon. These will probably
  include one or more grants targeted at Perl 6 design and/or
  implementation.
* TPF has been keeping a low profile over the last few months but has
  not been idle. Since last fall, they continued to fund Larry through
  the end of the year, helped with YAPC::Europe, are in the process of
  getting the next YAPC::America running, gave a small grant to Dan,
  and are currently looking at funding some Perl Monks site upgrades.
* The issue of accepting donations targeted to a particular area
  (e.g. Perl 6) has been raised and is being discussed.
Once again, as soon as that survey is available, I will inform the mailing list.

Damian

Re: Short-circuiting user-defined operators

Dave Whipp writes:
 Another, very different, situation where laziness is good is to abstract 
 fork/join situations:
 
 
my $a is lazy_thread := expensive_fn1(...);
my $b is lazy_thread := expensive_fn2(...);
 
print $a + $b;
 
 In this scenario, each expensive evaluation would be launched as a 
 separate thread. When the resulting value is later used, then the thread 
 would be joined, blocking if the thread is not complete.

That is gorgeous.  Clazy_thread isn't a good name, but it's a
marvelous concept.  Thanks.

Luke

Re: Conditional Creturns?

2003-04-01 Thread Paul

 I'm looking for a Perl6 way to say that oft-repeated, oft-chained 
 two-line snippet up there without declaring the temporary variable.  
 Using Cgiven or Cwhen, maybe?

I think you're going to have to have some holding space, but $_ should
do it and still avoid the predeclaration. My P6 syntax is still weak,
though. Maybe

  given big_calc() { return $_ if $_ }

__
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://platinum.yahoo.com

Re: How shall threads work in P6?

2003-04-01 Thread Dan Sugalski

At 7:35 AM -0800 4/1/03, Austin Hastings wrote:
--- Dan Sugalski [EMAIL PROTECTED] wrote:
 At 11:09 AM -0800 3/31/03, Austin Hastings wrote:
 --- Dan Sugalski [EMAIL PROTECTED] wrote:
   At 8:13 PM +0200 3/31/03, Matthijs van Duin wrote:
   On Mon, Mar 31, 2003 at 07:45:30AM -0800, Austin Hastings wrote:
   I've been thinking about closures, continuations, and
 coroutines,
   and
   one of the interfering points has been threads.
   
   What's the P6 thread model going to be?
   
   As I see it, parrot gives us the opportunity to implement
   preemptive
   threading at the VM level, even if it's not available via the
 OS.
   
   I think we should consider cooperative threading, implemented
 using
   continuations.  Yielding to another thread would automatically
   happen when a thread blocks, or upon explicit request by the
   programmer.
   
   It has many advantages:
 
   And one disadvantage:
 
   Dan doesn't like it. :)
 
   Well, there are actually a lot of disadvantages, but that's the
 only
   important one, so it's probably not worth much thought over
 alternate
   threading schemes for Parrot at least--it's going with an
 OS-level
   preemptive threading model.
 
   No, this isn't negotiable.
 
 More information please.
 There isn't any, particularly. We're doing preemptive threads. It
 isn't up for negotiation. This is one of the few things where I truly
 don't care what people's opinions on the matter are.
Okay, but what does OS-level mean? Are you relying on the OS for
implementing the threads (a sub-optimal idea, IMO) or something else?
Yes, we're using the OS-level threading facilities as part of the 
threading implementation.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: == vs. eq

On Tuesday, April 1, 2003, at 06:59  AM, Jonathan Scott Duff wrote:
On Tue, Apr 01, 2003 at 03:22:33AM -0700, Luke Palmer wrote:
   ($a =:= $b;  # looks a little better)
I like =:= as identity operator if we want one. If not, as long as .id
returns something that compares properly with both == and eq, I'm
happy.
Agreed, =:= is nice looking.

As I said before, I would strongly doubt that there will be an .id 
method _at all_ on any builtin types/classes -- because unless we used 
memory location as the id, it would imply that a separate id had to be 
calculated and stored with each object, which would be expensive, and 
if we _did_ use mem location as the id, getting and storing the id 
would be largely useless, since it could change unpredictably.

So I would imagine it _is_ possible to test that two values have the 
same identity, but I would imagine it is -not- possible to actually 
get what that identity is.  There's no .id method, per se, unless you 
create one yourself.

As to whether we want on identity op, the only purpose would be when 
building your own classes, so that string, numeric, smartmatch, and 
true identity comparisions could be overloaded separately.  We'd almost 
certainly have identical mean points to the same object in memory, 
as opposed to the fuzzier matching of the other variants.  Which sounds 
like a very good idea to me.

We've talked about this before, and let it drop.  We should decide... 
well, we should encourage the deciders to decide.  Myself, I strongly 
vote for -no- .id function, but for an identity-test operator separate 
from ==, eq, and ~~.  Called C=:=

MikeL

Re: == vs. eq

On Tuesday, April 1, 2003, at 02:22  AM, Luke Palmer wrote:
To outline the problem again, even disregarding user-defined objects:
Generic containers need a way to compare nums to nums and strings to
strings and only get true when they actually are equal.  The kind that
the user overloads with his own user-defined type to say what it means
to be equal.  No magic.
I would suggest that probably ~~ would be the thing most objects 
overload to determine equality.  Since == means numeric, and eq means 
string, that pretty much leaves ~~ as our beast-to-work-with.  Which is 
fine, because I can certainly see two things being equal numerically 
without being Equal like-wise.  And I can certainly see two things as 
being similar (like-wise), without being identical (identity-wise).

For example, two arrays may contain the name number of elements, but 
the actual elements in each may be totally different.  One possibility.

   my @a1 = (1,2,3);
   my @a2 = ('a','b','c');
   @a1 == @a2;   # true  -- same number of elements
   @a1 eq @a2;   # false -- stringifications aren't the same
   @a1 ~~ @a2;   # false -- elements contained don't ~~ match
   @a1 =:= @a2;  # false -- aren't bound to the same exact array
So I like your idea a lot, personally.

MikeL

Re: == vs. eq

On Tue, 1 Apr 2003, Michael Lazzaro wrote:
 As I said before, I would strongly doubt that there will be an .id
 method _at all_ on any builtin types/classes -- because unless we used
 memory location as the id, it would imply that a separate id had to be
 calculated and stored with each object, which would be expensive, and
 if we _did_ use mem location as the id, getting and storing the id
 would be largely useless, since it could change unpredictably.

 So I would imagine it _is_ possible to test that two values have the
 same identity, but I would imagine it is -not- possible to actually
 get what that identity is.  There's no .id method, per se, unless you
 create one yourself.

What about the \ (reference) operator?  If you take two references to an
object, they should compare the same, right?

~ John Williams

Re: How shall threads work in P6?

2003-04-01 Thread Simon Cozens

[EMAIL PROTECTED] (Matthijs Van Duin) writes:
 Well, if you optimize for the most common case, throw out threads altogether.
 
 Well, I almost would agree with you since cooperative threading can
 almost entirely be done in perl code, since they are built in
 continuations.  I actually gave an example of that earlier.

You thoroughly missed my point, but then I didn't make it very clearly:
the Huffman-encoding argument works well for language design, but doesn't
apply too well for implementation design.

We'll not bother implementing an exponentiation operator since
exponentiation is only used very rarely in Perl programs and we can
get around it with some shifts, multiplication and a loop if we need
it.

-- 
  They laughed at Columbus, they laughed at Fulton, they laughed at the
   Wright brothers.  But they also laughed at Bozo the Clown.
 -- Carl Sagan

Re: == vs. eq

2003-04-01 Thread Smylers

Luke Palmer writes:

 The solution that springs to mind is to conform to other languages'
 thought and make == polymorphically compare equality.

No!  Please!  PHP tried this and gets it very wrong indeed
(searching Google Groups for posts by me to this list containing the
word PHP should throw up a detailed explanation/rant on the issue).

Having both variables and operators being untyped leads to too much
guessing -- and guessing wrongly.  (It's a matter of opinion whether
it's the language or the programmer who guesses wrongly ...)

 Thanks to context-forcing, the string/numeric distinction is still
 there, at the expense of a little extra verbosity:
 
 +$a == +$b;  # Numeric compare
 ~$a == ~$b;  # String compare
  $a ==  $b;  # Generic compare

But what does a 'generic' compare do?  While Perl 6 has typed variables,
I get the impression that these are most useful for efficiency reasons
(especially for array and hash elements), and that it'll still be common
-- especially in simple scripts -- to continue to use Perl-5-style
scalar variables.

This very often leads to variables that contain textual representation
of numbers.  Pretty much all input from files, the keyboard, databases,
and from a web forms comes in as text even if its source considers it to
be numeric.  Likewise, in the programmer's mind such data is numeric.
Doing a string comparison because it currently happens to be stored as a
string is far too confusing.

The other reason for not having unary C+ and C~ to force numeric or
string context is the reason that Larry gave when we were discussing the
bitwise operators.  Somebody suggested that a single operator could do
for both numeric and character operations, using these symbols on the
operands to resolve ambiguities.

Larry rejected the idea, on the grounds that operands can be arbitrarily
complex expressions, and that can leave the C+ or C~ for the left
operand a considerable distance from the operator on which it has an
effect.

Smylers

Re: is is overoverloaded?

 Luke Palmer:
 # Now, I don't know what Larry has up his sleeve in this 
 # respect, but as I see it now, Cis is too heavily 
 # overloaded.  As it stands, it means 3 things:
 # 
 # (1) Attributing traits
 # (2) Inheriting base classes
 # (3) Tying variables
 # 
 # Depending on how traits are implemented, (1) and (3) might be 
 # unified.
 
 Who's to say they aren't all unified?  If a trait is just a sort of base
 class, and an instance of Scalar (the container) is seen as having its
 own (anonymous) class, then all three are one and the same.

Consider this:

my %hash is keyed(Int);

That would require Ckeyed to implement all hash methods, which I'm
not sure it wants to do.  Even if it does, how do you make it work
with base classes like Cconstant which Ialso want to change how
it's keyed.  For an even clearer example:

my %hash is constant;
my @array is constant;
my $scalar is constant;

Apparently, these are all implemented with the same container, and
should behave identically.

Nope.  Traits aren't ties.

--

sub foo() {...}
sub bar(code is rw) {
code = { Mwahahaha };
}
bar(foo);

If traits are inheritance, then this code shouldn't compile.  foo() is
not declared rw, so it can't be passed into bar, which is expecting a
sub that's declared rw.

Obviously, bar()'s Cis rw is referring to the container being
read-write, and not the sub's return value (which Cis rw would
specify were it on the definition of sub foo()).

Nah-uh.  Traits aren't inheritance either.

(As a side note, how Iwould one declare that a sub is expecting a
sub whose return value can be assigned to?)

--

In conclusion, there should be a different keyword for attributing
traits as for inheritance/tying.  Some possibilities:

  Inheritance/Tying:
is   (assuming traits have something different)
isa
uses
as
is/tied  (would work if traits can't be given to entire classes)
  Traits:
is
where

The former is more likely to change if anything is.

Luke

Re: == vs. eq

2003-04-01 Thread Simon Cozens

[EMAIL PROTECTED] (Smylers) writes:
 No!  Please!  PHP tried this and gets it very wrong indeed

Don't be too hasty on the basis of one failure - Ruby tried it and got
it very right indeed. In fact, Ruby has three types of equality/match
operator, all slightly different, but most people only need two.

Also, don't forget to distinguish between typed variables and typed values.
I was under the impression that Perl 6 is going to have both.

-- 
Last week I forgot how to ride a bicycle.  -- Steven Wright

Re: == vs. eq

Smylers wrote:
  Thanks to context-forcing, the string/numeric distinction is still
  there, at the expense of a little extra verbosity:
  
  +$a == +$b;  # Numeric compare
  ~$a == ~$b;  # String compare
   $a ==  $b;  # Generic compare
 
 But what does a 'generic' compare do?  While Perl 6 has typed variables,
 I get the impression that these are most useful for efficiency reasons
 (especially for array and hash elements), and that it'll still be common
 -- especially in simple scripts -- to continue to use Perl-5-style
 scalar variables.
 
 This very often leads to variables that contain textual representation
 of numbers.  Pretty much all input from files, the keyboard, databases,
 and from a web forms comes in as text even if its source considers it to
 be numeric.  Likewise, in the programmer's mind such data is numeric.
 Doing a string comparison because it currently happens to be stored as a
 string is far too confusing.
 
 The other reason for not having unary C+ and C~ to force numeric or
 string context is the reason that Larry gave when we were discussing the
 bitwise operators.  Somebody suggested that a single operator could do
 for both numeric and character operations, using these symbols on the
 operands to resolve ambiguities.
 
 Larry rejected the idea, on the grounds that operands can be arbitrarily
 complex expressions, and that can leave the C+ or C~ for the left
 operand a considerable distance from the operator on which it has an
 effect.

Very well put.  My solution sucks.

However, my problem remains.  What does the poor generic programmer do
when he needs generic equality!?  Particularly, what does 
Hash(keyed = Object) use?

Maybe a method in object, or a multimethod?  Called Csame or
somesuch?  Something just rings false about that :).

To outline the problem again, even disregarding user-defined objects:
Generic containers need a way to compare nums to nums and strings to
strings and only get true when they actually are equal.  The kind that
the user overloads with his own user-defined type to say what it means
to be equal.  No magic.

Ooh!  And I came up with a good identity operator!  :== (or =:= if you
like symmetry).  There's a beautiful parallel with := .

$a = $b;
$a == $b;   # is always true

$a := $b;
$a :== $b;  # is always true
   ($a =:= $b;  # looks a little better)

Luke

Re: Conditional Creturns?

2003-04-01 Thread arcadi shehter

Damian Conway writes:

  
 given baz(@args) { return $_ when defined }
 given baz(@args) { return $_ when $_  0 }
 # etc.
  

since we have 2 forms of return -- return and leave , may be we
can make return also to be a topicalizer for the rest of experssion
, and then :


return baz(@args) when $_ $_  0 ; 
return baz(@args) when defined  ; 
return baz(@args) when true ; 

but then inside given we will have to use leave : 

given $x { 
  leave  baz(@arg) when 5 # compare with $x 
  return bar(@arg) when 5 # compare with rezult of bar(@arg) 
}

or maybe we have to have anothre name for  return which also
topicalize. 

arcadi

Re: == vs. eq

On Tue, 1 Apr 2003, Michael Lazzaro wrote:

 On Tuesday, April 1, 2003, at 10:35  AM, John Williams wrote:
  On Tue, 1 Apr 2003, Michael Lazzaro wrote:
  So I would imagine it _is_ possible to test that two values have the
  same identity, but I would imagine it is -not- possible to actually
  get what that identity is.  There's no .id method, per se, unless
  you
  create one yourself.
 
  What about the \ (reference) operator?  If you take two references to
  an
  object, they should compare the same, right?

 In theory, I would think so.  But in P6 practice, that might not be as
 useful as it sounds:

 my @a;
 my @b := @a;  # bind @b same as @a

 [EMAIL PROTECTED] == [EMAIL PROTECTED];   # true, but not for the reason you 
 think!
  @a =:= @b;   # true, are bound to the same array

You're right, but personally, I have come to trust eq more that == when
comparing things-which-might-not-be-numbers, such as references.

 [EMAIL PROTECTED] eq [EMAIL PROTECTED];# true, for the reason I think
# (the string-representation of the refs are equal)

 [*] (Also, any identity test that relies on numerification or other
 transformation of the comparators is doing a lot of unnecessary work.)

Quite true.  But if we can agree that the reference is by necessity a
unique identifier for the object (or the container, at least), then a
$obj.id method which returned a numified reference value would do what you
want without unnecessary work (stringification) or unexpected results
(numification yields the length), Yes?

~ John Williams

Re: == vs. eq

On Tue, 1 Apr 2003, Michael Lazzaro wrote:
 So I *really* don't think comparing the equality of references will be
 a good idea, in P6.  :-)

 John Williams wrote:
   [EMAIL PROTECTED] eq [EMAIL PROTECTED];# true, for the reason I think
  # (the string-representation of the refs are equal)

 I'm pretty sure that breaks too, for the same reason.  It puts both
 sides in string context, which causes both sides to return the string
 representation of the underlying array, _not_ the string representation
 of the references themselves.

Yeah, I realized that might break after I sent the email too.

But you're still beating around my bush.  The main point is that the
reference is a unique identifier for an object.  At least, I haven't been
able to think why it wouldn't be yet (barring persistence).

So if you cede that point, achieving your identity comparison is a trivial
matter of spelling the comparison correctly.
Maybe its $x.ref == $y.ref, since 'ref' is less common than 'id'.
Maybe its something else.
If we can store it somewhere, we can surely figure out a way to compare it.

~ John Williams

Ruminating RFC 93- alphabet-blind pattern matching

2003-04-01 Thread Yary Hluchan

A couple nights ago I read RFC93 as discussed in Apoc. 5 and got
fired up- it reminded me of some ideas from when I was hacking
Henry Spencer's regexp package. How to futher generalize regular
expression input.  It's a bit orthoginal- a properly implemented
RFC93 make some difficult things easier- whether it's done as
binding to a sub, or as overloading =~, or whatever.

A very general description of a regular expression, is a program
that seeks a match within a string of letters.  In perl4 the string
of letters was a string of bytes, and in perl6 it's a string of
Unicode (most of the time).

It might as well be a string of *anythings*.  Binding a match against
a sub is a natural way to get the anythings you want to match.  Now,
I'm a newbie to perl6, so be patient with my hacked-up examples below.
They won't work in any language. And, for the first I tweaked RFC93:

  When the match is finished, the subroutine would be called one final
  time, and passed 1 arguments: a flag set to 1, and a list containing
  the unused elements

which I admit is a poor interface- but it lets me write:

  # Looking for luck- find a run of 3 numbers divisible by 7 or 13
  # sub numerology is simply an interface to an array of integers
  sub numerology { $#_ ? shift,unshift @::nums,@_ : splice @::nums,0,@_ }
  numerology =~ / ( !($_[0] % 7 and $_[0] % 13) )3 /;

True, it's easy to join integers with spaces and write an equivalent regexp
on the result- but why stringify when you don't have to?

I'm running into trouble here- using ( code ) to match against a single
atom (a number), it should be more character classy.  Assertions are
flexible enough to match all sorts of non-letter atoms, can write a grammer
to make it more readable- maybe something like
  numerology =~ /  divisible(7)divisible(13) 3 /;

Another example.  Let's say there's a class that deals with colors. It has
an operator that returns true if two colors look about the same. Given
a list of color objects, is there a regexp to find a rainbow? Even if the
color class doesn't support stringification? 

A less fanciful example- scan a sound. A very crude beat-finding regexp- 
 fetch_sound_frames =~
  / (   # store soundclip (array of frames) in $1
 (volume(-40db)50,1500) # quietish section, 50-1500 frames
 (volume(-15db)+) # Followed by some loud frame(s)
)   # End capture of the first beat

before # Make sure the loud/quiet pattern repeats,
 [  # but don't require the exact same frames
  volume(-40db)$2.length*.95,$2.length*1.05 
  volume(-15db)$3.length*.95,$3.length*1.05
 ]{3}

  /

The point I'm trying to make:
A regexp is already able to consume diffent kinds of characters from a
string- :u0, :u1, :u2, :u3- and with RFC93 it can be fed anything a sub
can return.  Those things can be characters- or strings- or stringified if
the regexp requires- but if the regexp doesn't have any strings to match
against, don't bother. Let the assertions get the atoms raw.

Plenty of brilliance on this list, I know I'm not brilliant, especially
when drowsy... did some research before posting but if this has been
covered already (or is completely daft) please face me in the right
direction and shoo me along gently.

-y

~

The Moon is New

Re: == vs. eq

2003-04-01 Thread Paul


--- Michael Lazzaro [EMAIL PROTECTED] wrote:
 Note if we are truly strict about C== always meaning compare 
 numerically, I imagine that the line:
 
 [EMAIL PROTECTED] == [EMAIL PROTECTED];
 
 would in fact be identical to _this_ line:
 
 @a.length == @b.length;# or whatever it's called

Whoa!! I read

 [EMAIL PROTECTED] == [EMAIL PROTECTED];

as does the [EMAIL PROTECTED] compare numerically as equal to the
[EMAIL PROTECTED], which is definitely NOT the same as 

@a.length == @b.length;# or whatever it's called

which I read as does @a have the same number of elements as @b?

Am I *that* far out of touch on P6 language? I thought that more of the
language was going to be similar than different!


__
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://platinum.yahoo.com

Re: How shall threads work in P6?

2003-04-01 Thread Dan Sugalski

At 11:09 AM -0800 3/31/03, Austin Hastings wrote:
--- Dan Sugalski [EMAIL PROTECTED] wrote:
 At 8:13 PM +0200 3/31/03, Matthijs van Duin wrote:
 On Mon, Mar 31, 2003 at 07:45:30AM -0800, Austin Hastings wrote:
 I've been thinking about closures, continuations, and coroutines,
 and
 one of the interfering points has been threads.
 
 What's the P6 thread model going to be?
 
 As I see it, parrot gives us the opportunity to implement
 preemptive
 threading at the VM level, even if it's not available via the OS.
 
 I think we should consider cooperative threading, implemented using
 continuations.  Yielding to another thread would automatically
 happen when a thread blocks, or upon explicit request by the
 programmer.
 
 It has many advantages:
 And one disadvantage:

 Dan doesn't like it. :)

 Well, there are actually a lot of disadvantages, but that's the only
 important one, so it's probably not worth much thought over alternate
 threading schemes for Parrot at least--it's going with an OS-level
 preemptive threading model.
 No, this isn't negotiable.
More information please.
There isn't any, particularly. We're doing preemptive threads. It 
isn't up for negotiation. This is one of the few things where I truly 
don't care what people's opinions on the matter are.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: == vs. eq

2003-04-01 Thread Marco Baringer

Luke Palmer [EMAIL PROTECTED] writes:

 However, my problem remains.  What does the poor generic programmer do
 when he needs generic equality!?

unfortunetly, no such thing exists.

see:

http://xrl.us/fdz

and 

http://www.nhplace.com/kent/PS/EQUAL.html

although the specifics are common lisp related the underlying ideas
are equally valid to perl.

-- 
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
 -Leonard Cohen

Re: == vs. eq

2003-04-01 Thread Jonathan Scott Duff

On Tue, Apr 01, 2003 at 03:30:46PM +0200, Marco Baringer wrote:
 Luke Palmer [EMAIL PROTECTED] writes:
 
  However, my problem remains.  What does the poor generic programmer do
  when he needs generic equality!?
 
 unfortunetly, no such thing exists.
 
 see:
 
 http://xrl.us/fdz
 
 and 
 
 http://www.nhplace.com/kent/PS/EQUAL.html
 
 although the specifics are common lisp related the underlying ideas
 are equally valid to perl.

Thanks Marco! I was pondering what generic equality meant (thinking
Luke knows something I don't) and having some difficulty until I read
these links.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: == vs. eq

2003-04-01 Thread Jonathan Scott Duff

On Tue, Apr 01, 2003 at 03:22:33AM -0700, Luke Palmer wrote:
[snip]
 Ooh!  And I came up with a good identity operator!  :== (or =:= if you
 like symmetry).  There's a beautiful parallel with := .
 
[snip]
 $a :== $b;  # is always true
($a =:= $b;  # looks a little better)

I like =:= as identity operator if we want one. If not, as long as .id
returns something that compares properly with both == and eq, I'm
happy.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: is is overoverloaded?

2003-04-01 Thread Austin Hastings


--- Luke Palmer [EMAIL PROTECTED] wrote:
  Luke Palmer:
  # Now, I don't know what Larry has up his sleeve in this 
  # respect, but as I see it now, Cis is too heavily 
  # overloaded.  As it stands, it means 3 things:
  # 
  # (1) Attributing traits
  # (2) Inheriting base classes
  # (3) Tying variables
  # 
  # Depending on how traits are implemented, (1) and (3) might be 
  # unified.
  
  Who's to say they aren't all unified?  If a trait is just a sort of
 base
  class, and an instance of Scalar (the container) is seen as having
 its
  own (anonymous) class, then all three are one and the same.
 
 Consider this:
 
 my %hash is keyed(Int);
 

Given that Larry was talking about typing the other day, how about a
template-style behavior that would use types and overrides:

class hash {
   has type key is Scalar; # Declare the types up front
   has type value is Scalar;   # Declare the types up front
   insert(key $k, value $v) {...}
}

my %hash has key(int)
 has value(String);# Run-time type substitution.

%hash{1} = Foo;  # okay
%hash{Foo} = Bar;  # Error, or String2int(Foo)

This has the advantage of allowing parameterized types in a standard
way, but the potential disadvantage of increasing compilation time, and
maybe increasing executable size. (I'm not sure on the last one...)




 That would require Ckeyed to implement all hash methods, which I'm
 not sure it wants to do.  Even if it does, how do you make it work
 with base classes like Cconstant which Ialso want to change how
 it's keyed.  For an even clearer example:
 
 my %hash is constant;
 my @array is constant;
 my $scalar is constant;
 
 Apparently, these are all implemented with the same container, and
 should behave identically.
 
 Nope.  Traits aren't ties.
 
 --
 
 sub foo() {...}
 sub bar(code is rw) {
 code = { Mwahahaha };
 }
 bar(foo);
 
 If traits are inheritance, then this code shouldn't compile.  foo()
 is
 not declared rw, so it can't be passed into bar, which is expecting a
 sub that's declared rw.
 
 Obviously, bar()'s Cis rw is referring to the container being
 read-write, and not the sub's return value (which Cis rw would
 specify were it on the definition of sub foo()).
 
 Nah-uh.  Traits aren't inheritance either.
 
 (As a side note, how Iwould one declare that a sub is expecting a
 sub whose return value can be assigned to?)
 
 --
 
 In conclusion, there should be a different keyword for attributing
 traits as for inheritance/tying.  Some possibilities:
 
   Inheritance/Tying:
 is   (assuming traits have something different)
 isa
 uses
 as
 is/tied  (would work if traits can't be given to entire classes)
   Traits:
 is
 where
 
 The former is more likely to change if anything is.
 
 Luke

Re: How shall threads work in P6?

2003-04-01 Thread Austin Hastings


--- Dan Sugalski [EMAIL PROTECTED] wrote:
 At 11:09 AM -0800 3/31/03, Austin Hastings wrote:
 --- Dan Sugalski [EMAIL PROTECTED] wrote:
   At 8:13 PM +0200 3/31/03, Matthijs van Duin wrote:
   On Mon, Mar 31, 2003 at 07:45:30AM -0800, Austin Hastings wrote:
   I've been thinking about closures, continuations, and
 coroutines,
   and
   one of the interfering points has been threads.
   
   What's the P6 thread model going to be?
   
   As I see it, parrot gives us the opportunity to implement
   preemptive
   threading at the VM level, even if it's not available via the
 OS.
   
   I think we should consider cooperative threading, implemented
 using
   continuations.  Yielding to another thread would automatically
   happen when a thread blocks, or upon explicit request by the
   programmer.
   
   It has many advantages:
 
   And one disadvantage:
 
   Dan doesn't like it. :)
 
   Well, there are actually a lot of disadvantages, but that's the
 only
   important one, so it's probably not worth much thought over
 alternate
   threading schemes for Parrot at least--it's going with an
 OS-level
   preemptive threading model.
 
   No, this isn't negotiable.
 
 More information please.
 
 There isn't any, particularly. We're doing preemptive threads. It 
 isn't up for negotiation. This is one of the few things where I truly
 don't care what people's opinions on the matter are.


Okay, but what does OS-level mean? Are you relying on the OS for
implementing the threads (a sub-optimal idea, IMO) or something else?

=Austin

RE: == vs. eq

2003-04-01 Thread Brent Dax

Luke Palmer:
# The first thing I noticed was the == / eq distinction.  This 
# has been invaluable for scripting, but since Perl 6 is 
# desiring to be more of a formal language, I'm wondering 
# whether the distinction is profitable. In generic programming 
# (my specialty :), it is very useful to have a standard sort 
# of equality[*] that all participating objects define.

Your desired standard sort of equality is provided by smartmatch.

$a ~~ $b

# The solution that springs to mind is to conform to other 
# languages' thought and make == polymorphically compare 
# equality.  Thanks to context-forcing, the string/numeric 
# distinction is still there, at the expense of a little extra 
# verbosity:
# 
# +$a == +$b;  # Numeric compare
# ~$a == ~$b;  # String compare
#  $a ==  $b;  # Generic compare

Conciseness and precision are lost.  What's gained?

# Then we could also use eq for real identity, if we wanted to.

Which is the more common operation, string equality or identity check?
Thought so.

--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)

How do you test this 'God' to prove it is who it says it is?
If you're God, you know exactly what it would take to convince me. Do
that.
--Marc Fleury on alt.atheism

RE: is is overoverloaded?

2003-04-01 Thread Brent Dax

Luke Palmer:
# Now, I don't know what Larry has up his sleeve in this 
# respect, but as I see it now, Cis is too heavily 
# overloaded.  As it stands, it means 3 things:
# 
# (1) Attributing traits
# (2) Inheriting base classes
# (3) Tying variables
# 
# Depending on how traits are implemented, (1) and (3) might be 
# unified.

Who's to say they aren't all unified?  If a trait is just a sort of base
class, and an instance of Scalar (the container) is seen as having its
own (anonymous) class, then all three are one and the same.

--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)

How do you test this 'God' to prove it is who it says it is?
If you're God, you know exactly what it would take to convince me. Do
that.
--Marc Fleury on alt.atheism

Re: == vs. eq