Luke Palmer wrote:
LP> my $foos = 'foo' ~ any(0..9) ~ any(0..9);
Actually $foos will be a junction. You could use C to get
each state out of the junction in an array.
my @foos = states $foos;
Luke's right on target (as usual :-). Just one slight niggle. I suspect
C may be a method
At 10:37 PM -0700 12/10/02, Luke Palmer wrote:
Why use regexen when you can just use junctions?
my $foos = 'foo' ~ any(0..9) ~ any(0..9);
...
We have a I language on our hands, people.
Agreed, but this solution doesn't work well for all cases. For example,
what if I want to iterate throug
Ken Fox <[EMAIL PROTECTED]> writes:
> Damian Conway wrote:
>> For that reason, even if we can solve this puzzle, it might be far kinder
>> just to enforce parens.
>
> I might be weird, but when I use parens to clarify code in Perl, I
> like to use the Lisp convention:
>
>(method $object args)
> Date: Wed, 11 Dec 2002 19:15:53 +1100
> From: Damian Conway <[EMAIL PROTECTED]>
>
> I suspect C may be a method only, so that would be either:
>
>my @foos = states $foos:;
>
> or:
>
>my @foos = $foos.states;
>
> Though, I suppose we might argue that C is as fundamental to Per
The Perl 6 Summary for the week ending 20021208
Another Monday evening. Another summary to write.
Starting, as is becoming tediously predictable, with perl6-internals.
Another JIT discussion
Toward the end of the previous week, Leopold Tötsch posted something
about the latest ro
[EMAIL PROTECTED] (Damian Conway) writes:
> > *Why* do methods need their parens?
>
> Because calls to them are not resolved until run-time and because methods
> can be overloaded by signature, so we can't tell at parse time what the
> parameter list of the called method will be (i.e. where it wil
On Wed 11 Dec, Simon Cozens quoted:
> No proper program contains an indication which as an operator-applied
> occurrence identifies an operator-defining occurrence which as an
> indication- applied occurrence identifies an indication-defining occurrence
> different from the one identified by the g
On Tue, Dec 10, 2002 at 03:38:58PM -0800, Rich Morin wrote:
> On occasion, I have found it useful to cobble up a "little language"
> that allows me to generate a list of items, using a wild-card or some
> other syntax, as:
>
> foo[0-9][0-9] yields foo00, foo01, ...
>
> I'm wondering whether Pe
How would one most nicely code what I'll call
a lazy pipeline, such that the first result
from the final element of the pipeline can
appear as soon as the first result has been
processed from the intervening elements?
--
ralph
On Mon, Dec 09, 2002 at 03:58:54PM -0700, Luke Palmer wrote:
> > From: Dave Storrs <[EMAIL PROTECTED]>
> > My understanding was that in Perl6, you could use pretty much anything
> > for a hashkey--string, number, object, whatever, and that it did not
> > get mashed down into a string. Did I have t
On Tue, Dec 10, 2002 at 10:37:10PM -0700, Luke Palmer wrote:
> Why use regexen when you can just use junctions?
>
> my $foos = 'foo' ~ any(0..9) ~ any(0..9);
At what moment does a junction actually create all of its states?
Hmm...perhaps a clearer way to say that is "At what moment does a
ju
Piers wrote:
Stringification of references
Joseph F. Ryan kicked off a discussion of the stringification of
objects and references and offered his suggestions. Joseph leans
towards having the default stringifications of objects and references
provide information useful to the programmer. I ag
On Tuesday, December 10, 2002, 1:26:41 PM, you (mailto:[EMAIL PROTECTED]) wrote:
> On 12/10/2002 4:54 AM, Me wrote:
>> How would one most nicely code what I'll call
>> a lazy pipeline, such that the first result
>> from the final element of the pipeline can
>> appear as soon as the first result has
On 12/11/02 1:10 PM, Michael Lazzaro wrote:
> I doggishly maintain my preference for treating "stringification for
> output" and "stringification for debugging" differently, but as long as
> I can specify an "AS_STRING" (sp?) method for a class, and _still_ get
> at a debugging version to print to
On Tuesday, December 10, 2002, at 02:50 PM, Damian Conway wrote:
Simon Cozens asked:
*Why* do methods need their parens?
*All* of them might be valid interpretations, and *none* of them might
be known to be valid (or even knowable) at the point where the code is
parsed. Throw multimethods i
Richard J Cox wrote:
On Tuesday, December 10, 2002, 1:26:41 PM, you (mailto:[EMAIL PROTECTED]) wrote:
On 12/10/2002 4:54 AM, Me wrote:
How would one most nicely code what I'll call
a lazy pipeline, such that the first result
from the final element of the pipeline can
appear as soon as the firs
(BOn Wednesday, December 11, 2002, at 10:36 AM, John Siracusa wrote:
(B> Maybe "AS_STRING" and "AS_STRING_DEBUG"? Too long? "DEBUG_STRING"?
(B> Are we married to the "AS_*" thing?
(B
(BNot really -- whatever works. We also had .debug, .identity, and .id
(Bproposed, for example.
(B
(
> Date: Tue, 10 Dec 2002 08:04:46 -0800
> From: Dave Storrs <[EMAIL PROTECTED]>
>
> On Mon, Dec 09, 2002 at 03:58:54PM -0700, Luke Palmer wrote:
> > > From: Dave Storrs <[EMAIL PROTECTED]>
> > > My understanding was that in Perl6, you could use pretty much anything
> > > for a hashkey--string, num
> Date: Wed, 11 Dec 2002 10:10:05 -0800
> From: Michael Lazzaro <[EMAIL PROTECTED]>
>
> (I also beg people to stop thinking about testing for
> equality/equivalence between two objects as being related to their
> stringification. You shouldn't be stringifying objects merely to test
> if they'r
On 12/11/02 2:04 PM, Michael Lazzaro wrote:
> On Wednesday, December 11, 2002, at 10:36 AM, John Siracusa wrote:
>> Maybe "AS_STRING" and "AS_STRING_DEBUG"? Too long? "DEBUG_STRING"?
>> Are we married to the "AS_*" thing?
>
> Not really -- whatever works. We also had .debug, .identity, and .id
At 10:41 AM -0800 12/11/02, Michael Lazzaro wrote:
How much overhead do we expect (runtime) multimethods to have? I
would guess it to be nontrivial, e.g. substantially worse than
normal methods...
I'd expect a non-trivial overhead to start, declining with time, only
paid when calling methods
On Wednesday, December 11, 2002, at 11:16 AM, Luke Palmer wrote:
This brings up something that's been on the tip of my toungue for
awhile. In many object-oriented languages we have seen that there is
an important difference between "equal" and "same." Perl already has
two kinds of equal, but I
On Wed, Dec 11, 2002 at 02:15:40PM -0800, Michael Lazzaro wrote:
> On Wednesday, December 11, 2002, at 11:16 AM, Luke Palmer wrote:
> >This brings up something that's been on the tip of my toungue for
> >awhile. In many object-oriented languages we have seen that there is
> >an important differen
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote:
> After thinking about it a little more, I'll set myself on the "yes"
> side. And propose either '===' or ':=:' to do it.
Definitely '==='.
This is used in various other languages.
> >$obj1 eq $obj2;# [1] are their stringifications identical?
Michael Lazzaro:
# Piers wrote:
# I doggishly maintain my preference for treating "stringification for
# output" and "stringification for debugging" differently, but
# as long as
# I can specify an "AS_STRING" (sp?) method for a class, and
# _still_ get
# at a debugging version to print to oth
At 2:28 PM -0800 12/11/02, Michael G Schwern wrote:
On Wed, Dec 11, 2002 at 02:15:40PM -0800, Michael Lazzaro wrote:
On Wednesday, December 11, 2002, at 11:16 AM, Luke Palmer wrote:
>This brings up something that's been on the tip of my toungue for
>awhile. In many object-oriented languages
There's no need for special methods or (gods forbid) more operators.
Just:
$obj1.id == $obj2.id
That's what the universal C method is *for*.
Damian
Dave Whipp wrote:
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote:
After thinking about it a little more, I'll set myself on the "yes"
side. And propose either '===' or ':=:' to do it.
Definitely '==='.
I could also see :== or =:= as well.
If we have
$obj1 = $obj2;
then presumably, ($obj1
Michael Lazzaro asked:
All subroutines with multiple signatures would have this problem, right,
even normal non-method subs?
foo $a, $b, $c, $d; # how many args?
Yep. Can't be known unless predeclared and hence compile-time discernible.
And methods can't be discerned in the presence of r
Luke Palmer asked:
Can junctions have methods?
If we decide they can, yes. ;-)
How do you tell the difference between calling a junction's method and
> calling a method on each of its states?
If it's a method of the class Junction (or one of its four subclasses) then it's
a method call on
This is just your friendly neighborhood curmudgeon reminding you that in
Perl 6, everything is an object. This is a concept that, as Perl
programmers, we're not familiar with.
What are the consequences of this in language design? Well, it means not
every new piece of functionality requires a new
Simon Cozens wrote:
*Why* do methods need their parens?
Because calls to them are not resolved until run-time and because methods
can be overloaded by signature, so we can't tell at parse time what the
parameter list of the called method will be (i.e. where it will end),
so we can't determine h
Dave Storrs wrote:
On Tue, Dec 10, 2002 at 10:37:10PM -0700, Luke Palmer wrote:
Why use regexen when you can just use junctions?
my $foos = 'foo' ~ any(0..9) ~ any(0..9);
At what moment does a junction actually create all of its states?
Hmm...perhaps a clearer way to say that is "At what
[EMAIL PROTECTED] (Michael G Schwern) writes:
> If you want a tactile grasp of the "Everything is an object" concept, try
> some Ruby.
If you want a tactile grasp of Perl 6, try some Ruby. But I'll be saying
a lot more on that later...
> A flip through the Ruby builtin methods is nice for buildi
* Damian Conway ([EMAIL PROTECTED]) [12 Dec 2002 10:32]:
[...]
> You underestimate your ability to communicate, Simon. I understood
> exactly what you wanted: pass a closure to a method without needing to
> wrap the closure in parens.
Simon appears to want to have closures as params just like Rub
[EMAIL PROTECTED] (Damian Conway) writes:
> You underestimate your ability to communicate, Simon. I understood
> exactly what you wanted: pass a closure to a method without needing
> to wrap the closure in parens.
Fair enough.
> I was explaining why I think we ought to keep the parens. And that
Damian Conway:
# that determine which method is called. Even if you write:
#
# my Foo $foo;
#
# # and later in the same lexical scope...
#
# $foo.bar();
#
# there's no way at compile time of knowing what class of
# object $foo contains. It could be a Foo object, or it could
[EMAIL PROTECTED] (Iain 'Spoon' Truskett) writes:
> So why does Ruby have so little trouble with it?
Because the Ruby designer(s) don't have fifteen years of Perl experience
muddling up their heads. :)
But seriously, Ruby does something a little tricky here that Perl 6
should probably *not* foll
[EMAIL PROTECTED] (Brent Dax) writes:
> # my Foo $foo;
> #
> # # and later in the same lexical scope...
> #
> # $foo.bar();
> Your point being...? Shouldn't it only dispatch to methods defined in
> Foo?
Are you taking full account of what sort of magic may be performed between
the
Simon Cozens wrote:
I was explaining why I think we ought to keep the parens. And that is
because, without them, we can't tell how many arguments to pass to
the method.
Not if it is specified that a block comes after the final
argument.
The only way that this could be specified is with a sig
Simon Cozens:
# Are you taking full account of what sort of magic may be
# performed between the two statements? :)
#
# Urgh:
# my Foo $foo;
# my Bar $bar;
# $foo := $bar; # Compile-time error?
Eww, gross.
# Also, Foo might change its nature, be replaced, import new
# m
[EMAIL PROTECTED] (Damian Conway) writes:
> But in Perl 6, the consistency between a method's parameter list and its
> argument list *is* checked at run-time, so passing the wrong number of
> arguments is (quite literally) fatal.
But wait! If we can check how many parameters to pass, we know how
m
On 12/11/02 6:16 PM, Damian Conway wrote:
> There's no need for special methods or (gods forbid) more operators.
> Just:
>
>$obj1.id == $obj2.id
>
> That's what the universal C method is *for*.
I must have missed this (or forgotten it?) Any chance of it becoming .ID or
.oid or even ._id? I
"Michael G Schwern" <[EMAIL PROTECTED]> wrote:
> This is just your friendly neighborhood curmudgeon reminding you that in
> Perl 6, everything is an object
> ...
> Instead of introducing new built-in functions they can be done as methods.
The problem with this worldview is that you end up with hor
On Wednesday, December 11, 2002, at 02:54 PM, Dave Whipp wrote:
There's actually a fourth concept: two (different) objects represent
the same value. (Actually, its the generalization of [1] and [2]).
I think that is covered by C<~~>. As long as we can create
class-specific variants of smart
[EMAIL PROTECTED] (Dave Whipp) writes:
> There is a difference between verbs and noun. Sometimes you don't want
> to associate a verb with an object: you want to associate it with the
> subject:
Verbs are almost always associated with their subject in OO languages,
so I don't see where you're comi
[EMAIL PROTECTED] (Michael Lazzaro) writes:
> I think that is covered by C<~~>. As long as we can create
> class-specific variants of smart matching, we're fine.
If we can't, case^Wgiven statements become very boring indeed.
For reference, and purely for reference, Ruby has four object comparato
On Wednesday, December 11, 2002, at 03:27 PM, Michael G Schwern wrote:
There's lots of reasons to use an operator or built-in instead of a
method, but remember to make the consideration first. Don't go
grammar happy.
I agree 98% with your argument (especially re: grammar extensions), and
it
"Simon Cozens" <[EMAIL PROTECTED]> wrote
> Verbs are almost always associated with their subject in OO languages,
> so I don't see where you're coming from.
Actually, the important part of it was the 3rd option (the multimethod):
sometimes the association is symmetrical. I was pointing out that t
On Wed, Dec 11, 2002 at 04:56:03PM -0800, Michael Lazzaro wrote:
> First, universal operators and universal methods both pollute the
> useful (programmer) namespace to nearly the same extent.
Most of the methods are not universal. For example:
$foo.compress
would be in the String class, n
On Wednesday, December 11, 2002, at 05:21 PM, Michael G Schwern wrote:
On Wed, Dec 11, 2002 at 04:56:03PM -0800, Michael Lazzaro wrote:
First, universal operators and universal methods both pollute the
useful (programmer) namespace to nearly the same extent.
Most of the methods are not unive
[EMAIL PROTECTED] (Michael Lazzaro) writes:
> would be a false savings. If a method _is_ universal, especially if
> it's symmetric, it might be an OK candidate for a builtin or operator.
> And if it isn't universal, I can see (almost) no justification for
> wasting an op on it, no matter how commo
> "BD" == Brent Dax <[EMAIL PROTECTED]> writes:
BD> Fine. In Perl 5 we have a restriction on when you can and can't use
BD> parens on a subroutine--you can omit them when the sub is predeclared,
BD> and Perl will assume that no magic is going on. I see nothing wrong
BD> with this rul
> [EMAIL PROTECTED] (Damian Conway) writes:
> > But in Perl 6, the consistency between a method's parameter list and its
> > argument list *is* checked at run-time, so passing the wrong number of
> > arguments is (quite literally) fatal.
> But wait! If we can check how many parameters to pass, we k
[EMAIL PROTECTED] (Deborah Ariel Pickett) writes:
> That works, with one big proviso. You have to have predeclared all
> possible methods in the class to which the object belongs, AND each
> method in that class (and all defined subclasses) has to have a unique
> signature.
No! No, no, no! You're
On Wednesday, December 11, 2002, at 05:39 PM, Simon Cozens wrote:
[EMAIL PROTECTED] (Michael Lazzaro) writes:
would be a false savings. If a method _is_ universal, especially if
it's symmetric, it might be an OK candidate for a builtin or operator.
And if it isn't universal, I can see (almost)
On Wednesday, December 11, 2002, at 06:41 PM, Michael Lazzaro wrote:
print $i; # ILLEGAL; use $STDOUT.print($i) or $i.print (?)
reverse @a; # ILLEGAL; use @a.reverse;
map {...} @a; # ILLEGAL; use @a.map({...});
sort {...} @a; #
keys %h;# ...etc...
(And yes,
[EMAIL PROTECTED] (Michael Lazzaro) writes:
> Wel... yes and no. You can make the same argument for operators
> upon scalars, for example, since 'scalar' is arguably no more
> universal than 'array'. And we could easily use that argument to
> remove *all* builtins, period:
Now you're getting
Uri Guttman:
# BD> Fine. In Perl 5 we have a restriction on when you can
# and can't use
# BD> parens on a subroutine--you can omit them when the sub
# is predeclared,
# BD> and Perl will assume that no magic is going on. I see
# nothing wrong
# BD> with this rule.
#
# but you are con
Simon Cozens wrote:
> [EMAIL PROTECTED] (Deborah Ariel Pickett) writes:
> > That works, with one big proviso. You have to have predeclared all
> > possible methods in the class to which the object belongs, AND each
> > method in that class (and all defined subclasses) has to have a unique
> > sign
[EMAIL PROTECTED] (Deborah Ariel Pickett) writes:
> About this point was when my brain when "a ha!". But I'm not yet
> convinced that generating all possible parses is (a) of sane time
> complexity, and (b) a little *too* DWIM for its own good.
As I said, I wasn't sure whether or not I was being
> As I said, I wasn't sure whether or not I was being serious at this point.
>
> > > > method bar($x, $y) {
> > > > method bar($z) { # note 1
> > > Oh, bringing in multimethods Just Isn't Fair.
> >
> > Those are multimethods? Migod, I feel like a person who's just
> > discovered for t
> "Rich" == Rich Morin <[EMAIL PROTECTED]> writes:
Rich> On occasion, I have found it useful to cobble up a "little language"
Rich> that allows me to generate a list of items, using a wild-card or some
Rich> other syntax, as:
Rich>foo[0-9][0-9] yields foo00, foo01, ...
Rich> I'm wonderi
> "Simon" == Simon Cozens <[EMAIL PROTECTED]> writes:
Simon> [EMAIL PROTECTED] (Damian Conway) writes:
Damian> But in Perl 6, the consistency between a method's parameter
Damian> list and its argument list *is* checked at run-time, so
Damian> passing the wrong number of arguments is (quite li
On Wed, Dec 11, 2002 at 07:08:58PM -0800, Brent Dax wrote:
> But when you know the type beforehand, there shouldn't *be* any
> ambiguity. You can see the methods in that class, and you know how many
> arguments the biggest implementation of a multimethod[1] takes. Just
> assume that that's the on
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Wed, 11 Dec 2002 19:21:35 -0500
> From: John Siracusa <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
>
> On 12/11/02 6:16 PM, Damian Conway wrote:
> > There's no need for
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> X-Sent: 11 Dec 2002 23:16:30 GMT
> Date: Thu, 12 Dec 2002 10:16:26 +1100
> From: Damian Conway <[EMAIL PROTECTED]>
> X-Accept-Language: en, en-us
> X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
>
> There's no need for special m
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> From: "Dave Whipp" <[EMAIL PROTECTED]>
> Date: Wed, 11 Dec 2002 14:54:18 -0800
> Organization: Fast-Chip inc.
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-Newsreader: Microsoft Outlook Express 5.50.4920.2300
> X-MimeOLE: Produced By Micro
At 3:24 AM + 12/12/02, Simon Cozens wrote:
[EMAIL PROTECTED] (Deborah Ariel Pickett) writes:
> Can we dictate that parentheses are optional in this case, and demand
parentheses in all others?
You see, the problem is that if we don't know what method we're going
to call until way after we'
At 9:43 PM -0700 12/11/02, Luke Palmer wrote:
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
X-Sent: 11 Dec 2002 23:16:30 GMT
Date: Thu, 12 Dec 2002 10:16:26 +1100
From: Damian Conway <[EMAIL PROTECTED]>
X-Accept-Language: en, en-us
X-SMTPD: qpsmtpd/0.20, http://develooper.com/code
70 matches
Mail list logo
