John Macdonald:
> [trans]
> If a shorter rule is allowed to match first, then the longer
> rule can be removed from the match set, at least for constant
> string matches.
It is not about the length of the rules, but about the length of the
matches.
If both \s+ and \h+ match the same length, shou
On 15/12/05 23:35, Larry Wall wrote:
On Thu, Dec 15, 2005 at 06:50:19PM +0100, Brad Bowman wrote:
: The "first in order" rule is more flexible, the user can sort their
: arrays to produce the longest input rule, or use another order if that is
: preferred.
What possible use is a user-ordered rul
On Fri, Dec 16, 2005 at 01:29:11PM +0100, Ruud H.G. van Tol wrote:
: John Macdonald:
:
: > [trans]
: > If a shorter rule is allowed to match first, then the longer
: > rule can be removed from the match set, at least for constant
: > string matches.
:
: It is not about the length of the rules, bu
On Fri, Dec 16, 2005 at 09:14:52AM -0800, Larry Wall wrote:
: It would be a useful exercise to write tr/// in terms of s///.
: It occurs to me that it'd be awfully useful to have a kind of hash
: that returns any unmatched key unchanged.
Actually, in this case it's handled by the fact that the nul
--- Rob Kinyon <[EMAIL PROTECTED]> wrote:
> As for the syntactic sugar, I'm not quite sure what should be
> done here. And, with macros, it's not clear that there needs
> to be an authoritative answer. Personally, I'd simply overload
> + for union, - for difference, * for cross-product, / for
> d
Larry Wall:
> Ruud H.G. van Tol:
>> John Macdonald:
>>> [trans]
>>> If a shorter rule is allowed to match first, then the longer
>>> rule can be removed from the match set, at least for constant
>>> string matches.
>>
>> It is not about the length of the rules, but about the length of the
>> match
This is only about transliteration (tr///), not rules in general.
So you are only matching a fixing set of strings at a certain position.
If one string is the prefix of another, the longer is preferred.
If there are two identical match strings, the replacement corresponding
to the first is used.
On Tue, Dec 13, 2005 at 12:42:47PM +0200, Gaal Yahas wrote:
: S11 stipulates:
:
: * modules can decorate exports with tagsets
:
: * module users are the ones who control which imports are allowed,
: and what scoping to give each import. The default is always lexical.
:
: There are a few pieces
On 12/16/05, Ovid <[EMAIL PROTECTED]> wrote:
> --- Rob Kinyon <[EMAIL PROTECTED]> wrote:
>
> > As for the syntactic sugar, I'm not quite sure what should be
> > done here. And, with macros, it's not clear that there needs
> > to be an authoritative answer. Personally, I'd simply overload
> > + for
I agree with just about everything you wrote. I only have two minor
quibbles and they may merely be restatements of what you meant.
--- Rob Kinyon <[EMAIL PROTECTED]> wrote:
> Overriding the operators in a generic way so that you have
> to have an exact type match before you compare values also,
On 12/16/05, Ovid <[EMAIL PROTECTED]> wrote:
> Minor nit: we're discussing to the relational algebra and not the
> relational Calculus (unless the topic changed and I wasn't paying
> attention. I wouldn't be surprised :)
Algebra, in general, is a specific form of calculus. So, we're
speaking of
Something else I've been thinking about, as a tangent to the
relational data models discussion, concerns Perl's concept of
"undef", which I see as being fully equivalent to the relational
model's concept of "null".
The root question of the matter is, what does "undef" mean to you?
To me, it m
Hi,
Overloading undef would be cool. This way Joe Coder can make it act
however he'd like when it's not used in the various contexts or
operations -- string, math, smart ... Basically a pragma (or
something) would define the behavior of all undefs declared within the
given scope. Since each undef
Please scratch that first parahgraph because it's incoherrent and I'm crazy:
Overloading undef would be cool. This way Joe Coder can make it act
however he'd like when it's not used in the various contexts or
operations -- string, math, smart ... Basically we would subclass (something) to
to defi
On 12/16/05, Darren Duncan <[EMAIL PROTECTED]> wrote:
> Something else I've been thinking about, as a tangent to the
> relational data models discussion, concerns Perl's concept of
> "undef", which I see as being fully equivalent to the relational
> model's concept of "null".
The relational model
On Friday 16 December 2005 18:15, Darren Duncan wrote:
> Therefore, I propose that the default behaviour of Perl 6 be changed
> or maintained such that:
>
> 0. An undefined value should never magically change into a defined
> value, at least by default.
This is fairly well at odds with the princi
At 11:57 PM -0500 12/16/05, Rob Kinyon wrote:
How many different undefs are there?
That depends on what exactly you are asking.
1. An undef is what you have when a container contains no explicit
value (or junction/etc thereof).
A variable whose value is undefined is still a typed container;
At 10:07 PM -0800 12/16/05, chromatic wrote:
On Friday 16 December 2005 18:15, Darren Duncan wrote:
> 0. An undefined value should never magically change into a defined
value, at least by default.
This is fairly well at odds with the principle that users shouldn't have to
bear the burden of
18 matches
Mail list logo
