subject:"Re\: == vs. eq"

>The IEEE-float-style infinities are quite sufficient for most purposes

>One thing I agree is that writing  1..Inf  is a *bit* sloppy since the 
>range operator  n..m  normally produces the numbers i for which 
>n <= i <= m  while  n..Inf  gives  n <= i < Inf

>but I can live with it

I could sure save myself a lot of typing by reading ahead to message N+1
before answering message N. :-)

--tom

PS:  For all N.  :-):-)

Re: == vs. eq

>Unless I'm very wrong, there are more whole numbers than natural 
>numbers. An induction should prove that there are twice as many.

We're probably having a language and/or terminology collision.  By natural
numbers, I mean the positive integers.  By whole numbers, I mean the
natural numbers plus the number zero.   Since both sets have infinite
members, each has just as many members as the other has.  It just *looks*
like the whole numbers have "one more".  But they don't, you know, because 
Inf+1 == Inf, as IEEE shows us in their seminal treatise on "How to Lie
With Computers under IEEE Floating Point".

It's not really relevant to figuring out how to evaluate equality testing
on unbounded lists in Perl, but I think that your inductive proof would
lead you to conclude the opposite of what you're thinking.  You can pick a
first member of both sets.  Then you can pick a second member of both sets.
Then a third, then a fourth, and so and so forth for all cardinal numbers.
Even though your list of pairings one from each set itself stretches to
infinity (not that that means it actually stops somewhere, of course, as
though infinity were a place; I mean it just stretches ever upwards without
bound), then I think induction will convince you that in the resulting
pair-list, there are no missed members from either set.  So we are
comfortable saying that there are "just as many" of one as the other; well,
*I* am comfortable saying that, at least, and I hope you are, too.  :-)
It's initially a bit disturbing, though, when you realize that this
necessarily leads to saying there are "just as many" multiple of two as
there are of, oh, eight.  Maybe that's why Cantor died mad. :-)

--tom

Re: == vs. eq

>You can define is very easily:  two lists are equal if the ith element of 
>one list is equal to the ith element of the other list, for all valid 
>indices i.

The problem is that you've slipped subtly from a well-known creature, like
1..10, a finite set of ten distinct integers, to a quite a different sort
of beast entirely, 1..Inf, which while notationally similar to the first,
does not share some very fundamental properties.  For example, it no longer
has an integral membership count, that is, a length.  This is problematic
if one is not quite careful.

>As for whether you can *evaluate* this test in bounded time, that depends. 
>Computers are incapable of storing truly infinite lists, so the lists will 
>have finite internal representations which you can compare.

Is it possible that "finite internal representations" will differ in
internal representation yet produce identical series?  It seems to me that
some meta-analsys would be required if this is possible.  If it is not
possible, then that means that every distinct series has a distinct
internal representation.  Certainly this is not true lexically: I can
use many variant lexical representations to produce the same infinite
series.  For example:

(1 .. X, X+1 .. Inf)
(1 .. Y, Y+1 .. Inf)

Those define identical list, for any natural numbers X and Y, even as 
compile-time constants.  However, save for special case of X==Y, I do
not expect their internal representation to be the same.  

>As for two dynamically generated infinite lists (which you can't easily 
>compare, for example if they're based on external input)... it will either 
>return false in finite time, or spend infinite time on determining they're 
>indeed equal.

I suppose you could classify

(1 .. X, X+1 .. Inf)
(1 .. Y, Y+1 .. Inf)

as "dynamically generated infinite lists", but again, given constants X and
Y, they really needn't be.  Even a run-time thing like the list (1 .. $X)
shouldn't actually need to spend infinite time on determining its
equivalence to (1 .. $Y).  However, there are more interesting
possibilities: generic iterator functions that you repeatedly call and
which produce successors that aren't generally recognizable.  Remember the
old flipflop, as in

if ( 1 .. /^$/ )  {  }
if ( /foo/ .. /bar/ ) {  }
if ( f() .. g() ) {  } 

You could, a think, have an infinite list that was really some fancy
interface to a dynamic interator of some sort.  I know it's interesting,
but whether this would be sufficiently useful to justify its complexity is
rather less obvious.  But if you did have such a list, where stepping 
down it implicitly called some sort of ->ITER method or whatnot, then 
for those I could see the intractability of finite evaluation, since it's
perfectly conceivable that it wouldn't terminate.  Another pitfall is
non-reproduceability; think about readline() as an  on a stream 
object whose underlying file descriptor is not seekable.  But I'm not sure
that the any of the sorts of lists we've been talking about have to have
that problem.  But I don't know whether we can be clever enough to step
around infinite evaluation through some sort of higher-level analysis.

A clever compiler could move things around.  Maybe it could change 

for ($i = 1; $i <= 10_000; $i++)  

into

for $i ( 1 .. 10_000 ) 

and then perhaps take advantage of that construct's lazy evaluation.
Given general purpose lazy evaluation, you could start doing things 
like thinking of 

for ($i = 1; $i <= fn(); $i++)  
for $i ( 1 .. fn() ) 

and making instead a list or array whose members are 

( 1 .. fn() )

However, do you evaluate fn() only once or repeatedly?

Hm.

If it were repeatedly, then I do see what you mean by dynamically
generated infinite lists.

>>In other words, if you treat Inf as any particular number (which Mr
>>Mathematician stridently yet somewhat ineffectually reminds you that are
>>*not* allowed to do!), then you may get peculiar results.

>There is no problem with doing that, as long as you define what you want 
>it to do.

Well, sure, you could let Inf = MAXINT + 1 for example, and then define
things as you want them to act, but that doesn't mean that this resulting
Inf is either what people think of as a Number nor what they think of as
Infinity.  See below on IEEE, which found it very useful to something of
the like.

>Remember, most of mathematics is just an invention of humans :)

