Re: RFC 164 (v1) Replace =~, !~, m//, and s/// with match() and subst()

On Mon, Aug 28, 2000 at 08:12:22AM -0700, Nathan Wiger wrote:
> Jonathan Scott Duff wrote:
> > 
> > I think that C<subst> is too syntactically close yet semantically far
> > from C<substr> that the evil demons of confusion will rear their ugly
> > heads.
> 
> I agree too, any suggestions are welcome. The fact that 'sub' and
> 'substr' are already taken makes this tough...

Well, if s/// stays around, I imagine that's what people will use, so
we could call the function form C<substitute>.  Only those weirdos
using the function form would have to pay the syntactic penalty.  ;-)

> > Given the above, why not make a bare C<subst> do something equally
> > useful?  Here are some ideas:
> > 
> >         subst;          # removes leading and trailing whitespace
> 
> I like this one alot.

Me too.  I put down the others to give people brain-food mostly  :-)

But again, this doesn't seem to make much sense in what I would think
would be its common use (using the spelled out version):

	while (<>) {
	    substitute;		# What the hell am I substituting?
	    ...
	}

Similarly with match:

	while (<>) {
	    next unless match;	# Er, match *what*?
	    ...
	}

Both leave me hanging.  I can't read Perl in english like I'm used to.


> > I wonder what happens when people start typing
> > 
> >         $new = subst s/old/new/i, $old;
> 
> They get a syntax error! :-)
> 
> Honestly, I don't think that's a big problem. People don't do this with
> split() now. I think people will either use the "backwards compat" s///
> form or the function form.

But they might *accidentally* use both.  I'd prefer that Perl ... you
guessed it ... DWIM here.  I.e., 

	$new = substitute s/old/new/i, $old;

would be equivalent to

	$new = substitute /old/new/i, $old;

With a warning if they're turned on.  Same for match.  

Hmm.  Does using the function form still give the ability to pick
delimiters?  And what does *this* mean:

	@stuff = split match /foo/, $string;

?

-Scott
-- 
Jonathan Scott Duff
[email protected]