Re: study

[Nicholas Clark]

On Sun, Mar 20, 2005 at 10:54:15PM -0700, Luke Palmer wrote:

 in the same form if it does come back.  So consider 6.0 its usage
 deprecation cycle, so we can redefine its meaning (if we decide to).

I don't see why study needs a deprecation cycle when length doesn't get one.
It seems fair game to me that (some) things can change disjointly in Perl 6

(providing that not too many things change such that the language is no
longer perl. Which I don't think is happening, and if you do think it's
happening, there's still always going to be perl 5 for you to use)

Also it sounds like study fits much better as a method on a scalar, rather
than a function in *::

Nicholas Clark

Re: study

[Luke Palmer]

Nicholas Clark writes:
 On Sun, Mar 20, 2005 at 10:54:15PM -0700, Luke Palmer wrote:
 
  in the same form if it does come back.  So consider 6.0 its usage
  deprecation cycle, so we can redefine its meaning (if we decide to).
 
 I don't see why study needs a deprecation cycle when length doesn't get one.
 It seems fair game to me that (some) things can change disjointly in Perl 6

Sorry.  I misspoke (My brain forgot what a deprecation cycle does).
`study` should not be in 6.0.

Luke

study

[Rod Adams]

Cstudy is an odd sort of function. AFAIK, it's the only optimization 
hint that we have.

Will the P6RE even use this information, and is it worth keeping?
My gut feeling tells me that it will be useful again around 6.2, and we 
should keep it around until then as a potential no-op.

Comments?
-- Rod Adams

Re: study

[Luke Palmer]

Rod Adams writes:
 Cstudy is an odd sort of function. AFAIK, it's the only optimization 
 hint that we have.
 
 Will the P6RE even use this information, and is it worth keeping?
 
 My gut feeling tells me that it will be useful again around 6.2, and we 
 should keep it around until then as a potential no-op.

Ummm... yeah, keep a function around if it's not currently implemented.
I don't think so.  

When we do implement it, we can put it in as a method on Str.

$string.=study;

Luke

Re: study

[Luke Palmer]

Rod Adams writes:
 Luke Palmer wrote:
 Ummm... yeah, keep a function around if it's not currently implemented.
 I don't think so.  
  
 I see that as preferable to saying we had it in 5.10, we dropped it in 
 6.0, then added it back in for 6.2.

Umm... your statement isn't quite so shocking when you s/6\.0/6.0
along with everything else/.  However, I don't think added it back
would be true either, because it's very unlikely that it would come back
in the same form if it does come back.  So consider 6.0 its usage
deprecation cycle, so we can redefine its meaning (if we decide to).

Luke

RFC: extend study to produce a fast grep through many regexes

[David L. Nicol]

title: study a list of regexes
David Nicol.
Aug 21
version 1
[EMAIL PROTECTED]


Sometimes I have a group of regexen, and I would like to know
which ones will match.

Current practice is to "study" $situation and then grep them:


example a:

    study $situation;
@matches = @rules{ grep {$situation =~ m/$_/} keys %rules};


What if there were a faster way to do this, a way to Cstudy a
group of regexes and have the computer determine which ones had
parts in common, so that if $situation =~ m/^foo/ is true, the
fifty rules that start ^bar don't waste any time.  At all.

example b:

$matchcode = study @regexen;

will generate an anonymous subroutine (it's called $matchcode in
the example line) with a tree based on required parts of the
regexes, to minimize the number of match attempts to determine
which regexes will match.  The subroutine will take an array
argument and will return the subset of the rules (as stated in
the original array, either string or compiled qr// references)
that match on all the arguments.

The code in example a could then be replaced

$matchcode = study keys %rules;
@matches = @rules{ $matchcode $situation }


This ability could speed "dirty matching" which currently cannot
take advantage of constant-time hash lookups without standardizing
the dirty parts.




-- 
  David Nicol 816.235.1187 [EMAIL PROTECTED]
  Does despair.com sell a discordian calendar?

Re: RFC: extend study to produce a fast grep through many regexes

[Larry Wall]

David L. Nicol writes:
: What if there were a faster way to do this, a way to Cstudy a
: group of regexes and have the computer determine which ones had
: parts in common, so that if $situation =~ m/^foo/ is true, the
: fifty rules that start ^bar don't waste any time.  At all.

Perl 4 did this sort of thing automatically without a study, at least
with respect to the first character that could match.  Of course, it
didn't do it with regular expressions in an array, but rather in
a "switch" structure.  And you had to bunch your tests right.  If
your regular expressions were in an array, you had to use eval.

So certainly there's room for an interface that can take multiple regex
objects and turn them into a single super regex.  I don't think the
code to do it necessarily belongs in the core, but it would certainly
have to be somewhat incestuous with regex innards.

Larry