home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / perl / 7029 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  5.1 KB
  1. Path: sparky!uunet!caen!sol.ctr.columbia.edu!news.cs.columbia.edu!mail
  2. Newsgroups: comp.lang.perl
  3. Date: Tue, 17 Nov 92 23:06:32 EST
  4. From: thayer@cs.columbia.edu (Charles Thayer)
  5. Message-ID: <9211180406.AA03308@cs.columbia.edu>
  6. Subject: Re: Partial RegExp's
  7. References: <1992Nov12.003038.18617@netlabs.com>
  8.     <BxGFIy.LuA@news.cso.uiuc.edu>
  9. Lines: 105
  10.  
  11. lwall writes:
  12.   chappell@math.uiuc.edu (Glenn Chappell) writes:
  13.   : Here's a question I've been pondering for a few weeks:
  14.   : 
  15.   : Inherent in the design of Perl seems to be the idea that you always have
  16.   : enough space in memory for the entirety of any file you'd ever want to
  17.   : work on. But what if you don't? How does one do wonderful things like
  18.   : "split" and various pattern matches & such on files that are just too big?
  19.  
  20. Yes, I know what you mean.  For me it is very tempting to read in a whole
  21. file, split on white space, then unshift to get tokens.  Which is silly
  22. unless you are looking to match disparate token sequences, such as across
  23. line boundaries or deep in a parse.
  24.  
  25.   : Well, if there's already a standard, ok-I'll-spell-it-all-out-for-a-
  26.   : neophyte-like-you-but-next-time-read-the-book-okay answer to this
  27.   : question, I'd like to hear it. If, not, an idea:
  28.  
  29. Not really, but there are the usual ways to break up input.
  30.  
  31.   : Of course, the way you deal with huge files is to read them in chunks.
  32.   : The problem with that is that you miss a pattern match that starts on
  33.   : one chunk and ends on another.
  34.   : 
  35.   : Currently, the result of an attempt at a pattern match gives one of two
  36.   : responses: "Got a match" or "Didn't get a match". What if there were a
  37.   : way to tell the pattern matcher that some patterns may extend off the
  38.   : end of the currently available text, and we gave the matcher the ability
  39.   : to give two other reponses: "Got a partial match, and if you give me
  40.   : more data, I may get a match" and "Got a match, which may turn into a
  41.   : bigger match if you give me more data". The matcher would also return
  42.   : the place at which the partial match began.
  43.  
  44. A better solution would probably be to write a fsm package (finite-state
  45. machine) or more specifically a little parser package.  Which reminds me,
  46. someone (jeffrey@netcom.com) did recently post a package called marpa. 
  47. Although I haven't used it, the author describes it as a "prototype of
  48. a hacker's parser for perl."
  49.  
  50.   : Now, from what I know of pattern matching, it seems to me that this would
  51.   : be an easy modification to do. The question, then, is whether it would
  52.   : be worthwhile. So, does anyone think so? Or is it just me?
  53.  
  54. If that is your specific goal then you may want to do something
  55. simpler, such as breaking your expression into two (if you know where
  56. you can expect boundaries.)  Let's say you'd like to replace "foo bar"
  57. with "moo man" across whitespace boundaries:
  58.  
  59. #!/bin/perl
  60. $reg1='foo';
  61. $reg2='bar';
  62.  
  63. &prog while(<>);
  64.  
  65. sub prog {
  66.     if ($_ =~ /$reg1/) {
  67.     $_ .= <>;
  68.     s/$reg1([ \t\n]+)$reg2/moo\1man/g;
  69.     &prog;
  70.     } else { print; }
  71. }
  72.  
  73. [damn, there I go recursing again.  If it's not an eval its recursion]
  74.    
  75.   lw> This is one of the reasons that Mark and I have been talking about
  76.   lw> variants of *, + and {} that would match the shortest string
  77.   lw> possible.  Currently there are only two ways to do first-match
  78.   lw> rather than last-match: 1) have the thing you're looking for be the
  79.   lw> first thing in a pattern, or 2) carefully write the intermediate
  80.   lw> stuff to exclude the pattern you're looking for.  Both of these
  81.   lw> approaches leave something to be desired.
  82.  
  83.   lw> A thing that might help with option 1 is if we attached the state
  84.   lw> of m//g searches to the searched string rather than to the pattern
  85.   lw> itself.  This would let you switch from one pattern to another in
  86.   lw> mid search.  One could then do tokenizing without s///, for
  87.   lw> instance.  Of course, that doesn't help the
  88.   lw> slurp-in-more-file-if-you-run-out problem.
  89.  
  90. One thing that might be a simple/useful change to perl would be
  91. to let one assign a regex to $/ for doing on-the-fly parsing.
  92. (to remain compatible with old scripts, this magic wouldn't turn
  93. on unless you did a 'study $/')
  94.  
  95.   lw> I don't see any theoretical problems with regular expression
  96.   lw> operators that backtrack by attempting to match more rather than
  97.   lw> less.  There's certainly no problem with oscillation, since any
  98.   lw> given operator always progresses in the same direction.
  99.  
  100. This is probably one of those things that can be proven to be an
  101. equivalent set of operations, where providing some operators of the
  102. other set is extraneous, but possibly convenient.
  103.  
  104.   lw> As for the feature in question, it's just one of those things where
  105.   lw> you try to figure out the most general (and practical) way to do
  106.   lw> it, then think about whether you want to do it at all, and then
  107.   lw> maybe find time to do it.  None of these is a trivial undertaking.
  108.   lw> Language design is not a haphazard activity, appearances
  109.   lw> notwithstanding.  :-)
  110.  
  111. /charles
  112. ==============================================================================
  113. Charles Thayer, Columbia University, Dept. CS, Tech-staff... my words only.
  114.  
  115.  
  116.