I believe we are indeed trying to define what we want it to do, no?

So sure, you can create a new infinite set by conjoining some new elements
to an existing one.  That's what all the numberic sets are, pretty much.
Do be careful that the result has consistent properties, though.

>>(crap about testing first/last N elements)

>testing the first/last N elements is not the same as testing the whole list

>for all N  :)

>>Mr Mathematician, purist that he is, has of course long ago thrown up his
>>hands in disgust, contempt, or both, an

Re: == vs. eq

2003-04-05 Thread Steffen Mueller

Tom Christiansen wrote:
[...]
The price of that consideration would be to give the Mathematicians
blank looks on *their* faces for a very long time instead.  Certainly,
they'll be quick to tell you there are just as many whole numbers
as naturals.  So they won't know what you mean by equal up there.
[...]

Unless I'm very wrong, there are more whole numbers than natural 
numbers. An induction should prove that there are twice as many.

Steffen
--
@n=([283488072,6076],[2105905181,8583184],[1823729722,9282996],[281232,
1312416],[1823790605,791604],[2104676663,884944]);$b=6;@c=' -/\_|'=~/./g
;for(@n){for$n(@$_){map{$h=int$n/$b**$_;$n-=$b**$_*$h;[EMAIL PROTECTED]
0..11;[EMAIL PROTECTED],[EMAIL PROTECTED];[EMAIL PROTECTED]"\n"[EMAIL PROTECTED];

Re: == vs. eq

2003-04-05 Thread Matthijs van Duin

On Sun, Apr 06, 2003 at 12:38:29AM +0200, Matthijs van Duin wrote:
In other words, if you treat Inf as any particular number (which Mr
Mathematician stridently yet somewhat ineffectually reminds you that are
*not* allowed to do!), then you may get peculiar results.
There is no problem with doing that, as long as you define what you want 
it to do.
Actually, if you really want to "do" infinities the math-way, then just 
grab a book on set theory.

one thing you might not like however is that when you go beyond the finite, 
it becomes necessary to differentiate between cardinal and ordinal numbers.

That's probably something you don't want to do in perl

The IEEE-float-style infinities are quite sufficient for most purposes

One thing I agree is that writing  1..Inf  is a *bit* sloppy since the 
range operator  n..m  normally produces the numbers i for which 
n <= i <= m  while  n..Inf  gives  n <= i < Inf

but I can live with it

--
Matthijs van Duin  --  May the Forth be with you!

Re: == vs. eq

2003-04-05 Thread Matthijs van Duin

On Sat, Apr 05, 2003 at 03:22:17PM -0700, Tom Christiansen wrote:
When you write:

   (1..Inf) equal (0..Inf)

I'd like Perl to consider that false rather than having a blank look
on its face for a long time.  
The price of that consideration would be to give the Mathematicians
blank looks on *their* faces for a very long time instead.  Certainly,
they'll be quick to tell you there are just as many whole numbers
as naturals.  So they won't know what you mean by equal up there.
Based on his description, he meant element-wise equality.  And since the 
first element of (1..Inf) is 1, and the first element of (0..Inf) is 0, 
I agree with the result being "false".

So no blank stare from me (student of mathematics)

The length of both will be Inf ofcourse (meaning countably infinite. I 
don't think we have a need for working with uncountably infinite sets in 
perl ;-)

Practically speaking, I'm not sure how--even whether--you *could*
define it.
You can define is very easily:  two lists are equal if the ith element of 
one list is equal to the ith element of the other list, for all valid 
indices i.

As for whether you can *evaluate* this test in bounded time, that depends. 
Computers are incapable of storing truly infinite lists, so the lists will 
have finite internal representations which you can compare.

As for two dynamically generated infinite lists (which you can't easily 
compare, for example if they're based on external input)... it will either 
return false in finite time, or spend infinite time on determining they're 
indeed equal.

In other words, if you treat Inf as any particular number (which Mr
Mathematician stridently yet somewhat ineffectually reminds you that are
*not* allowed to do!), then you may get peculiar results.
There is no problem with doing that, as long as you define what you want 
it to do.

Remember, most of mathematics is just an invention of humans :)

(crap about testing first/last N elements)
testing the first/last N elements is not the same as testing the whole list

for all N  :)


Mr Mathematician, purist that he is, has of course long ago thrown up his
hands in disgust, contempt, or both, and stormed out of the room
If he has, he's a very narrow-minded Mr Mathematician


how can you say 1+Inf?
Unless you're speech-impaired, it's not too hard

and 1..Inf will be problematic, too, since to say 1..Inf is also to say 
there must exist some number whose successor is Inf.
*cough*bullshit  writing the interval 1..infinity is very common

I've skipped the rest.. not in the mood... but you make many references 
to a Mr Mathematician I don't think I want to work with... luckily I 
haven't seen him around here at the maths faculty

--
Matthijs van Duin  --  May the Forth be with you!

Re: == vs. eq

>When you write:

>(1..Inf) equal (0..Inf)

>I'd like Perl to consider that false rather than having a blank look
>on its face for a long time.  

The price of that consideration would be to give the Mathematicians
blank looks on *their* faces for a very long time instead.  Certainly,
they'll be quick to tell you there are just as many whole numbers
as naturals.  So they won't know what you mean by equal up there.

The Engineers might also be perplexed if you make that false, but
for rather different reasons.  I think that you will have to define
your "equal" operator in a way contrary to their respective
expectations, because both have ways of thinking that could quite
reasonably lead them to expect the answer to the expression above
to come out to be false, not true.

Practically speaking, I'm not sure how--even whether--you *could*
define it.  One is tempted to attempt something like saying that
operator "equal" is true of a *lazy*, *infinite* list if and only
if elements 0..N of both lists were each themselves "equal", and
then only blessedly finite values of N.

But where then do you stop?  If N is 1, then (1..Inf) and (1..Inf:2)
are ok.  If N is 2, meaning to check both the first pair from each
list and also the second one, they aren't.  However, if N is true,
(1..Inf) and (1, 2..Inf:2) are certainly ok.

In fact, that definition seems trivial to break.  Given a known N
steps of comparison, the lazy lists (1..Inf) and (1..N-1, (N..Inf:2))
would both test equal in the first N positions and differ in position
N+1.  Therefore, we can always break any operator that tests the
first N positions of both lazy lists, and thus that definition would
be wrong.

The reason Mr Engineer might expect false would be if they thought you were
eventually testing against Inf.  Due to his experience in numerical
programming, he sees NaN and Inf having certain behaviors that no pure
mathematician would even countenance.  On a system whose system nummifier
knows things like Inf and NaN already, you see this happening even today.
Witness real Perl:

% perl -e 'printf "%g\n", NaN'
nan
% perl -e 'printf "%g\n",  1 + NaN'
nan
% perl -e 'printf "%g\n", 42 * NaN'
nan
% perl -e 'printf "%g\n", Nan == NaN'
0
% perl -e 'printf "%g\n", 1+Nan == NaN'
0
% perl -le 'printf "%g\n", Inf'
inf
% perl -le 'printf "%g\n", 1+Inf'
inf
% perl -le 'printf "%g\n", 2+Inf'
inf
% perl -e 'printf "%g\n", Inf == Inf'
1
% perl -e 'printf "%g\n", Inf == -Inf'
0
% perl -e 'printf "%g\n", 1+Inf == Inf'
1
% perl -e 'printf "%g\n", Inf + Inf' 
inf
% perl -e 'printf "%g\n", Inf * Inf'
inf
% perl -e 'printf "%g\n", Inf / Inf'
nan

=begin ASIDE

Yes, it's platform dependent what you'll get:

mach1%  perl -le 'printf "On $^O, NaN == NaN is %g\n", Nan == NaN'
On openbsd, NaN == NaN is 1

mach2% perl -le 'printf "On $^O, NaN == NaN is %g\n", Nan == NaN'
On linux, NaN == NaN is 0

I believe that's because the libc on openbsd doesn't nummify string "NaN"
to any special IEEE float, whereas the redhate one did.

I am truly hoping that on Perl6, comparing "apples" with "greed" will mean
that you're testing NaN with itself, that testing NaN and *anything*
including another Nan with == will get you into trouble no matter what your
platform, and that that trouble will be the same irrespective of platform.

=end ASIDE

In other words, if you treat Inf as any particular number (which Mr
Mathematician stridently yet somewhat ineffectually reminds you that are
*not* allowed to do!), then you may get peculiar results.  Heck, you could
probably then get Mr Engineer to agree that the lazy lists (1..Inf) and
(0..Inf) are the same in the *last* N positions for all values of N, and
since you could just select N to be equal (ahem) to the length (ahem**Inf)
of your list, they must be equal. :-)

Mr Mathematician, purist that he is, has of course long ago thrown up his
hands in disgust, contempt, or both, and stormed out of the room.  To him,
most of those Perl examples given above were utter nonsense: how can you
say 1+Inf?  It bothers him to talk about Inf+1, and 1..Inf will be
problematic, too, since to say 1..Inf is also to say there must exist some
number whose successor is Inf.  And of course, there isn't.  Which is why
Inf is not a valid operand for numerical questions in Mr Mathematician's
platonically purist world of ideas.  But practical Mr Engineer has defined
his own Inf in which you can do limited otherwise apparently numerical
operations, because it was *practical* for him to do so.  He had work to
do, and needed some new rules.

While Mr Mathematician won't put up with comparing numbers and infinities,
he's quite comfortable with comparing *infinities* themselves.  He's
comfortable with infinite sets, and he's comfortable with infinite series,
too, which is what these lists seem to be.  I'm not sure that his
experience with infinite series

Re: == vs. eq

2003-04-05 Thread Larry Wall

On Tue, Apr 01, 2003 at 06:39:24PM -0500, Miko O'Sullivan wrote:
: 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).

