RE: == vs. eq
Luke Palmer:
# The first thing I noticed was the == / eq distinction. This
# has been invaluable for scripting, but since Perl 6 is
# desiring to be more of a formal language, I'm wondering
# whether the distinction is profitable. In generic programming
# (my specialty :), it is very useful to have a standard sort
# of equality[*] that all participating objects define.
Your desired standard sort of equality is provided by smartmatch.
$a ~~ $b
# The solution that springs to mind is to conform to other
# languages' thought and make == polymorphically compare
# equality. Thanks to context-forcing, the string/numeric
# distinction is still there, at the expense of a little extra
# verbosity:
#
# +$a == +$b; # Numeric compare
# ~$a == ~$b; # String compare
# $a == $b; # Generic compare
Conciseness and precision are lost. What's gained?
# Then we could also use eq for real identity, if we wanted to.
Which is the more common operation, string equality or identity check?
Thought so.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
How do you test this 'God' to prove it is who it says it is?
If you're God, you know exactly what it would take to convince me. Do
that.
--Marc Fleury on alt.atheism
RE: is is overoverloaded?
Luke Palmer:
# Now, I don't know what Larry has up his sleeve in this
# respect, but as I see it now, Cis is too heavily
# overloaded. As it stands, it means 3 things:
#
# (1) Attributing traits
# (2) Inheriting base classes
# (3) Tying variables
#
# Depending on how traits are implemented, (1) and (3) might be
# unified.
Who's to say they aren't all unified? If a trait is just a sort of base
class, and an instance of Scalar (the container) is seen as having its
own (anonymous) class, then all three are one and the same.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
How do you test this 'God' to prove it is who it says it is?
If you're God, you know exactly what it would take to convince me. Do
that.
--Marc Fleury on alt.atheism
Re: == vs. eq
Luke Palmer:
# The first thing I noticed was the == / eq distinction. This
# has been invaluable for scripting, but since Perl 6 is
# desiring to be more of a formal language, I'm wondering
# whether the distinction is profitable. In generic programming
# (my specialty :), it is very useful to have a standard sort
# of equality[*] that all participating objects define.
Your desired standard sort of equality is provided by smartmatch.
$a ~~ $b
Don't get too hasty here, I actually did put some thought into this.
Smart match was not what I was thinking of. I don't think two hashes
should be considered equal if their key intersection is nonempty.
# 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?
IOne solitary equality operator. Remember, I'm considering this
from a generic programmer's point of view. I'm already aware that the
== eq distinction is useful for scripting.
class Map {
method insert(Pair $p) {
push @.elems: $p;
}
method get($key) {
for (@.elems) { return $_.value if $_.key == $key }
}
has Pair @.elems;
}
Or should that have been C$_.key eq $key? It certainly shouldn't have
been ~~ (lest this work:)
my Map $map;
my @array = (1..5);
my @other = (4..12);
$map.insert(@array = 1);
$map.get(@other); # Returns 1 !!!
Whatever the array equality operator is, it sure isn't that! :)
Do you see the problem now? If I use ==, then I get length
comparison. If I use eq, then I get string comparison (which,
depending on the elements' types, may not be correct).
Map was just a coded example of what Hash has to do if it doesn't want
to be keyed by strings (and that option is given in Perl 6).
Luke
Re: == vs. eq
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: How shall threads work in P6?
[EMAIL PROTECTED] (Matthijs Van Duin) writes: Well, if you optimize for the most common case, throw out threads altogether. Well, I almost would agree with you since cooperative threading can almost entirely be done in perl code, since they are built in continuations. I actually gave an example of that earlier. You thoroughly missed my point, but then I didn't make it very clearly: the Huffman-encoding argument works well for language design, but doesn't apply too well for implementation design. We'll not bother implementing an exponentiation operator since exponentiation is only used very rarely in Perl programs and we can get around it with some shifts, multiplication and a loop if we need it. -- They laughed at Columbus, they laughed at Fulton, they laughed at the Wright brothers. But they also laughed at Bozo the Clown. -- Carl Sagan
Re: == vs. eq
Luke Palmer writes: The solution that springs to mind is to conform to other languages' thought and make == polymorphically compare equality. No! Please! PHP tried this and gets it very wrong indeed (searching Google Groups for posts by me to this list containing the word PHP should throw up a detailed explanation/rant on the issue). Having both variables and operators being untyped leads to too much guessing -- and guessing wrongly. (It's a matter of opinion whether it's the language or the programmer who guesses wrongly ...) Thanks to context-forcing, the string/numeric distinction is still there, at the expense of a little extra verbosity: +$a == +$b; # Numeric compare ~$a == ~$b; # String compare $a == $b; # Generic compare But what does a 'generic' compare do? While Perl 6 has typed variables, I get the impression that these are most useful for efficiency reasons (especially for array and hash elements), and that it'll still be common -- especially in simple scripts -- to continue to use Perl-5-style scalar variables. This very often leads to variables that contain textual representation of numbers. Pretty much all input from files, the keyboard, databases, and from a web forms comes in as text even if its source considers it to be numeric. Likewise, in the programmer's mind such data is numeric. Doing a string comparison because it currently happens to be stored as a string is far too confusing. The other reason for not having unary C+ and C~ to force numeric or string context is the reason that Larry gave when we were discussing the bitwise operators. Somebody suggested that a single operator could do for both numeric and character operations, using these symbols on the operands to resolve ambiguities. Larry rejected the idea, on the grounds that operands can be arbitrarily complex expressions, and that can leave the C+ or C~ for the left operand a considerable distance from the operator on which it has an effect. Smylers
Re: is is overoverloaded?
Luke Palmer:
# Now, I don't know what Larry has up his sleeve in this
# respect, but as I see it now, Cis is too heavily
# overloaded. As it stands, it means 3 things:
#
# (1) Attributing traits
# (2) Inheriting base classes
# (3) Tying variables
#
# Depending on how traits are implemented, (1) and (3) might be
# unified.
Who's to say they aren't all unified? If a trait is just a sort of base
class, and an instance of Scalar (the container) is seen as having its
own (anonymous) class, then all three are one and the same.
Consider this:
my %hash is keyed(Int);
That would require Ckeyed to implement all hash methods, which I'm
not sure it wants to do. Even if it does, how do you make it work
with base classes like Cconstant which Ialso want to change how
it's keyed. For an even clearer example:
my %hash is constant;
my @array is constant;
my $scalar is constant;
Apparently, these are all implemented with the same container, and
should behave identically.
Nope. Traits aren't ties.
--
sub foo() {...}
sub bar(code is rw) {
code = { Mwahahaha };
}
bar(foo);
If traits are inheritance, then this code shouldn't compile. foo() is
not declared rw, so it can't be passed into bar, which is expecting a
sub that's declared rw.
Obviously, bar()'s Cis rw is referring to the container being
read-write, and not the sub's return value (which Cis rw would
specify were it on the definition of sub foo()).
Nah-uh. Traits aren't inheritance either.
(As a side note, how Iwould one declare that a sub is expecting a
sub whose return value can be assigned to?)
--
In conclusion, there should be a different keyword for attributing
traits as for inheritance/tying. Some possibilities:
Inheritance/Tying:
is (assuming traits have something different)
isa
uses
as
is/tied (would work if traits can't be given to entire classes)
Traits:
is
where
The former is more likely to change if anything is.
Luke
Re: == vs. eq
[EMAIL PROTECTED] (Smylers) writes: No! Please! PHP tried this and gets it very wrong indeed Don't be too hasty on the basis of one failure - Ruby tried it and got it very right indeed. In fact, Ruby has three types of equality/match operator, all slightly different, but most people only need two. Also, don't forget to distinguish between typed variables and typed values. I was under the impression that Perl 6 is going to have both. -- Last week I forgot how to ride a bicycle. -- Steven Wright
Re: == vs. eq
Smylers wrote: Thanks to context-forcing, the string/numeric distinction is still there, at the expense of a little extra verbosity: +$a == +$b; # Numeric compare ~$a == ~$b; # String compare $a == $b; # Generic compare But what does a 'generic' compare do? While Perl 6 has typed variables, I get the impression that these are most useful for efficiency reasons (especially for array and hash elements), and that it'll still be common -- especially in simple scripts -- to continue to use Perl-5-style scalar variables. This very often leads to variables that contain textual representation of numbers. Pretty much all input from files, the keyboard, databases, and from a web forms comes in as text even if its source considers it to be numeric. Likewise, in the programmer's mind such data is numeric. Doing a string comparison because it currently happens to be stored as a string is far too confusing. The other reason for not having unary C+ and C~ to force numeric or string context is the reason that Larry gave when we were discussing the bitwise operators. Somebody suggested that a single operator could do for both numeric and character operations, using these symbols on the operands to resolve ambiguities. Larry rejected the idea, on the grounds that operands can be arbitrarily complex expressions, and that can leave the C+ or C~ for the left operand a considerable distance from the operator on which it has an effect. Very well put. My solution sucks. However, my problem remains. What does the poor generic programmer do when he needs generic equality!? Particularly, what does Hash(keyed = Object) use? Maybe a method in object, or a multimethod? Called Csame or somesuch? Something just rings false about that :). To outline the problem again, even disregarding user-defined objects: Generic containers need a way to compare nums to nums and strings to strings and only get true when they actually are equal. The kind that the user overloads with his own user-defined type to say what it means to be equal. No magic. Ooh! And I came up with a good identity operator! :== (or =:= if you like symmetry). There's a beautiful parallel with := . $a = $b; $a == $b; # is always true $a := $b; $a :== $b; # is always true ($a =:= $b; # looks a little better) Luke
Re: How shall threads work in P6?
At 11:09 AM -0800 3/31/03, Austin Hastings wrote: --- Dan Sugalski [EMAIL PROTECTED] wrote: At 8:13 PM +0200 3/31/03, Matthijs van Duin wrote: On Mon, Mar 31, 2003 at 07:45:30AM -0800, Austin Hastings wrote: I've been thinking about closures, continuations, and coroutines, and one of the interfering points has been threads. What's the P6 thread model going to be? As I see it, parrot gives us the opportunity to implement preemptive threading at the VM level, even if it's not available via the OS. I think we should consider cooperative threading, implemented using continuations. Yielding to another thread would automatically happen when a thread blocks, or upon explicit request by the programmer. It has many advantages: And one disadvantage: Dan doesn't like it. :) Well, there are actually a lot of disadvantages, but that's the only important one, so it's probably not worth much thought over alternate threading schemes for Parrot at least--it's going with an OS-level preemptive threading model. No, this isn't negotiable. More information please. There isn't any, particularly. We're doing preemptive threads. It isn't up for negotiation. This is one of the few things where I truly don't care what people's opinions on the matter are. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: == vs. eq
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
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
On Tue, Apr 01, 2003 at 03:22:33AM -0700, Luke Palmer wrote: [snip] Ooh! And I came up with a good identity operator! :== (or =:= if you like symmetry). There's a beautiful parallel with := . [snip] $a :== $b; # is always true ($a =:= $b; # looks a little better) I like =:= as identity operator if we want one. If not, as long as .id returns something that compares properly with both == and eq, I'm happy. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: is is overoverloaded?
--- Luke Palmer [EMAIL PROTECTED] wrote:
Luke Palmer:
# Now, I don't know what Larry has up his sleeve in this
# respect, but as I see it now, Cis is too heavily
# overloaded. As it stands, it means 3 things:
#
# (1) Attributing traits
# (2) Inheriting base classes
# (3) Tying variables
#
# Depending on how traits are implemented, (1) and (3) might be
# unified.
Who's to say they aren't all unified? If a trait is just a sort of
base
class, and an instance of Scalar (the container) is seen as having
its
own (anonymous) class, then all three are one and the same.
Consider this:
my %hash is keyed(Int);
Given that Larry was talking about typing the other day, how about a
template-style behavior that would use types and overrides:
class hash {
has type key is Scalar; # Declare the types up front
has type value is Scalar; # Declare the types up front
insert(key $k, value $v) {...}
}
my %hash has key(int)
has value(String);# Run-time type substitution.
%hash{1} = Foo; # okay
%hash{Foo} = Bar; # Error, or String2int(Foo)
This has the advantage of allowing parameterized types in a standard
way, but the potential disadvantage of increasing compilation time, and
maybe increasing executable size. (I'm not sure on the last one...)
That would require Ckeyed to implement all hash methods, which I'm
not sure it wants to do. Even if it does, how do you make it work
with base classes like Cconstant which Ialso want to change how
it's keyed. For an even clearer example:
my %hash is constant;
my @array is constant;
my $scalar is constant;
Apparently, these are all implemented with the same container, and
should behave identically.
Nope. Traits aren't ties.
--
sub foo() {...}
sub bar(code is rw) {
code = { Mwahahaha };
}
bar(foo);
If traits are inheritance, then this code shouldn't compile. foo()
is
not declared rw, so it can't be passed into bar, which is expecting a
sub that's declared rw.
Obviously, bar()'s Cis rw is referring to the container being
read-write, and not the sub's return value (which Cis rw would
specify were it on the definition of sub foo()).
Nah-uh. Traits aren't inheritance either.
(As a side note, how Iwould one declare that a sub is expecting a
sub whose return value can be assigned to?)
--
In conclusion, there should be a different keyword for attributing
traits as for inheritance/tying. Some possibilities:
Inheritance/Tying:
is (assuming traits have something different)
isa
uses
as
is/tied (would work if traits can't be given to entire classes)
Traits:
is
where
The former is more likely to change if anything is.
Luke
Re: Conditional Creturns?
I'm looking for a Perl6 way to say that oft-repeated, oft-chained
two-line snippet up there without declaring the temporary variable.
Using Cgiven or Cwhen, maybe?
I think you're going to have to have some holding space, but $_ should
do it and still avoid the predeclaration. My P6 syntax is still weak,
though. Maybe
given big_calc() { return $_ if $_ }
__
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://platinum.yahoo.com
Re: How shall threads work in P6?
At 7:35 AM -0800 4/1/03, Austin Hastings wrote: --- Dan Sugalski [EMAIL PROTECTED] wrote: At 11:09 AM -0800 3/31/03, Austin Hastings wrote: --- Dan Sugalski [EMAIL PROTECTED] wrote: At 8:13 PM +0200 3/31/03, Matthijs van Duin wrote: On Mon, Mar 31, 2003 at 07:45:30AM -0800, Austin Hastings wrote: I've been thinking about closures, continuations, and coroutines, and one of the interfering points has been threads. What's the P6 thread model going to be? As I see it, parrot gives us the opportunity to implement preemptive threading at the VM level, even if it's not available via the OS. I think we should consider cooperative threading, implemented using continuations. Yielding to another thread would automatically happen when a thread blocks, or upon explicit request by the programmer. It has many advantages: And one disadvantage: Dan doesn't like it. :) Well, there are actually a lot of disadvantages, but that's the only important one, so it's probably not worth much thought over alternate threading schemes for Parrot at least--it's going with an OS-level preemptive threading model. No, this isn't negotiable. More information please. There isn't any, particularly. We're doing preemptive threads. It isn't up for negotiation. This is one of the few things where I truly don't care what people's opinions on the matter are. Okay, but what does OS-level mean? Are you relying on the OS for implementing the threads (a sub-optimal idea, IMO) or something else? Yes, we're using the OS-level threading facilities as part of the threading implementation. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: == vs. eq
On Tuesday, April 1, 2003, at 06:59 AM, Jonathan Scott Duff wrote: On Tue, Apr 01, 2003 at 03:22:33AM -0700, Luke Palmer wrote: ($a =:= $b; # looks a little better) I like =:= as identity operator if we want one. If not, as long as .id returns something that compares properly with both == and eq, I'm happy. Agreed, =:= is nice looking. As I said before, I would strongly doubt that there will be an .id method _at all_ on any builtin types/classes -- because unless we used memory location as the id, it would imply that a separate id had to be calculated and stored with each object, which would be expensive, and if we _did_ use mem location as the id, getting and storing the id would be largely useless, since it could change unpredictably. So I would imagine it _is_ possible to test that two values have the same identity, but I would imagine it is -not- possible to actually get what that identity is. There's no .id method, per se, unless you create one yourself. As to whether we want on identity op, the only purpose would be when building your own classes, so that string, numeric, smartmatch, and true identity comparisions could be overloaded separately. We'd almost certainly have identical mean points to the same object in memory, as opposed to the fuzzier matching of the other variants. Which sounds like a very good idea to me. We've talked about this before, and let it drop. We should decide... well, we should encourage the deciders to decide. Myself, I strongly vote for -no- .id function, but for an identity-test operator separate from ==, eq, and ~~. Called C=:= MikeL
Re: == vs. eq
On 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: Conditional Creturns?
Damian Conway writes:
given baz(@args) { return $_ when defined }
given baz(@args) { return $_ when $_ 0 }
# etc.
since we have 2 forms of return -- return and leave , may be we
can make return also to be a topicalizer for the rest of experssion
, and then :
return baz(@args) when $_ $_ 0 ;
return baz(@args) when defined ;
return baz(@args) when true ;
but then inside given we will have to use leave :
given $x {
leave baz(@arg) when 5 # compare with $x
return bar(@arg) when 5 # compare with rezult of bar(@arg)
}
or maybe we have to have anothre name for return which also
topicalize.
arcadi
Re: == vs. eq
On 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
[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
Luke Palmer wrote: As much as I don't want to refute my own operator, I agree with you here. I don't know what the official (this week) policy is, but I think it's a bad idea for references to auto-dereference. The other way around is fine, though (arrays auto-referencizing). I'm pretty darn sure they autodereference... we last talked about this when we were trying to determine how an arrayref would behave when interpolated into a string literal (answer: just like the original array would). Here's the relevant message: On Fri, Dec 06, 2002, Larry Wall wrote: On Fri, Dec 06, 2002, Dan Sugalski wrote: : If an aggregate and a reference to an aggregate are going to behave : the same, which is what Larry's indicated in the past, then : stringifying a reference should be the same as stringifying its : referent. This is a bit of an oversimplification. $foo and @foo do not always behave the same, even if $foo and @foo refer to the same array object. In particular, $foo doesn't behave like @foo in a list context. snip But it's probably fair to say that $foo and @foo always behave identically in a scalar context. So I *really* don't think comparing the equality of references will be a good idea, in P6. :-) John Williams wrote: You're right, but personally, I have come to trust eq more that == when comparing things-which-might-not-be-numbers, such as references. [EMAIL PROTECTED] eq [EMAIL PROTECTED];# true, for the reason I think # (the string-representation of the refs are equal) I'm pretty sure that breaks too, for the same reason. It puts both sides in string context, which causes both sides to return the string representation of the underlying array, _not_ the string representation of the references themselves. MikeL
Re: Conditional Creturns?
Paul writes:
My P6 syntax is still weak, though. Maybe
given big_calc() { return $_ if $_ }
Using Cfor works in Perl 5. Is there anything preventing this working
in Perl 6:
for big_calc() { return $_ if $_ }
Smylers
Re: == vs. eq
On Tue, 1 Apr 2003, Miko O'Sullivan wrote: =:= is a generic comparison operator that simply calls the value_for_comparison method of the objects on left and right. If they both return the same string, then the expression returns true, else it ^^ returns false. If they don't have that method, that's a fatal error. Their value_for_comparison() methods must have been defined in the same class, otherwise you're comparing apples and oranges. (Yes, I'm sure we can think of a better name than value_for_comparison.) I propose the name str for the value_for_comparison method, and eq for the generic comparison operator. That's how my objects will work, anyway. ~ John Williams
Re: == vs. eq
One thing we should clear up is that we already *have* a generic comparator, C~~, depending on what you mean by generic. It can be made to compare things however you like, according to whatever standard of similarness you decide you want to enforce, and can even compare objects of disparate types (if you tell it how.) The way I personally have been envisioning this working is: $a == $b; # compares numerifications of $a and $b $a eq $b; # compares stringifications of $a and $b $a ~~ $b; # tests equality of $a and $b $a =:= $b; # tests identity of $a and $b Of these, I would expect that ==, eq, and =:= would almost never be overloaded, because they have very specific meanings.[*] You _could_ choose to override those == and eq for a particular custom class, and use those for comparing equality of objects. But since some people will tend to want to override ==, and some will want to override eq, it's not clear that the Perl6 community will converge on using only one or the other, which might make things quite confusing if you're using a library that has standardized on the opposite convention from your own. ~~, on the other hand, is meant to be overloaded to a possibly-excruciating extent, and I've been assuming that it will be the thing that classes most often overload when they want to test equality of two arbitrary objects, without resorting to serializing them via num/str. (Using num/str comparisions to test for object equality obviously only works if num/stringifying _completely_ serializes the object -- which very often is _not_ what you want the num/stringification of an object to do, by default.) The proposed =:=, however, merely tests that two objects are identical -- that is, _that they are bound to the same underlying thing_. It's possible for two objects to be equal, ~~wise, without actually being identical, identitywise. I don't see ever wanting to overload =:=, and it's unclear if it should even be allowed. Note also that == and eq comparisions are naturally accompanied by greater-than, less-than variants. But ~~ and =:= don't really have those variants, because they wouldn't make much sense. Having said all that, it should be noted that I'm completely making this stuff up. MikeL [*] By 'overloading', I mean multimethod variants. The comparision operators are almost certainly accomplished via multimethods, $a and $b being the two invocants.
Short-circuiting user-defined operators
Is there any way to write a user-defined operator so that it
short-circuits, like and || ? This might be function trait, for
instance,
sub infix:!! ($lhs, $rhs) is short_circuit {...}
Alternatively, there might be a new parameter type that indicates that the
parameter is not evaluated immediately:
sub infix:!! ($lsh, $rhs is deferred) {...}
In this case, it might be possible to make ordinary functions
short-circuit also
sub conditional(bool $condition, $trueCase is deferred, $falseCase is
deferred)
{
return ($condition) ?? $trueCase :: $falseCase;
}
I have no idea how difficult it would be to implement either of these
concepts. Also, if a parameter is deferred, would we need a new keyword to
say when to actually evaluate it?
Joe Gottman
Re: Funding the design team
Thanks to everybody for your patience and support. Here's where things currently stand wrt TPF and funding for Perl 6 related activities: * TPF is now active again. Special thanks to Nat Torkington for being so responsive when I conveyed the list's concerns to him. * An on-line survey of the Perl community will be made available in the very near future. It will be an opportunity for the whole community -- including those of us primarily concerned with Perl 6 -- to offer guidance to TPF as regards funding priorities. * A number of new grants will be announced soon. These will probably include one or more grants targeted at Perl 6 design and/or implementation. * TPF has been keeping a low profile over the last few months but has not been idle. Since last fall, they continued to fund Larry through the end of the year, helped with YAPC::Europe, are in the process of getting the next YAPC::America running, gave a small grant to Dan, and are currently looking at funding some Perl Monks site upgrades. * The issue of accepting donations targeted to a particular area (e.g. Perl 6) has been raised and is being discussed. Once again, as soon as that survey is available, I will inform the mailing list. Damian
Re: Short-circuiting user-defined operators
Joe Gottman wrote:
Alternatively, there might be a new parameter type that indicates that the
parameter is not evaluated immediately:
sub infix:!! ($lsh, $rhs is deferred) {...}
A nice concept! So nice, in fact, that it would be a shame to limit it
to function args. I could see myself writing:
my $a is lazy := expensive_fn1(...);
my $b is lazy := expensive_fn2(...);
print rand ?? $a :: $b;
I'm not sure quite how the syntax would work (should I be binding or
assigning?); but there are definitely cases where this ability is
useful. Given this capability, defered evaluation of function args would
be trivial.
Another, very different, situation where laziness is good is to abstract
fork/join situations:
my $a is lazy_thread := expensive_fn1(...);
my $b is lazy_thread := expensive_fn2(...);
print $a + $b;
In this scenario, each expensive evaluation would be launched as a
separate thread. When the resulting value is later used, then the thread
would be joined, blocking if the thread is not complete.
Re: Short-circuiting user-defined operators
Dave Whipp writes: Another, very different, situation where laziness is good is to abstract fork/join situations: my $a is lazy_thread := expensive_fn1(...); my $b is lazy_thread := expensive_fn2(...); print $a + $b; In this scenario, each expensive evaluation would be launched as a separate thread. When the resulting value is later used, then the thread would be joined, blocking if the thread is not complete. That is gorgeous. Clazy_thread isn't a good name, but it's a marvelous concept. Thanks. Luke
Ruminating RFC 93- alphabet-blind pattern matching
A couple nights ago I read RFC93 as discussed in Apoc. 5 and got
fired up- it reminded me of some ideas from when I was hacking
Henry Spencer's regexp package. How to futher generalize regular
expression input. It's a bit orthoginal- a properly implemented
RFC93 make some difficult things easier- whether it's done as
binding to a sub, or as overloading =~, or whatever.
A very general description of a regular expression, is a program
that seeks a match within a string of letters. In perl4 the string
of letters was a string of bytes, and in perl6 it's a string of
Unicode (most of the time).
It might as well be a string of *anythings*. Binding a match against
a sub is a natural way to get the anythings you want to match. Now,
I'm a newbie to perl6, so be patient with my hacked-up examples below.
They won't work in any language. And, for the first I tweaked RFC93:
When the match is finished, the subroutine would be called one final
time, and passed 1 arguments: a flag set to 1, and a list containing
the unused elements
which I admit is a poor interface- but it lets me write:
# Looking for luck- find a run of 3 numbers divisible by 7 or 13
# sub numerology is simply an interface to an array of integers
sub numerology { $#_ ? shift,unshift @::nums,@_ : splice @::nums,0,@_ }
numerology =~ / ( !($_[0] % 7 and $_[0] % 13) )3 /;
True, it's easy to join integers with spaces and write an equivalent regexp
on the result- but why stringify when you don't have to?
I'm running into trouble here- using ( code ) to match against a single
atom (a number), it should be more character classy. Assertions are
flexible enough to match all sorts of non-letter atoms, can write a grammer
to make it more readable- maybe something like
numerology =~ / divisible(7)divisible(13) 3 /;
Another example. Let's say there's a class that deals with colors. It has
an operator that returns true if two colors look about the same. Given
a list of color objects, is there a regexp to find a rainbow? Even if the
color class doesn't support stringification?
A less fanciful example- scan a sound. A very crude beat-finding regexp-
fetch_sound_frames =~
/ ( # store soundclip (array of frames) in $1
(volume(-40db)50,1500) # quietish section, 50-1500 frames
(volume(-15db)+) # Followed by some loud frame(s)
) # End capture of the first beat
before # Make sure the loud/quiet pattern repeats,
[ # but don't require the exact same frames
volume(-40db)$2.length*.95,$2.length*1.05
volume(-15db)$3.length*.95,$3.length*1.05
]{3}
/
The point I'm trying to make:
A regexp is already able to consume diffent kinds of characters from a
string- :u0, :u1, :u2, :u3- and with RFC93 it can be fed anything a sub
can return. Those things can be characters- or strings- or stringified if
the regexp requires- but if the regexp doesn't have any strings to match
against, don't bother. Let the assertions get the atoms raw.
Plenty of brilliance on this list, I know I'm not brilliant, especially
when drowsy... did some research before posting but if this has been
covered already (or is completely daft) please face me in the right
direction and shoo me along gently.
-y
~
The Moon is New
