subject:"Re\: <\( .... \)> vs <\{ .... \}>"

>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

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

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 diff

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

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 th

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 *thei

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 b

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

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

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, l

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

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'

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

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" symbolog

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 ==:/ (ma

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

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

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

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 disparat

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.

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 su

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,

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 auto

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

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

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 rehashi

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 whate

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 actu

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, pe

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,

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 o

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

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

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

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

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' compar

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 on

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" shou

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

Re: == vs. eq