The problem with this approach is that it assumes you can efficiently return
a string to be compared.  I'm not sure this is even true of strings, let alone
arrays and hashes.  When you write:

(1..Inf) equal (0..Inf)

I'd like Perl to consider that false rather than having a blank look
on its face for a long time.  It's just a generalization of how eq and
cmp give up as soon as they see two different characters in a string.

So whatever equivalence and ordering operators we end up with, they
had better be able to do lazy comparisons of characters or elements
and give up as soon as they know the answer.  In fact, they need to
be smarter than that if we also want:

(0..Inf) equal (0..Inf)

to run in finite time.  Lazy arrays need to delegate the operation
to their underlying generators whenever possible.

Larry

Re: == vs. eq

2003-04-04 Thread John Williams

On Thu, 3 Apr 2003, mlazzaro wrote:

> Yes.  I expect that internally, that's how it will work.  (And agreed,
> C<.ref> is probably a good name.)
>
> My concern with explicitly comparing refs in order to compare identity
> is a philosophical one.  It may be perfectly acceptable to do it via
>
> $x.ref == $y.ref;# do they exist at the same location?
>
> but I worry that that is a bit obtuse.  I'd rather people didn't have to
> worry about comparing reference locations, even indirectly, because it
> leads to thinking you can do things like this:
>
> my $loc = $x.ref;
> ...stuff...
> $loc == $y.ref;# OOPS: but has $x moved since then?
>
> Depending on the implementation, code like that might be dangerous.

