On Sun, Apr 06, 2003 at 05:52:30AM -0700, Paul wrote:
I just said you can *compare* them, I didn't say test whether they're
identical. Obviously comparing internal representations is a tricky
business, and may have three results: "yes, the lists they generate
are equal", "no, the lists they ge
> Tom Christiansen wrote:
> >>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. B
Tom Christiansen wrote:
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 th
--- Matthijs van Duin <[EMAIL PROTECTED]> wrote:
> I just said you can *compare* them, I didn't say test whether they're
> identical. Obviously comparing internal representations is a tricky
> business, and may have three results: "yes, the lists they generate
> are equal", "no, the lists they
On Sat, Apr 05, 2003 at 05:28:16PM -0700, Tom Christiansen wrote:
Is it possible that "finite internal representations" will differ in
internal representation yet produce identical series?
..[snip]..
Those define identical list, for any natural numbers X and Y, even as
compile-time constants. How
Steffen Mueller wrote:
>
> 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. S
Tom Christiansen wrote:
> Anyway, all fun and games with Messrs Engineer and Mathematician,
> you still want to find some sensible way of comparing lazily evaluated
> infinite lists so that you could get some sort of answer. But what
> is that answer? Or what is *an* answer? Can there even *be*
ree 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. :-)
Again, you seem to be thinking that C would take the size of
both side
>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
>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
>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
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
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
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
>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
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
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
>
>
--- 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
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
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'
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
--- 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
--- 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
--- 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...)
--- 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
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
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
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.
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
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,
[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
> --- 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
> 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
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
--- 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
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
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
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,
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
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
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 =:=
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
>
>
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
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
[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
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
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
> 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 ve
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
Since my mail server has been down for a week, I've had a lot of time
to look through Perl 6 as it stands, without being concerned with
"current issues." I'll do them one-message-at-a-time (and rather
slowly, too).
The first thing I noticed was the == / eq distinction. This has been
invaluable f
50 matches
Mail list logo
