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-
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
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 woul
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:
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
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 im
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.
Paul writes:
> My P6 syntax is still weak, though. Maybe
>
> given big_calc() { return $_ if $_ }
Using C works in Perl 5. Is there anything preventing this working
in Perl 6:
for big_calc() { return $_ if $_ }
Smylers
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
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 :
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
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
> 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 C or C, 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
--- 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
--- 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, C is too heavily
> > # overloaded. As it stands, it means 3 things:
> > #
> > # (1) Attributing traits
> > # (2) Inheriting base
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
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 th
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:
> # Now, I don't know what Larry has up his sleeve in this
> # respect, but as I see it now, C is too heavily
> # overloaded. As it stands, it means 3 things:
> #
> # (1) Attributing traits
> # (2) Inheriting base classes
> # (3) "Tying" variables
> #
> # Depending o
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
[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 a
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:
# Now, I don't know what Larry has up his sleeve in this
# respect, but as I see it now, C 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 imp
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
39 matches
Mail list logo