I don't thing there is any danger.  Consider this:

my $xref = \$x;
...stuff...
print $$xref;# OOPS: but has $x moved since then?

Obviously that "oops" is not a concern.  The reference is not necessarily
a memory address.  The GC can move objects around if it wants, but it must
make sure the references to an object still refer to the object.

The danger I see with reference comparison involves the perl6
auto-dereferencing, and how to be sure we have a reference-to-an-object
and not a reference-to-a-reference-to-an-object.  For example:

   $b = @a;
   $b.ref; # is this [EMAIL PROTECTED] or [EMAIL PROTECTED]
   $b.ref == @a.ref;   # will this work?  should this work?

> I like the suggestion of =:= in particular because it so clearly relates
> to "bound to", so it feels quite elegant.

Personally, I doubt the necessity of yet-another-operator, because I'm not
convinced the operation is a frequent one.  We may both be biased by
our personal coding experience on that count.  But, no one can stop you
from defining infix:=:= in your own code.

~ John Williams

Re: == vs. eq

2003-04-04 Thread Paul

--- mlazzaro <[EMAIL PROTECTED]> wrote:
> Austin Hastings wrote:
> > It has been pointed out once already that we already talked about
> > this, and I for one am in favor of the general version of it.
> > The original discussion posited an "adverbial comparison", viz:
> > C<$a eq:ref $b>. Which, looking at your proposal, is very close to
> > C<$a =:= $b>, because I'm reading that as "equals, under
> > assignment".
> 
> What was decided about the adverbial ops -- did we ever get a
> confirmation or rejection on that proposal, or did it die in the
> ether?

