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*
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. So 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.
--- 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 generate
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
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
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
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
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
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
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
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
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 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
, only they happen to be list elements instead.
One could *almost* extend Ceq to have this semantics when applied to
lists. But it breaks down when you recursively want to do polymorphic
== vs eq. Whereas C $a equal $b would perhaps have a few smarts
about comparing dissimilar types, though
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,
--- 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
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
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.
snip
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
--- 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
--- 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 =
--- 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.
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
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
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
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 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
[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
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
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
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
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
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, 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 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
[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
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
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
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
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
40 matches
Mail list logo
