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:
# 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
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
[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
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
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
[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
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
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
--- 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
#
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
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
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,
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
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
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
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
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
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.
*
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:
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
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-
30 matches
Mail list logo