I'd still like to know as well. I must've missed it.

> I like the idea lots (though I still would argue that
> identity-compare =:= is important enough conceptually to be
> a separate case.) 

I *disagree* with that, though only in principle. I don't want the code
to require a lot of special cases. That was one of P5's problems.
Larry&co are doing a beautiful job of designing a system by which the
language is systematically and semantically consistent. Admittedly, I'm
not doing any of the under-the-hood design, but for the sake of those
who are as well as my own, I'd rather see the smallest possible number
of "seperate case" situations.

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

Re: == vs. eq

2003-04-04 Thread mlazzaro

Austin Hastings wrote:
> It has been pointed out once already that we already talked about this,
> and I for one am in favor of the general version of it.
> 
> The original discussion posited an "adverbial comparison", viz:
> C<$a eq:ref $b>. Which, looking at your proposal, is very close to
> C<$a =:= $b>, because I'm reading that as "equals, under assignment".

What was decided about the adverbial ops -- did we ever get a
confirmation or rejection on that proposal, or did it die in the ether?

I like the idea lots (though I still would argue that identity-compare
=:= is important enough conceptually to be a separate case.)  My only
worry is that we make sure they don't cannibalize their own namespace. 
For example, to create an adverbial eq that works like this:

$a eq:soundex $b;

I wonder if it shouldn't be declared as:

sub infix:eq:soundex ($a,$b) {...}

as opposed to the simpler:

sub soundex ($a,$b) {...}

I.E. would you ever use the 'soundex' adverb without the 'eq', and if
not, mightn't you just call it 'eq:soundex' and be done with it?  (If we
made the colon allowable for the case of infix & other ops
declarations?)  That way you could have things like

$a eq:foo $b;
$a gt:foo $b;
$a lt:foo $b;
$a +:foo $b;

and the various declarations of 'foo' wouldn't get in each other's way,
even if you had a whole mess of 'em.

MikeL

Re: == vs. eq

2003-04-03 Thread mlazzaro

John Williams wrote:
>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.

> 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).

Yes, I believe that to be true as well.  For all practical purposes, the
memory address of an object is a unique identifier for the object, since
only one object can exist at the same point in memory.  Well, probably.  :-)

> 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.

Yes.  I expect that internally, that's how it will work.  (And agreed,
C<.ref> is probably a good name.)

My concern with explicitly comparing refs in order to compare identity
is a philosophical one.  It may be perfectly acceptable to do it via

$x.ref == $y.ref;# do they exist at the same location?

but I worry that that is a bit obtuse.  I'd rather people didn't have to
worry about comparing reference locations, even indirectly, because it
leads to thinking you can do things like this:

my $loc = $x.ref;
...stuff...
$loc == $y.ref;# OOPS: but has $x moved since then?

Depending on the implementation, code like that might be dangerous.

In addition to discouraging the above behavior, the main reason I like
an operator-based solution is that it can be used to test
identity-equality in a very explicit way.  You're not testing whether
two objects "exist at the same location" -- you're testing whether two
objects "share the same identity".  In practice, those two concepts are
linked, but conceptually I'd rather teach people to think of it as the latter.

I like the suggestion of =:= in particular because it so clearly relates
to "bound to", so it feels quite elegant.

MikeL

Re: == vs. eq

2003-04-02 Thread Paul

Error correction:

--- Paul <[EMAIL PROTECTED]> wrote:
> > > no idea how adverbial modification would affect that. Exactly
> > > what *would* adverbial assignment be? Would
> > >   $a =:\ $b
> > > be like 
> > >   $a = \$b

Thatv should have been: would
   $a =:\ $b
be like 
   \$a = \$b
???

And does that mean that the do{} block of the \ operator replaces the
do{} of the = op? That wouldn't work.

But the resulting muppet really *IS* cute! ;~}

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

