Trey Harris wrote:
> A more practical application would be:
>
> my $foo;
> # Code which might or might not set $foo...
> $foo //= 23;
> # or
> $foo is default(23);
>
> In such a case, the C just looks plain odd to me.
It is. More than that, it's plain wrong. C properties are
compil
Aaron Sherman:
# Ok, so without knowing what the XS-replacement will look like
# and without knowing what we're doing with
# filehandle-functions (is tell() staying or does it get
# removed in favor of $fh.tell()) and a whole lot of other
I think that sort of thing is going. IIRC, the only b
> sub hidden (str $name, int $force is aka($override))
>{ ... }
I know that the property syntax is pseudo established,
but I'm beggining to become a bit jaded about all the
built in properties were building. What about good ol'
aliases?
sub hidden (str $name, int $force := $override)
{
Oh, BTW: Lest anyone think I'm spamming p6l for no reason, I sent the
Builtins.p6m to p6l instead of p6i because I consider this a document,
not code. When some of the questions get ironed out about the language,
then I will talk to p6i about next steps.
Ok, so without knowing what the XS-replacement will look like and
without knowing what we're doing with filehandle-functions (is tell()
staying or does it get removed in favor of $fh.tell()) and a whole lot
of other stuff it's impossible to translate all of the Perl 5 functions
to Perl 6. However,
Somewhere, in another thread . . .
Dr. Claw wrote . . .
>> sub hidden (str $name, int $force is aka($override))
>>{ ... }
>
>Yeah, that's what I meant.
Is it just me or is the 'is' property syntax a little
too intuitive? Seems like everywhere I turn, the
proposed syntax to solve a problem
David Whipp wrote:
> But can I use a non-constant date?
You didn't show us the iso_date rule.
> Obviously we could put the onus on the module writer to write super-flexible
> rules/grammars. But will there be an easy way to force interpolative context
> onto this type of regex-valued subroutine
Dan Sugalski wrote:
> At 9:10 AM -0400 9/4/02, [EMAIL PROTECTED] wrote:
>> So, just to clarify, does that mean that multi-dispatch is (by
>> definition)
>> a run-time thing, and overloading is (by def) a compile time thing?
>
> No. They can be both compile time things or runtime things, dependin
> Again, it would be nice to be able to flag these to the compiler in a
> rule:
> rule thrice :count { <={.count < 4}> }
> / a? /
> Note that the C would cause the thrice count-rule to be matched
> non-greedily because the regex parser knows that it's a count, not a
> generic rule.
Going
On Wed, Sep 04, 2002 at 10:25:39PM +, Damian Conway wrote:
> Jonathan Scott Duff wrote:
>
> > It seems odd to require two syntactic elements to achieve one semantic.
> > And actually, after looking at A5, that's not what Larry wrote:
> >
> > my $x;
> > / (\S*) { let $
On Wed, Sep 04, 2002 at 10:34:23PM +, Damian Conway wrote:
> Trey Harris wrote:
> > It should. I think everyone has been proceeding under the assumption that
> > they are. If you use a variable name already defined, then you set both
> > the match object's attribute of the same name (minus t
In a message dated Wed, 4 Sep 2002, Andrew Wilson writes:
> On Wed, Sep 04, 2002 at 03:48:41PM -0500, Jonathan Scott Duff wrote:
> > On Wed, Sep 04, 2002 at 04:43:25PM -0400, [EMAIL PROTECTED] wrote:
> > > Only augment //= in subroutine declarations, //= would also work.
> > > I love the //= oper
On Wed, Sep 04, 2002 at 03:48:41PM -0500, Jonathan Scott Duff wrote:
> On Wed, Sep 04, 2002 at 04:43:25PM -0400, [EMAIL PROTECTED] wrote:
> > Only augment //= in subroutine declarations, //= would also work.
> > I love the //= operator, but in the context of sub declarations it's
> > confusing as
Trey Harris wrote:
>>So, each time I use a hypothetical, I have to be concious of which
>>variables are currently in scope? Perl can't help be with this task
>>because how does it know if I meant to hypothetically clobber that
>>lexical or store something in the match object. This is only reall
Dan Sugalski wrote:
>> Dan, can you explain what "multimethod dispatch" is?
>
> Damian can explain it better than I can,
I thought you did a great job!
However, anyone who wants to know more about multiple dispatch
might also like to read:
http://www.samag.com/documents/s=1274/sam050
In a message dated Wed, 4 Sep 2002, Jonathan Scott Duff writes:
> The thread on hypotheticals has caused me to reread that section of A5 a
> few times now and a couple of paragraphs bother me the more I read
> them. I'll just quote the parts that bother me:
>
> ... If a regex sets a hypo
On Wed, Sep 04, 2002 at 05:06:32PM -0400, [EMAIL PROTECTED] wrote:
> Is there a general rule that a property must make sense in all contexts?
Nah, I was just being distracted by work and not thinking clearly
about your default() proposal. :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Jonathan Scott Duff wrote:
> It seems odd to require two syntactic elements to achieve one semantic.
> And actually, after looking at A5, that's not what Larry wrote:
>
> my $x;
> / (\S*) { let $x = .pos } \s* foo /
A typo, I believe. He has been very consistent in d
The thread on hypotheticals has caused me to reread that section of A5 a
few times now and a couple of paragraphs bother me the more I read
them. I'll just quote the parts that bother me:
... If a regex sets a hypothetical variable that was declared
with either my or our beforeha
[EMAIL PROTECTED] wrote:
>> sub hidden (str $name, int $force, int $override is aka($force))
>> { ... }
>
>
> Would the following be simpler...?
>
> sub hidden (str $name, int $force is aka($override))
>{ ... }
Yeah, that's what I meant.
Sorry. I've travelled 14,000 miles and given 93
From: Jonathan Scott Duff [EMAIL PROTECTED]
> Oh. You want default() to be synonymous with //= but only in
> subroutine declarations. That seems a tad odd. Why not make it
> synonymous everywhere?
>
> my $foo is default(23); # same as ...
> my $foo //= 23;
Well, for "is default" to DWIM i
On Wed, Sep 04, 2002 at 04:43:25PM -0400, [EMAIL PROTECTED] wrote:
> Only augment //= in subroutine declarations, //= would also work.
> I love the //= operator, but in the context of sub declarations it's
> confusing as the *only* way to default an argument.
Oh. You want default() to be synon
From: Jonathan Scott Duff [EMAIL PROTECTED]
> Or are you proposing to *only* replace //=? Or are you
> proposing to *only* replace //= in subroutine declarations?
Only augment //= in subroutine declarations, //= would also work.
> What issues did you have with //=? It seems clear and concis
On Wed, Sep 04, 2002 at 04:01:50PM -0400, [EMAIL PROTECTED] wrote:
> It was settled a while ago that sub arguments would be defaulted like this:
>
> sub load_data ($version / /=1) {...}
>
> (The space between / and / is on purpose, my emailer has problems if they
> are together) I and a few
On Wed, 2002-09-04 at 07:28, Damian Conway wrote:
> Aaron Sherman wrote:
>
> > Hmm... I had not thought of the copy aspect. Certainly, the code version
> > is more flexible. You could define C<$x> above as anything. For example:
> >
> > / (gr\w+) {let $x = Gr_Thing.new($1)} /
> >
> > Th
It was settled a while ago that sub arguments would be defaulted like this:
sub load_data ($version / /=1) {...}
(The space between / and / is on purpose, my emailer has problems if they
are together) I and a few others had issues with the slash-slash-equals
thing, but were unable to persuad
On Wed, 2002-09-04 at 14:38, Jonathan Scott Duff wrote:
> my $x;
> / (\S*) { let $x = .pos } \s* foo /
>
> After this pattern, $x will be set to the ending position of
> $1--but only if the pattern succeeds. If it fails, $x is
> restored to und
In Perl5, I might write:
sub set_date {
my ($self, $date) = @_;
$date =~ /(\d{4})-(\d{2})-(\d{2})/ or croak "bad date format";
@$self{qw/year month day/} = ($1,$2,$3);
}
I could then call:
$foo->set_date('2002-09-04')
In Perl6 I can write:
sub set_date ( $date is rx/
On Wed, Sep 04, 2002 at 11:27:46AM +, Damian Conway wrote:
> This is not what Larry has said previously. He said that only
> binding can be used with C variables and that only C
> variable assignments are undone on backtracking.
It seems odd to require two syntactic elements to achieve one se
On Wed, 2002-09-04 at 12:41, Luke Palmer wrote:
> Aaron Sherman wrote:
> > So, for example here are some translations of existing operators:
> >
> > + <={.count > 0}>
> > * <={1}>
> > *? <={1}>?
> > <8> <={.count == 8}># No optimization possible!
>
>
From: Damian Conway [EMAIL PROTECTED]
> If it were allowed, it would probably be done
> via properties instead:
>
> sub hidden (str $name, int $force, int $override is aka($force))
>{ ... }
How does this method affect the non-parameter-based calling scheme? It
looks like it is possible to
From: Damian Conway [EMAIL PROTECTED]
> If it were allowed, it would probably be done
> via properties instead:
>
> sub hidden (str $name, int $force, int $override is aka($force))
>{ ... }
Would the following be simpler...?
sub hidden (str $name, int $force is aka($override))
{ ... }
Peter Behroozi wrote:
> Has anyone considered a syntax for allowing subroutines to have many
> different names for the same argument?
If it were allowed, it would probably be done via properties instead:
sub hidden (str $name, int $force, int $override is aka($force)) { ... }
Damian
Jonathan Scott Duff wrote:
> How can you be sure that is
> implemented as a character class instead of being some other arbitrary
> rule? An answer is that perl should know how these things are
> implemented and if you try arithmetic on something that's not a
> character class, it should carp a
Aaron Sherman wrote:
> Hmm... I had not thought of the copy aspect. Certainly, the code version
> is more flexible. You could define C<$x> above as anything. For example:
>
> / (gr\w+) {let $x = Gr_Thing.new($1)} /
>
> The binding version is just a simple, fast version of one special ca
Ken Fox wrote:
>> / $x := (gr\w+) /vs/ (gr\w+) { let $x = $1 } /
>>
>>Shouldn't they both use C< := > ?
They should. The second version is a typo. It should be:
/ (gr\w+) { let $x := $1 } /
> Depends on what you want. The "$x :=" in the rule
Aaron Sherman wrote:
> So, for example here are some translations of existing operators:
>
> + <={.count > 0}>
> * <={1}>
> *?<={1}>?
> <8> <={.count == 8}># No optimization possible!
Could it be done this way?:
@c:=(.)* <( @c == 8 )>
Surely ineffi
On Wed, 2002-09-04 at 09:55, Markus Laire wrote:
> On 4 Sep 2002 at 0:22, Aaron Sherman wrote:
>
> > On Wed, 2002-09-04 at 00:01, Sean O'Rourke wrote:
> >
> > > None, I think. Of course, if we ignore internals, there's no
> > > difference bewteen that and "rx / | 1 | 7/".
> >
> > Then, why is
The specific definitions of these terms vary from language to
language. In Java, for instance, a method is said to be
"overloaded" and/or "overridden".
An "overloaded" method is actually two or more methods with the
same name but differing numbers/types of parameters (which Java
calls the "signa
At 8:03 AM -0700 9/4/02, Erik Steven Harrison wrote:
>
>--
>
>On Wed, 4 Sep 2002 07:45:37
> Sean O'Rourke obviated:
>To me a language's grammar, once
>>defined, shouldn't do a lot of changing, internally or otherwise. When
>>was the last time C's grammar changed? Or even gcc's implementation
Just some thoughts (and an idea):
I have found the whole context thing in Perl5 easier to understand when I regard it as
overloading based on the return type. We all know that languages like C, C++ and Java
throw a compile-time error if two function
definitions differ in their return type only
On Wed, 2002-09-04 at 00:22, Aaron Sherman wrote:
> Then, why is there a C<+>? Why not make it C<|>?
>
> $foo = rx/ <||[cde]>|f /
This brings to mind a few big things that have been batting around in my
head about user-defined rules for a while now These things fall out
nicely from A5
--
On Wed, 4 Sep 2002 07:45:37
Sean O'Rourke obviated:
To me a language's grammar, once
>defined, shouldn't do a lot of changing, internally or otherwise. When
>was the last time C's grammar changed? Or even gcc's implementation of
>it?
Granted . . .mostly. Were talking about Perl, the
On Wed, 4 Sep 2002, Erik Steven Harrison wrote:
> How are we planning on dealing with this, or do the
> implementers consider it a non issue?
Well, to me this is a non-Yet issue, but a very real issue. I'm hoping
that when Perl 6 goes 1.0, the grammar will have seen a lot of testing,
and will be
At 7:31 AM -0700 9/4/02, David Wheeler wrote:
>On Wednesday, September 4, 2002, at 06:58 AM, Dan Sugalski wrote:
>
>>No. They can be both compile time things or runtime things,
>>depending on the characteristics of the language.
>
>So if it's compile-time for a given language, how is it differen
It seems to me that what I mostly do is wave my arms
about my head with a concern and then stay silent
whenever praise is required. Everyone - consider
yourselves praised :-)
On to the concern (which I am fairly confident someone
will obviate). I've never touched the Perl internals
(and P5P
On Wednesday, September 4, 2002, at 06:58 AM, Dan Sugalski wrote:
> No. They can be both compile time things or runtime things, depending
> on the characteristics of the language.
So if it's compile-time for a given language, how is it different from
the Java concept of overloading?
And will
At 9:10 AM -0400 9/4/02, [EMAIL PROTECTED] wrote:
>
>From: Ken Fox [EMAIL PROTECTED]
>> Over loading is what C++ has. It is not the same as
>> multi-dispatch. The trouble with over loading is that the
>> compiler uses static (compile-time) type information to
>> select the over loaded method.
From: Peter Behroozi [EMAIL PROTECTED]
> Has anyone considered a syntax for allowing
> subroutines to have many different names for
> the same argument? For example, in CGI.pm, many
> methods support the "-override" parameter but
> can also accept the alias of "-force":
Yes. See the thread start
On 4 Sep 2002 at 0:22, Aaron Sherman wrote:
> On Wed, 2002-09-04 at 00:01, Sean O'Rourke wrote:
>
> > None, I think. Of course, if we ignore internals, there's no
> > difference bewteen that and "rx / | 1 | 7/".
>
> Then, why is there a C<+>? Why not make it C<|>?
>
> $foo = rx/ <||[cde
From: Ken Fox [EMAIL PROTECTED]
> Over loading is what C++ has. It is not the same as
> multi-dispatch. The trouble with over loading is that the
> compiler uses static (compile-time) type information to
> select the over loaded method. This can create subtle
> bugs when people try to re-use code
David Wheeler wrote:
> Ah, yes, the same thing exists in Java. I remember, now.
I thought Java only has over loading?
Over loading is what C++ has. It is not the same as
multi-dispatch. The trouble with over loading is that the
compiler uses static (compile-time) type information to
select the o
On Tue, 2002-09-03 at 23:57, Luke Palmer wrote:
> On Tue, 3 Sep 2002, Brent Dax wrote:
> >
> > How can you be sure that is implemented as a character
> > class, as opposed to (say) an alternation?
>
> What's the difference? :)
>
> Neglecting internals, semantically what I the difference?
>
O
53 matches
Mail list logo
