Re: read text from file, a chunk of more lines at a time

[Kaz Kylheku <kaz@xxxxxxxxxxx>, 2011-11-01 00:02]
On 2011-10-31, Carlos <angus@xxxxxxxxxxxxxxx> wrote:
[Anton Kovalenko <anton@xxxxxxxxx>, 2011-10-31 20:59]
But that's not how people program in Perl,
apparently: they recognize $/ as something that has a chance to
work, and they go on and use it because it's simple and terse and
"beautiful". Now let's look closer at this beauty.

$/="*RECORD*" is obviously wrong:

An item, that would set the *RECORD* straight.
A previous record triggered a bug.

$/="\n*RECORD*\n" is somewhat better, but the *first* record header
(if there are headers) won't be recognized as record separator
anymore. (For a variant without \n's, we get an empty first record
in this case, but, of course, Perl people would "solve" it by
ignoring empty records).

Now, a line-sensitive regular expression could be useful as
separator instead, but $/ is _not_ a regex, so we're out of luck.
It's "better" to leave it as $/="*RECORD*. Good perl programmer
would _document_ the problem with inline *RECORD*s; that's the
maximum quality we could reasonably expect.

To solve your "problem", a Perl programmer would probably just read
and discard the first header, and then set $/ to "\n*RECORD*\n".
Your strawman Perl programmers are too incompetent, you should fire

If you discard the first header, but that record is empty,
then you're again left with a header which does not match

\n is not a good substitute for anchors like ^ and $ which are not
character matches, but a semantic extension to regexes.

Come on, you are testing a sketch algorithm to a made up specification.
He was talking about *RECORD* being not a separator but a header. Now
you say there can be empty records? Then the Perl programmer would set
$/ to "*RECORD*\n" and join records if needed.

My point is that Perl programmers aren't necessarily stupid. That's all.

Oh, and also that Perl's augmented read-line simplifies the solution a



Relevant Pages

  • Re: read text from file, a chunk of more lines at a time
    ... empty records). ... a Perl programmer would probably just read and ... If you discard the first header, but that record is empty, ...
  • Re: TRUE and FALSE values in the relational lattice
    ... E * E: natural join ... the relation with empty header and a single empty tuple ... the equality relation with header ... So the syntax becomes: ...
  • HELP! how do i read in multiline data blocks?
    ... fgetl, etc., and trying out various things, but I am not succeeding. ... ONE HEADER LINE ... ONE EMPTY LINE ... I know I want a loop that goes through one datablock at a time, ...
  • Re: No exceptions?
    ... I had in mind that an "empty" header would be assumed. ... I'm still not sure whether relations called TRUE and FALSE would cause confusion with the REAL TRUE and FALSE.) ... with the confidence that your expressions are still correct. ...
  • Re: attribute name conflicts
    ... Regarding "capacity", I think I'd prefer for an app to use the three ... would be that I find it helpful to have as much transparency as possible but a technical reason might be that then I wouldn't need to deal with "exceptions" (I presume that an expression like "A JOIN B" where A and B use the "capacity" attribute name for different types would, in the purest sense, be considered not well-formed, ie., it would not be strictly logical to give a result such as "empty" or "false" for such an expresssion.) ... Whether such a join would cause an exception is a matter of applied psychology and not theory. ... First, assume the header of relation A is and that of relation B is the same. ...