Re: == vs. eq

2003-04-02 Thread Paul


--- Austin Hastings <[EMAIL PROTECTED]> wrote:
> --- Paul <[EMAIL PROTECTED]> wrote:
> > --- Austin Hastings <[EMAIL PROTECTED]> wrote:
> > > Likewise, I could argue that it be called C<=:\> (the
> > > "disgruntled muppet" operator?) since that reflects the
> > > "equals, under reference" symbology. But that's yucky.
> > 
> > Shouldn't that be ==:/ (maybe the "severely startled muppet"
> > operator? lol...) A single = would be assignment, but I have
> > no idea how adverbial modification would affect that. Exactly
> > what *would* adverbial assignment be? Would
> >   $a =:\ $b
> > be like 
> >   $a = \$b

Still no input here. Was it a stupid question? :)

> > > sub budgetwise(Int $a, Int $b) {
> > >  -1_000_000 <= $a - $b <= 1_000_000; }
> > > my Int $log_rolling, Int $pork_barrel;
> > > $log_rolling = random() * 1.0E9;
> > > $pork_barrel = random() * 1.0E9;
> > > if ($log_rolling eq:budgetwise $pork_barrel)
> > >   print "They cost the same, give or take a million dollars.";
> > 
> > Is that saying to make budgetwise the comparison operator at the
> > same precedence as eq? 
> 
> Actually, what I think I'm saying in this case is "replace the do()
> behavior of infix:eq with this sub."

Okay, that clicked. I'm here now.

> Which has kind of startling effects, because then you can also say
> things like this:
> 
> sub uniquely(@dest is rw, @src) {
>   my $last = @src[0] ~ "1";
>   for @src -> $s {
> @dest.push($last = $s) unless $s == $last;
>   }
> }
> my @a = <>; # Read all lines from a file.
> my @b =:uniquely @a;# Eat the duplicates

(Apologies: code above reformatted purely in the interest of readable
space, and not considered an improvement. >:O)
 
Ok, so you replace ='s do{} with uniquely(). The example won't work to
assign to a scalar, right? I think I'm following you, and I like where
you're going. 

"My God, it's full of stars"

> > Wouldn't that be much like saying
> > 
> >  my sub infix:um(Int$a,Int $b)is equiv(&infix:eq){#c.f.A6p.11
> >  -1_000_000 <= $a - $b <= 1_000_000; }
> >   if ($log_rolling um $pork_barrel) # etc
> 
> Looks right to me, modulo type-casting behavior -- I think yours does
> typechecking and blows up if the types are misaligned enough, while
> mine finds the right infix:= operator, and replaces the actual
> mechanics. (Frankly, I'm not sure what the right behavior of mine is.
> It may be better to think of it as "temporizing" the infix:= operator
> for one expression only. More thought required.)

Good territory to expore.

> > So how does one get a ref in P6 that won't dereference itself???
> 
> No idea. I thought that the auto-da-fe^Wautodereference behavior was
> intended to make "loose references" impossible -- that is, you have
> to treat a reference object as an object, always. (Which just means
> more backslashes, I guess.)
> 
> > Then we could say 
> >   my sub infix:embodies ($a,$b) is equiv(&infix:eq) { 
> >  $a.ref eq $b.ref  # unless eq deref's even here.
> >   }
> >   if ($x embodies $y) {
> >   print "X and Y refer to the same entity\n";
> >   } 
>
> Maybe you just have to say C<\$a eq \$b> ?

Makes sense to me. Then the right spelling of the above would be

   my sub infix:embodies ($a,$b) is equiv(&infix:eq) { \$a eq \$b }

The only reason I didn't put that to begin with was because of a
discussion I saw about arrays deref'ing themselves. Let's try again
with a little more complexity:

   my sub infix:embodies(Ref $a is ref,$b is ref)is equiv(&infix:eq){
  $a eq $b
   }

Could it be this simple? (Granted, for some definition of "simple")
If I read this right, it means $a is a referencing alias of the first
argument, $b the second. Could we then say

  if (@x embodies @y) { foople() }

and have it DWIM? Would that mean (in P5-speak) $a->[0] *IS* @x[0] ???
Because if so, then that's exactly what Larry was talking about. The
"cruft" has been sucked back up into the signature where the coder had
to work out the details *once*, and then the code of the operator is
deafeningly simple, as is it use.



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

Re: == vs. eq

2003-04-02 Thread Austin Hastings


