NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/lang/perl/7415

Internet Message Format | 1992-12-14 | 2.5 KB

Path: sparky!uunet!paladin.american.edu!europa.asd.contel.com!emory!swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!olivea!sgigate!sgi!wdl1!wdl39!mab
From: [e-mail] (Mark A Biggar)
Newsgroups: comp.lang.perl
Subject: Re: In 5.0, are we gonna get...
Message-ID: <[e-mail]>
Date: 14 Dec 92 19:20:07 GMT
References: <[e-mail]>
Sender: [e-mail]
Organization: Loral Western Development Labs
Lines: 50

In article <[e-mail]> [e-mail] (Mark Jefferys) writes:
>Will we see:
>
>1) an equivalent of lisp's mapcar?  For an instance:
>
>    map(/(\d+)/, "asdf 23fjk4", "qwerty", "123 ")
>
>   would return ("23", "4", "123").

Easily constructed using grep:

        grep((/(\d+)/,$_=$1), "asdf 23jfk4", "qwerty", "123 ")

produces ("23", "123") (Even lisp's mapcar only applies the function once per
sequence item.)  Larry has talked about adding a 'reduce' operator that
calls a special sort like function (used $a,$b for arg passing) on each element
of a list for doing summations like so:

    $sum = reduce {$a+$b} 1,34,$x,45,-8,0.1;
>
>2) a way of only matching the real beginning/end of a *string* in a
>   regexp?  Currently, '^' and '$' match the beginning and ending of
>   a line (with simplifying assumptions when $* == 0).  A string match
>   would ignore newlines and $*.
>
>   A new option on pattern matches might do it:  `/^\d+$/s' might match
>   "23", but not "23\n" or "x\n45".  The option should treat `.' as
>   matching "\n", as well as every other character -- so the option
>   means that "\n" should not be treated specially.

I believe that ^ at the beginning of a pattern will only match the beginning
of a string and $ at the end only the end, $* has effect only on embedded
^ and $ in the middle of a pattern.
>
>3) a pure grouping operator in pattern matches.  Normally, `/Type:
>   (\d+|[a-zA-Z])/' will return an element containing the
>   `\d+|[a-zA-Z]' (in an array context), and assign $1 to the pattern.
>   If this isn't wanted, it will only slow perl down, and possibly
>   make life confusing if the pattern is very complex.  One that
>   doesn't try to save its contents would be nice.

Larry and I have also talked about this, possibly using < > as the grouping
chars, as well as **, ++, and {n-m} which would be minimal length matching
versions of the current maximal length matching *, + and {n,m} and possibly
a prolog like cut operator (!?) to limit backtracking in patterns.

--
Perl's Maternal Uncle
Mark Biggar
[e-mail]