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 roundascii is implemented as a character
class, as opposed to (say) an alternation?
What's the difference? :)
Neglecting internals, semantically what Iis the difference?
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
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 by
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 /roundascii | 1 | 7/.
Then, why is there a C+? Why not make it C|?
$foo = rx/ a|b|[cde]|f
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 starting at
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. This can
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
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
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 different
from
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
--
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, 2002-09-04 at 00:22, Aaron Sherman wrote:
Then, why is there a C+? Why not make it C|?
$foo = rx/ a|b|[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, I
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
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 of
it?
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 signature
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 /roundascii | 1 | 7/.
Then, why is there a
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 inefficient, but it works
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 binds the
Jonathan Scott Duff wrote:
How can you be sure that roundascii 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
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
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))
{ ... }
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 use
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!
Could it be done this
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 Clet variables and that only Clet
variable assignments are undone on backtracking.
It seems odd to require two syntactic elements to achieve
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 undef
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
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)} /
The binding
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
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 concise
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
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 in a
[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 hours of
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
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
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]
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
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:
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 really a
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 the
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 //= operator,
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 the
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 $x = .pos }
Again, it would be nice to be able to flag these to the compiler in a
rule:
rule thrice :count { ={.count 4} }
/ athrice? /
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
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
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 is
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.
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.
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)
{ .
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
49 matches
Mail list logo