--- Paul <[EMAIL PROTECTED]> wrote:
> 
> --- Austin Hastings <[EMAIL PROTECTED]> wrote:
> > Likewise, I could argue that it be called C<=:\> (the "disgruntled
> > muppet" operator?) since that reflects the "equals, under
> reference"
> > symbology. But that's yucky.
> 
> Shouldn't that be ==:/ (maybe the "severely startled muppet"
> operator?
> lol...) A single = would be assignment, but I have no idea how
> adverbial modification would affect that. Exactly what *would*
> adverbial assignment be? Would
>   $a =:\ $b
> be like 
>   $a = \$b;
>  
> > sub budgetwise(Int $a, Int $b){-1_000_000 <= $a - $b <= 1_000_000;}
> > my Int $log_rolling, Int $pork_barrel;
> > $log_rolling = random() * 1.0E9;
> > $pork_barrel = random() * 1.0E9;
> > if ($log_rolling eq:budgetwise $pork_barrel)
> >   print "They cost the same, give or take a million dollars.";
> 
> Is that saying to make budgetwise the comparison operator at the same
> precedence as eq? 

Actually, what I think I'm saying in this case is "replace the do()
behavior of infix:eq with this sub."

Which has kind of startling effects, because then you can also say
things like this:

sub uniquely(@dest is rw, @src)
{
  my $last = @src[0] ~ "1";

  for @src -> $s
  {
@dest.push($last = $s) unless $s == $last;
  }
}

my @a = <>; # Read all lines from a file.
my @b =:uniquely @a;# Eat the duplicates


> 
> Wouldn't that be much like saying
> 
>   my sub infix:um (Int $a, Int $b) is equiv(&infix:eq) { # c.f.A6
> p.11
>  -1_000_000 <= $a - $b <= 1_000_000; }
>   if ($log_rolling um $pork_barrel) # etc

Looks right to me, modulo type-casting behavior -- I think yours does
typechecking and blows up if the types are misaligned enough, while
mine finds the right infix:= operator, and replaces the actual
mechanics. (Frankly, I'm not sure what the right behavior of mine is.
It may be better to think of it as "temporizing" the infix:= operator
for one expression only. More thought required.)

> So how does one get a ref in P6 that won't dereference itself???

No idea. I thought that the auto-da-fe^Wautodereference behavior was
intended to make "loose references" impossible -- that is, you have to
treat a reference object as an object, always. (Which just means more
backslashes, I guess.)

> The we could say 
> 
>   my sub infix:embodies ($a,$b) is equiv(&infix:eq) { 
>  $a.ref eq $b.ref  # unless eq deref's even here.
>   }

Maybe you just have to say C<\$a eq \$b> ?

> 
>   if ($x embodies $y) {
>   print "X and Y refer to the same entity\n";
>   } 
> 

=Austin

Re: == vs. eq

2003-04-02 Thread Paul

--- Austin Hastings <[EMAIL PROTECTED]> wrote:
> Likewise, I could argue that it be called C<=:\> (the "disgruntled
> muppet" operator?) since that reflects the "equals, under reference"
> symbology. But that's yucky.

Shouldn't that be ==:/ (maybe the "severely startled muppet" operator?
lol...) A single = would be assignment, but I have no idea how
adverbial modification would affect that. Exactly what *would*
adverbial assignment be? Would
  $a =:\ $b
be like 
  $a = \$b;

> sub budgetwise(Int $a, Int $b){-1_000_000 <= $a - $b <= 1_000_000;}
> my Int $log_rolling, Int $pork_barrel;
> $log_rolling = random() * 1.0E9;
> $pork_barrel = random() * 1.0E9;
> if ($log_rolling eq:budgetwise $pork_barrel)
>   print "They cost the same, give or take a million dollars.";

Is that saying to make budgetwise the comparison operator at the same
precedence as eq? 

Wouldn't that be much like saying

  my sub infix:um (Int $a, Int $b) is equiv(&infix:eq) { # c.f.A6 p.11
 -1_000_000 <= $a - $b <= 1_000_000; }
  if ($log_rolling um $pork_barrel) # etc

So how does one get a ref in P6 that won't dereference itself???
The we could say 

  my sub infix:embodies ($a,$b) is equiv(&infix:eq) { 
 $a.ref eq $b.ref  # unless eq deref's even here.
  }

  if ($x embodies $y) {
  print "X and Y refer to the same entity\n";
  } 

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

Re: == vs. eq

2003-04-02 Thread Austin Hastings


--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
> 
> 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.

It has been pointed out once already that we already talked about this,
and I for one am in favor of the general version of it.

