ive oft wondered how a constant/parameter namespace could be designed to:
- lighten Exporter symbol export in perl 5
- expose (for example) POSIX constants in only the contexts where
theyre meaningful
within a POSIX call - ex various c-open flags (im too lazy
to cite any
On Sat, 17 August 2002, Nicholas Clark wrote:
But how on earth would you implement such a thing? :-)
I imagine that type specifiers require that values assigned to
the corresponding variable satisfy: value.isa(type). Using a
superposition as a type means that the result of that test comes
Aaron Sherman wrote:
So,
my all(str, int) $foo = $!;
would be fine?
I'd expect so.
I'm forgetting what has been said about $!
Typically contains an object with both string and integer conversions.
Whether convertability to both types is enough to satisfy a
superpositional type
In a message dated Sat, 17 Aug 2002, [EMAIL PROTECTED] writes:
[$!] Typically contains an object with both string and integer
conversions. Whether convertability to both types is enough to satisfy a
superpositional type is an interesting question. I suspect it *is*.
Then I'd assume that
Hello All,
After reading over Apocalypse 5 one more time, I noticed that balanced
matches (like capturing nested parenthetical comments ((like this))) had
been glossed over in the rejection of RFC 145. What was not even
mentioned in the rejection was the possibility of balanced expressions
that
Peter Behroozi:
# After reading over Apocalypse 5 one more time, I noticed that
# balanced matches (like capturing nested parenthetical
# comments ((like this))) had been glossed over in the
# rejection of RFC 145. What was not even mentioned in the
rule parenthesized { \( ( -[()] |
On Sat, 17 Aug 2002, Brent Dax wrote:
: Peter Behroozi:
: # After reading over Apocalypse 5 one more time, I noticed that
: # balanced matches (like capturing nested parenthetical
: # comments ((like this))) had been glossed over in the
: # rejection of RFC 145. What was not even mentioned in
Larry Wall:
# That being said, there may well be a builtin self rule that
# refers to the current rule without having to name it. That
# lets you write anonymous recursive rules, or possibly a
# generic rule that could have more than one name.
I suspected as much, but didn't use it to avoid
On Sat, 2002-08-17 at 14:31, Brent Dax wrote:
Peter Behroozi:
# After reading over Apocalypse 5 one more time, I noticed that
# balanced matches (like capturing nested parenthetical
# comments ((like this))) had been glossed over in the
# rejection of RFC 145. What was not even mentioned
I've uploaded a new version of my Perl6::Parameters module. This is
mostly just a make it compile version; its design is out of sync with
the current Perl 6 design, a problem I'll resolve in the next version.
It should be bouncing around between mirrors right now, so it may be up
to a day
On 17 Aug 2002, Peter Behroozi wrote:
: However, since you forced me to read through A5 again, I now have
: another question :). Since we can now do
:
: $string.tr %hash;
:
: what happens when the keys of %hash have overlapping ranges by accident
: or otherwise? Are there any other options
Somewhat random question here:
We all know how to alias things in Perl 5. The binding operator allows aliasing in
Perl 6, I understand. So, how do we alias grammer rules? Here are my guesses.
Rules live in the same namespace as subroutines, so you can use the . Or possibly
(because
12 matches
Mail list logo
