home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / perl / 6947 < prev    next >
Encoding:
Internet Message Format  |  1992-11-11  |  3.5 KB
  1. Path: sparky!uunet!ogicse!uwm.edu!zaphod.mps.ohio-state.edu!usc!news!netlabs!lwall
  2. From: lwall@netlabs.com (Larry Wall)
  3. Newsgroups: comp.lang.perl
  4. Subject: Re: Partial RegExp's
  5. Message-ID: <1992Nov12.003038.18617@netlabs.com>
  6. Date: 12 Nov 92 00:30:38 GMT
  7. Article-I.D.: netlabs.1992Nov12.003038.18617
  8. References: <BxGFIy.LuA@news.cso.uiuc.edu>
  9. Sender: news@netlabs.com
  10. Organization: NetLabs, Inc.
  11. Lines: 58
  12. Nntp-Posting-Host: scalpel.netlabs.com
  13.  
  14. In article <BxGFIy.LuA@news.cso.uiuc.edu> chappell@math.uiuc.edu (Glenn Chappell) writes:
  15. : Here's a question I've been pondering for a few weeks:
  16. : 
  17. : Inherent in the design of Perl seems to be the idea that you always have
  18. : enough space in memory for the entirety of any file you'd ever want to
  19. : work on. But what if you don't? How does one do wonderful things like
  20. : "split" and various pattern matches & such on files that are just too big?
  21. : 
  22. : Well, if there's already a standard, ok-I'll-spell-it-all-out-for-a-
  23. : neophyte-like-you-but-next-time-read-the-book-okay answer to this
  24. : question, I'd like to hear it. If, not, an idea:
  25. : 
  26. : Of course, the way you deal with huge files is to read them in chunks.
  27. : The problem with that is that you miss a pattern match that starts on
  28. : one chunk and ends on another.
  29. : 
  30. : Currently, the result of an attempt at a pattern match gives one of two
  31. : responses: "Got a match" or "Didn't get a match". What if there were a
  32. : way to tell the pattern matcher that some patterns may extend off the
  33. : end of the currently available text, and we gave the matcher the ability
  34. : to give two other reponses: "Got a partial match, and if you give me
  35. : more data, I may get a match" and "Got a match, which may turn into a
  36. : bigger match if you give me more data". The matcher would also return
  37. : the place at which the partial match began.
  38. : 
  39. : Now, from what I know of pattern matching, it seems to me that this would
  40. : be an easy modification to do. The question, then, is whether it would
  41. : be worthwhile. So, does anyone think so? Or is it just me?
  42.  
  43. The main problem is the semantics of *, + and {}.  Currently these want
  44. to match the LONGEST possible string.  Some patterns would have to
  45. slurp in the entire file anyway.
  46.  
  47. This is one of the reasons that Mark and I have been talking about
  48. variants of *, + and {} that would match the shortest string possible.
  49. Currently there are only two ways to do first-match rather than last-match:
  50. 1) have the thing you're looking for be the first thing in a pattern, or
  51. 2) carefully write the intermediate stuff to exclude the pattern you're
  52. looking for.  Both of these approaches leave something to be desired.
  53.  
  54. A thing that might help with option 1 is if we attached the state of
  55. m//g searches to the searched string rather than to the pattern
  56. itself.  This would let you switch from one pattern to another in mid
  57. search.  One could then do tokenizing without s///, for instance.  Of
  58. course, that doesn't help the slurp-in-more-file-if-you-run-out problem.
  59.  
  60. I don't see any theoretical problems with regular expression operators
  61. that backtrack by attempting to match more rather than less.  There's
  62. certainly no problem with oscillation, since any given operator always
  63. progresses in the same direction.
  64.  
  65. As for the feature in question, it's just one of those things where you
  66. try to figure out the most general (and practical) way to do it, then
  67. think about whether you want to do it at all, and then maybe find time
  68. to do it.  None of these is a trivial undertaking.  Language design is
  69. not a haphazard activity, appearances notwithstanding.  :-)
  70.  
  71. Larry
  72.