The original discussion posited an "adverbial comparison", viz:
C<$a eq:ref $b>. Which, looking at your proposal, is very close to
C<$a =:= $b>, because I'm reading that as "equals, under assignment".

Likewise, I could argue that it be called C<=:\> (the "disgruntled
muppet" operator?) since that reflects the "equals, under reference"
symbology. But that's yucky.

So: I believe that adverbial comparisons are desirable, and in fact
believe that arbitrary-sub comparisons are desirable, provided they
don't cost much.

sub budgetwise(Int $a, Int $b) { -1_000_000 <= $a - $b <= 1_000_000; }

my Int $log_rolling, Int $pork_barrel;

$log_rolling = random() * 1.0E9;
$pork_barrel = random() * 1.0E9;

if ($log_rolling eq:budgetwise $pork_barrel)
  print "They cost the same, give or take a million dollars.";


> 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.

Even inverted comparisons are suspect in junctionville.

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

Finest kind.

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

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.

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

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.

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

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 C.

-Miko

Miko O'Sullivan
Programmer Analyst
Rescue Mission of Roanoke

Re: == vs. eq

2003-04-01 Thread Simon Cozens

[EMAIL PROTECTED] (Luke Palmer) writes:
> I don't know what the "official" (this week) policy is, but I
> think it's a bad idea for references to auto-dereference. 

keys %$hash_r would bore me compared to keys $hash_r, since 'keys' can
easily know that it wants a hash; in fact, I thought that autodereferencing
of references in this way was something that was guaranteed from early on.
I seem to remember hacking it into the Perl 6 emulator, as was..

-- 
"The bad reputation UNIX has gotten is totally undeserved, laid on by people
 who don't understand, who have not gotten in there and tried anything."
-- Jim Joyce, former computer science lecturer at the University of California

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

> 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 I 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

2003-04-01 Thread Dave Whipp

Luke Palmer wrote:
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)
While we're rehashing old ideas, I'll take this opportunity to reference 
a previous idea:

  http://archive.develooper.com/[EMAIL PROTECTED]/msg13028.html

The =:= operator is cute, but it doesn't provide much scope to extend 
onto the infinite varieties of comparison that can be dreamt up. "eq:id" 
is much easier to generalize/extend.

Dave.
--
http://dave.whipp.name

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: == 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 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
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

or even just:

   @a == @b;

...which is probably not at all what you meant when you tried to 
compare [EMAIL PROTECTED] == [EMAIL PROTECTED]

Likewise, if you attempt to store the numerified reference of 
something, in hopes of using it later as an identifier:

   my num $id = [EMAIL PROTECTED];

You would be in for a world of hurt.  That line would actually set $id 
to the number of elements in @a -- at least, I hope it would:

   my $x = @a;   # stores a reference to @a
   my $x = [EMAIL PROTECTED];  # same thing
   my int $x = @a;   # stores length of @a
   my int $x = [EMAIL PROTECTED];  # same thing
So I don't think comparing references would do what you wanted, for 
arbitrary (non-scalar) objects.  Or rather, I don't think it'll be easy 
to get at a "numeric representation" of a reference ... a true 
'identity' test might be a better approach.[*]

(?)

MikeL

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

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: == 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 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

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: == 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 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

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 C 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: == 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

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: == vs. eq

2003-04-01 Thread Steffen Mueller

Luke Palmer wrote:
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.
[...]

Brent Dax:
Your desired "standard sort of equality" is provided by smartmatch.

	$a ~~ $b
Don't get too hasty here, I actually did put some thought into this.
Smart match was not what I was thinking of. 
[...]

# 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?
Sorry, but how's precision lost here? As Luke points out, we'd free up 
the eq operator to do more sophisticated comparisons like (deeply) 
checking for identity of data structures.
Admittedly, this would be a major break with Perl5's idioms, especially 
since eq would work the same in some situations in Perl6 as it did in 
Perl5, but even ignoring that it'd be slower, it'd break in other 
situations where joe average-scripter used it as (s)he used Perl5's eq 
operator.

[...]

Steffen
--
@n=([283488072,6076],[2105905181,8583184],[1823729722,9282996],[281232,
1312416],[1823790605,791604],[2104676663,884944]);$b=6;@c=' -/\_|'=~/./g
;for(@n){for$n(@$_){map{$h=int$n/$b**$_;$n-=$b**$_*$h;[EMAIL PROTECTED]
0..11;[EMAIL PROTECTED],[EMAIL PROTECTED];[EMAIL PROTECTED]"\n"[EMAIL PROTECTED];

Re: == vs. eq