study

[Rod Adams]

C<study> 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

[Luke Palmer]

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

[Rod Adams]

Luke Palmer wrote:

>Rod Adams writes:
>
>
>>C<study> 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.
>
>

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."

Imagine the guy who has a case where it makes a huge difference, and in
porting his code, he wants to make it where when C<study> works again...
he uses it. But until then, he has a no-op to hold it's place.

I wouldn't suggest this if C<study> actually changed semantics in any
way. Semantically, it already is a no-op. Removing it makes no
difference to your output, only in how fast patterns are matched.

-- Rod Adams

[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

[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

[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

[Galion Public Library]

One advantage of keeping study is that it would facilitate the
inevitable Perl6 port of Black Perl. HTH.HAND.