Mailing List Archive

pod2latex and pod2man differ from pod2html
The handling of =over, =back and =item is different in pod2html than
it is in either pod2man or pod2latex. In the former, they nest. In the
latter they do not (almost).

In fact, on the following pod:

=over 1

=item 1

=over 1

=item a

=back

=item 2

=back

pod2man will output:

1
a
2

pod2 latex will complain:

Illegal '=item' command without preceding 'over': at /usr/new/bin/pod2latex line 361, <POD> chunk 6.

and output the correctly nested enumerate and description blocks but
the wrong \item for "2" (eg. it spits out \item[2] when it should spit
out \item).

pod2html will output currectly nested

1
a
.
2
.

but with the "."'s in the places noted.

*******************WARNING: Dream-functionality idea ahead!*******************

Given all of this flakiness, wouldn't it be esier to have a Pod module
that reads in pod files, and represents them as perl datastructures
and THEN write modules to convert that internal representation to
another format? This would lend itself to more consistency and would
even allow for silly things like "suggesting" a common set of
command-line options and i/o conventions (what DOES "pod2x file.pod"
do?)

pod2foo could just be:

use Pod;
use Pod::Foo;
$pod = Pod->new(@ARGV);
$pod->convert('Foo');
exit 0;

-AJS

--
Aaron Sherman <ajs@ajs.com> B4 f w+ c kv s+(--)v r p
I-Kinetics, Inc. Pager: (508)545-0584
1 NE Executive Park Fax: (617)270-4979
Burlington, MA 01803-5005 WWW: http://ajs.com/~ajs/
ajs@ajs.com or ajs@openmarket.com
"I speak for no one."
Re: pod2latex and pod2man differ from pod2html [ In reply to ]
On Thu, 7 Sep 1995, Aaron Sherman wrote:

> *******************WARNING: Dream-functionality idea ahead!*******************
>
> Given all of this flakiness, wouldn't it be esier to have a Pod module
> that reads in pod files, and represents them as perl datastructures
> and THEN write modules to convert that internal representation to
> another format? This would lend itself to more consistency and would
> even allow for silly things like "suggesting" a common set of
> command-line options and i/o conventions (what DOES "pod2x file.pod"
> do?)

Aarrghhh!

> pod2foo could just be:
>
> use Pod;
> use Pod::Foo;
> $pod = Pod->new(@ARGV);
> $pod->convert('Foo');
> exit 0;

Yes, sounds like a neat idea, doesn't it? Actually, I've been working on just
such a module (Pod::Parse, to be exact) for some time now. Well, actually I
was working on version 1 for some time. Recently I've given it up as a bad
job and have started in on version 2. I may have something finished by
perl5.003 or so. The main problem is simplifying the POD structure, turning
it into something parsable by simple code, and coalecseing the various
behaviors present in pod2man, pod2html, and pod2parse.

> -AJS
>
> --
> Aaron Sherman <ajs@ajs.com> B4 f w+ c kv s+(--)v r p
> I-Kinetics, Inc. Pager: (508)545-0584
> 1 NE Executive Park Fax: (617)270-4979
> Burlington, MA 01803-5005 WWW: http://ajs.com/~ajs/
> ajs@ajs.com or ajs@openmarket.com
> "I speak for no one."
>
>

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
Re: pod2latex and pod2man differ from pod2html [ In reply to ]
On Sep 7, 1:40pm, Aaron Sherman wrote:
} Subject: pod2latex and pod2man differ from pod2html
}
} The handling of =over, =back and =item is different in pod2html than
} it is in either pod2man or pod2latex. In the former, they nest. In the
} latter they do not (almost).

[...]
}
} pod2html will output currectly nested
} but with the "."'s in the places noted.

The "."'s are a bug when there's not 2 blank lines separating items.
It'll be fixed rsn. In general tho, I'm pretty happy with the way
pod2html handles lists, there's even builtin logic to make sure
that the pod author closed the lists. The main reason it works so
well is that it slurps from ^= to ^=, instead of single paragraphs,
requiring many more state variables to handle lists and other stuff.


} Given all of this flakiness, wouldn't it be esier to have a Pod module
} that reads in pod files, and represents them as perl datastructures
} and THEN write modules to convert that internal representation to
} another format? This would lend itself to more consistency and would
} even allow for silly things like "suggesting" a common set of
} command-line options and i/o conventions (what DOES "pod2x file.pod"
} do?)
}
} pod2foo could just be:
}
} use Pod;
} use Pod::Foo;
} $pod = Pod->new(@ARGV);
} $pod->convert('Foo');
} exit 0;

We're working on this now, starting with the Parse module.


Humbly,

Bill
Re: pod2latex and pod2man differ from pod2html [ In reply to ]
}
} Yes, sounds like a neat idea, doesn't it? Actually, I've been working on just
} such a module (Pod::Parse, to be exact) for some time now. Well, actually I
} was working on version 1 for some time. Recently I've given it up as a bad
} job and have started in on version 2. I may have something finished by
} perl5.003 or so. The main problem is simplifying the POD structure, turning
} it into something parsable by simple code, and coalecseing the various
} behaviors present in pod2man, pod2html, and pod2parse.

Gee, I wish we could get together with a few 6packs on this. I bet
we could knock it out in a night or two. 'Specially if I could talk
Larry into allowing slurped chunks.


Bill
Re: pod2latex and pod2man differ from pod2html [ In reply to ]
On Thu, 7 Sep 1995, Bill Middleton wrote:

> }
> } Yes, sounds like a neat idea, doesn't it? Actually, I've been working on just
> } such a module (Pod::Parse, to be exact) for some time now. Well, actually I
> } was working on version 1 for some time. Recently I've given it up as a bad
> } job and have started in on version 2. I may have something finished by
> } perl5.003 or so. The main problem is simplifying the POD structure, turning
> } it into something parsable by simple code, and coalecseing the various
> } behaviors present in pod2man, pod2html, and pod2parse.
>
> Gee, I wish we could get together with a few 6packs on this. I bet
> we could knock it out in a night or two. 'Specially if I could talk
> Larry into allowing slurped chunks.

OK, I'll bite. What are slurped chunks, and why should Larry allow them?
What are your thoughts here?

> Bill

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
Re: pod2latex and pod2man differ from pod2html [ In reply to ]
Well, in that case, I'll stop writing one. I got just far enough to
start wondering about some of the harder questions....

-AJS

--
Aaron Sherman <ajs@ajs.com> B4 f w+ c kv s+(--)v r p
I-Kinetics, Inc. Pager: (508)545-0584
1 NE Executive Park Fax: (617)270-4979
Burlington, MA 01803-5005 WWW: http://ajs.com/~ajs/
ajs@ajs.com or ajs@openmarket.com
"I speak for no one."
Re: pod2latex and pod2man differ from pod2html [ In reply to ]
On Thu, 7 Sep 1995, Aaron Sherman wrote:

>
> Well, in that case, I'll stop writing one. I got just far enough to
> start wondering about some of the harder questions....

Exactly. It looks simple to start, but soon bogs down.

For Bill and the rest, here are some comments on what I'm currently
working on:

1. regexps are dead. Attempting to parse POD formatting commands using
regexps is tempting, but very difficult, especially if you want to stay
8-bit clean.

2. I'm playing with a pseduo-lisp data structure. That means that "A
B<bold> word and a B<bold I<italic word>>" turns into the following data
structure:

[B, [text, "bold"]], [text, " word and a "],
[B, [I, [text, "italic word"]]]

3. Things like L<> and proposed things like X<> that need some of
separator use the "/" character to subdivide the contents of the command.
A "//" acts like a "/" and doesn't delimit.

4. Wherever possible do heuristics on [text, "..."] items, or on full
parse trees. Massive regexp massaging is a no-no.

5. Entire pod files turn into something like #2 above:

[file, "test.pod"], [head1, [text, "A header!"]], [flow, [text, "a
normal text paragraph"]], etc.

6. So far, implementing some heuristics seems incredibly painful. This
may simply be because I don't use LISP much. Getting [CBIF]<...> to
change into R<[CBIF]<...>> is simple enough, but doing it only if there
isn't an R<> inside already, and not doing it more then once just gives
me a headache.

7. I'm quite proud that I got #3 implemented in such a way that I can
turn this:

[B, [text, "ab/cd"], [I, [text, "ef/gh]] ], [text, "i"]

into this:

[ [B, [text, "ab"]] ],
[ [B, [text, "cd"], [I, [text, "ef"]]] ],
[ [B, [I, [text, "gh"]]], [text, "i"] ]

However, I must admit that I don't quite understand exactly how the code
works :-(. (Back to not enough LISP, I'm afraid.) This actually seems
indicative of perl's nested arrays so far. They work just fine, and are more
then fast enough, but are painful to use at times. I know exactly how the
argument for "/" division should work, but the code has required lots of
fudging to work. Whether that is my fault or perl's is mildly unclear.

8. Surprisingly, perhaps, doing all of this with nested arrays instead
of regexps is quite efficient, and probably workable at production level.
Once you get into complex heuristics that like to walk a [flow, ...] tree
up and down several times, though, things start to slow down.

> -AJS

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
Re: pod2latex and pod2man differ from pod2html [ In reply to ]
On Sep 7, 3:55pm, Kenneth Albanowski wrote:
} Subject: Re: pod2latex and pod2man differ from pod2html
} On Thu, 7 Sep 1995, Bill Middleton wrote:
}
} > Gee, I wish we could get together with a few 6packs on this. I bet
} > we could knock it out in a night or two. 'Specially if I could talk
} > Larry into allowing slurped chunks.
}
} OK, I'll bite. What are slurped chunks, and why should Larry allow them?
} What are your thoughts here?
}

Slurping chunks just means reading from ^= to ^= in a pod at a time.
It makes coding a parser much less work, at least for me. :)
The first pod2html actually did slurp paragraphs, but I found it much
more intuitive to handle chunks at a time. It implies fewer state
variables, and less state logic. There were other things that seemed
to fall into place when I made the switch, too.

You seem to be spending most of your time resolving issues related to
markup and translation, which is fine, I've never even tried Lisp. There
must be a better way than pre->hide->post translations, but I'm not sure
what it is. The problem, as you've surmised, is that unless the
translations are carried out in _exactly_ the right order, and with
_exactly_ the right operation, a given step can cause the step which
follows to get hosed.

I've thought alot about it, and what seems to me to be the ultimate
algorithm is to perform translation ops on different copies of the
current buffer (chunks work best in this scenario too), then somehow
merge the copies into the final translated buffer. I cant seem to be
able to see into it much deeper than that, mostly for lack of time, but
also for lack of in-depth understanding of parsing algorithms and yacc'ish
stuff.

I'm still not convinced that a general Parse module will work for
all the parsers, but I, like you, am not a roff hacker. Neither do
I do latex, web, postscript, or any others I can think of. Maybe the
roff module and others will fall into place, possibly using an algorithm
like the above. I suspect tho, given the complexity of the pod2man, that
it may remain a separate program for awhile. At least 'til Tom
has time to make it work with Parse.

So, I'm afraid I've still not provided an argument convincing enough
for Larry to relax the standard. I guess formalization of other things
in the pod standard are more important, for the time being.


Bill
Re: pod2latex and pod2man differ from pod2html [ In reply to ]
On Thu, 7 Sep 1995, Bill Middleton wrote:

> Slurping chunks just means reading from ^= to ^= in a pod at a time.
> It makes coding a parser much less work, at least for me. :)
> The first pod2html actually did slurp paragraphs, but I found it much
> more intuitive to handle chunks at a time. It implies fewer state
> variables, and less state logic. There were other things that seemed
> to fall into place when I made the switch, too.

Sorry, but I just don't see this as necessary. I'm taking Larry's word as
gospel that POD's consist of paragraphs, and that you read paragraphs at a
time. The only change is that can read in multiple flowed and verbatim
paragraphs at a time. Also, come to think of it, you had the "title"
distinction in pod2html where the first line of an =command is distinct
from the rest. Personally, I feel that you are intent on parsing something
that is slightly different from actual POD. (Then again, since we seem
to be defining POD as we go along, this hardly matters.)

> You seem to be spending most of your time resolving issues related to
> markup and translation, which is fine, I've never even tried Lisp. There
> must be a better way than pre->hide->post translations, but I'm not sure
> what it is.

What I'm working on is. I _think_.

> The problem, as you've surmised, is that unless the
> translations are carried out in _exactly_ the right order, and with
> _exactly_ the right operation, a given step can cause the step which
> follows to get hosed.

No kidding. At least I've graduated from "E<lt>" to [E, "lt"]. It may not
seem like it, but this is a major improvement. If I don't want to see a
particular command type, I can just skip over it when I'm recursing
through. This seems to be the only way to go.

> I've thought alot about it, and what seems to me to be the ultimate
> algorithm is to perform translation ops on different copies of the
> current buffer (chunks work best in this scenario too), then somehow
> merge the copies into the final translated buffer. I cant seem to be
> able to see into it much deeper than that, mostly for lack of time, but
> also for lack of in-depth understanding of parsing algorithms and yacc'ish
> stuff.

:-) Actually, quite by accident I happened to create something along that
style of parsing too. Here's a rough example:

Hide stuff:

s/E<(.+)>/ ($escape[++$escapes]=$1), "%E$escapes%" /ge;

Reveal stuff:

s/%E(\d+)%/$escape[$1]/ge;

I think this is close to what you are thinking of. Or maybe not, but it's
still a useful idea.

> I'm still not convinced that a general Parse module will work for
> all the parsers, but I, like you, am not a roff hacker. Neither do
> I do latex, web, postscript, or any others I can think of. Maybe the
> roff module and others will fall into place, possibly using an algorithm
> like the above. I suspect tho, given the complexity of the pod2man, that
> it may remain a separate program for awhile. At least 'til Tom
> has time to make it work with Parse.

Let me say this. I don't see _any_ difficulty in gluing in different
parsers. Even without understanding all the formatting concerns of
pod2man, I've easily managed to use it into some of my various parsing
engines, with good success. Once you rip POD's formatting commands down to
a canonical minimum (and hopefully one that is easily parsed) then even
pod2man becomes quite simple. It's just a matter of reading in some sort
of chunk, and then doing something with it. If the chunks are reduced to
"make this bold", "make this italic", and "this starts a bulleted list",
then things are actually rather simple. Or so it seems so far.

As for the various heuristics that all of the modules go through: I very
much hope that they can all be put in Parse, and thus gotten out of the
way. I see the formatters as _only_ formatters, with as little
intelligence as is possible. Otherwise the whole idea of Parse falls
through.

> So, I'm afraid I've still not provided an argument convincing enough
> for Larry to relax the standard. I guess formalization of other things
> in the pod standard are more important, for the time being.

Yes, formalization seems important. From what I've been playing around
with, though, it seems even getting a functional parsing engine -- a
_perfect_ parsing engine that obeys a particular standard -- is quite
difficult, and the standard may have to come after the technology is in
place.

Let it be said that Larry did a fine job with POD, and that as a simple
formatting language it works quite nicely. It's just all the little
heuristics in pod2* that make it challenging.

> Bill

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
Re: pod2latex and pod2man differ from pod2html [ In reply to ]
On Thu, 7 Sep 1995, Bill Middleton wrote:

> Slurping chunks just means reading from ^= to ^= in a pod at a time.
> It makes coding a parser much less work, at least for me. :)
> The first pod2html actually did slurp paragraphs, but I found it much
> more intuitive to handle chunks at a time. It implies fewer state
> variables, and less state logic. There were other things that seemed
> to fall into place when I made the switch, too.

Sorry, but I just don't see this as necessary. I'm taking Larry's word as
gospel that POD's consist of paragraphs, and that you read paragraphs at a
time. The only change is that can read in multiple flowed and verbatim
paragraphs at a time. Also, come to think of it, you had the "title"
distinction in pod2html where the first line of an =command is distinct
from the rest. Personally, I feel that you are intent on parsing something
that is slightly different from actual POD. (Then again, since we seem
to be defining POD as we go along, this hardly matters.)

> You seem to be spending most of your time resolving issues related to
> markup and translation, which is fine, I've never even tried Lisp. There
> must be a better way than pre->hide->post translations, but I'm not sure
> what it is.

What I'm working on is. I _think_.

> The problem, as you've surmised, is that unless the
> translations are carried out in _exactly_ the right order, and with
> _exactly_ the right operation, a given step can cause the step which
> follows to get hosed.

No kidding. At least I've graduated from "E<lt>" to [E, "lt"]. It may not
seem like it, but this is a major improvement. If I don't want to see a
particular command type, I can just skip over it when I'm recursing
through. This seems to be the only way to go.

> I've thought alot about it, and what seems to me to be the ultimate
> algorithm is to perform translation ops on different copies of the
> current buffer (chunks work best in this scenario too), then somehow
> merge the copies into the final translated buffer. I cant seem to be
> able to see into it much deeper than that, mostly for lack of time, but
> also for lack of in-depth understanding of parsing algorithms and yacc'ish
> stuff.

:-) Actually, quite by accident I happened to create something along that
style of parsing too. Here's a rough example:

Hide stuff:

s/E<(.+)>/ ($escape[++$escapes]=$1), "%E$escapes%" /ge;

Reveal stuff:

s/%E(\d+)%/$escape[$1]/ge;

I think this is close to what you are thinking of. Or maybe not, but it's
still a useful idea.

> I'm still not convinced that a general Parse module will work for
> all the parsers, but I, like you, am not a roff hacker. Neither do
> I do latex, web, postscript, or any others I can think of. Maybe the
> roff module and others will fall into place, possibly using an algorithm
> like the above. I suspect tho, given the complexity of the pod2man, that
> it may remain a separate program for awhile. At least 'til Tom
> has time to make it work with Parse.

Let me say this. I don't see _any_ difficulty in gluing in different
parsers. Even without understanding all the formatting concerns of
pod2man, I've easily managed to use it into some of my various parsing
engines, with good success. Once you rip POD's formatting commands down to
a canonical minimum (and hopefully one that is easily parsed) then even
pod2man becomes quite simple. It's just a matter of reading in some sort
of chunk, and then doing something with it. If the chunks are reduced to
"make this bold", "make this italic", and "this starts a bulleted list",
then things are actually rather simple. Or so it seems so far.

As for the various heuristics that all of the modules go through: I very
much hope that they can all be put in Parse, and thus gotten out of the
way. I see the formatters as _only_ formatters, with as little
intelligence as is possible. Otherwise the whole idea of Parse falls
through.

> So, I'm afraid I've still not provided an argument convincing enough
> for Larry to relax the standard. I guess formalization of other things
> in the pod standard are more important, for the time being.

Yes, formalization seems important. From what I've been playing around
with, though, it seems even getting a functional parsing engine -- a
_perfect_ parsing engine that obeys a particular standard -- is quite
difficult, and the standard may have to come after the technology is in
place.

Let it be said that Larry did a fine job with POD, and that as a simple
formatting language it works quite nicely. It's just all the little
heuristics in pod2* that make it challenging.

> Bill

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
Re: pod2latex and pod2man differ from pod2html [ In reply to ]
One request about pod modules: Please make it so that text blocks that
have no special attributes are stored as scalars. Why? Space and
speed. For instance, [B, [I, "text ", [C, "%foo"] ] ] even feels right to
my LISP genes... and is much more efficient than, [B, [I, [text, "text "],
[C, [text, "%foo"] ] ] ] which on just this simple example contains 2
more RVs, 2 more AVs and 2 more SVs than I think it needs. You can
always deal with this correctly because !ref tells you that you've got
text.

--
--- Aaron Sherman / "B4 f w+ c kv s+(--)v r p" ---
Phone: (617)321-5100 "I do not speak for THEM."
Email: ajs@ajs.com WWW: http://ajs.com/~ajs/
Re: pod2latex and pod2man differ from pod2html [ In reply to ]
On Fri, 8 Sep 1995, Aaron Sherman wrote:

>
> One request about pod modules: Please make it so that text blocks that
> have no special attributes are stored as scalars. Why? Space and
> speed. For instance, [B, [I, "text ", [C, "%foo"] ] ] even feels right to
> my LISP genes... and is much more efficient than, [B, [I, [text, "text "],
> [C, [text, "%foo"] ] ] ] which on just this simple example contains 2
> more RVs, 2 more AVs and 2 more SVs than I think it needs. You can
> always deal with this correctly because !ref tells you that you've got
> text.

I'm still playing around with things like that. On my first pass through,
the main formatting engine is simpler, as "B" and "I" just recurse through
all elements, with "text" always having a single element that it outputs
directly without recursing. It seemed elegant at the time. But as I said,
I'm still playing. We'll see what happens when I'm done.

> --
> --- Aaron Sherman / "B4 f w+ c kv s+(--)v r p" ---
> Phone: (617)321-5100 "I do not speak for THEM."
> Email: ajs@ajs.com WWW: http://ajs.com/~ajs/

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
Re: pod2latex and pod2man differ from pod2html [ In reply to ]
Aaron Sherman writes:
>
>
> One request about pod modules: Please make it so that text blocks that
> have no special attributes are stored as scalars. Why? Space and
> speed. For instance, [B, [I, "text ", [C, "%foo"] ] ] even feels right to
> my LISP genes... and is much more efficient than, [B, [I, [text, "text "],
> [C, [text, "%foo"] ] ] ] which on just this simple example contains 2
> more RVs, 2 more AVs and 2 more SVs than I think it needs. You can
> always deal with this correctly because !ref tells you that you've got
> text.

Well, if space is of any concern, then blessed refs may be a way to
go. Maybe even revive old idea on

use Overload '""' => \&stringify;

Ilya
Re: pod2latex and pod2man differ from pod2html [ In reply to ]
On Sep 8, 8:56am, Kenneth Albanowski wrote:
} Subject: Re: pod2latex and pod2man differ from pod2html
} On Thu, 7 Sep 1995, Bill Middleton wrote:
}
} [...]
} Personally, I feel that you are intent on parsing something
} that is slightly different from actual POD. (Then again, since we seem
} to be defining POD as we go along, this hardly matters.)

I dunno, my main concern is that pod2html does a good job on the perl pods.
Correctness, as defined by any one opinion (including Larry's), is secondary.
There's more than one way to do it. (Someone said that once...)

} > I've thought alot about it, and what seems to me to be the ultimate
} > algorithm is to perform translation ops on different copies of the
} > current buffer (chunks work best in this scenario too), then somehow
} > merge the copies into the final translated buffer. [...]
}
} :-) Actually, quite by accident I happened to create something along that
} style of parsing too. Here's a rough example:
}
} Hide stuff:
}
} s/E<(.+)>/ ($escape[++$escapes]=$1), "%E$escapes%" /ge;
}
} Reveal stuff:
}
} s/%E(\d+)%/$escape[$1]/ge;
}
} I think this is close to what you are thinking of. Or maybe not, but it's
} still a useful idea.

Yes. Thats the notion, I think, assuming it could apply to other types
of markups.

} Let it be said that Larry did a fine job with POD, and that as a simple
} formatting language it works quite nicely. It's just all the little
} heuristics in pod2* that make it challenging.

Seems like most of his ideas turn out ok. :-)


Bill
Re: pod2latex and pod2man differ from pod2html [ In reply to ]
> I'm still playing around with things like that. On my first pass through,
> the main formatting engine is simpler, as "B" and "I" just recurse through
> all elements, with "text" always having a single element that it outputs
> directly without recursing. It seemed elegant at the time. But as I said,
> I'm still playing. We'll see what happens when I'm done.

We should measure how much memory is taken up by parsing, say, perlfunc,
and figure out whether this will work on systems with limited memory,
such as PCs. It's possible we'll need a way to pipeline to the backend
(I don't mean as a separate process), especially if pod is to be used
for other (arbitrarily large) purposes.

On the other hand, systems running Perl aren't typically short on
memory... :-)

Larry
Re: pod2latex and pod2man differ from pod2html [ In reply to ]
On Sat, 9 Sep 1995, Larry Wall wrote:

> > I'm still playing around with things like that. On my first pass through,
> > the main formatting engine is simpler, as "B" and "I" just recurse through
> > all elements, with "text" always having a single element that it outputs
> > directly without recursing. It seemed elegant at the time. But as I said,
> > I'm still playing. We'll see what happens when I'm done.
>
> We should measure how much memory is taken up by parsing, say, perlfunc,
> and figure out whether this will work on systems with limited memory,
> such as PCs. It's possible we'll need a way to pipeline to the backend
> (I don't mean as a separate process), especially if pod is to be used
> for other (arbitrarily large) purposes.
>
> On the other hand, systems running Perl aren't typically short on
> memory... :-)

In some of my tests of semi-stable engines, I usually top out at about 5
meg to parse and format all of pod/*.pod. Of course, that's with _all_ of
the pods being loaded into memory simulatenously.

> Larry

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
Re: pod2latex and pod2man differ from pod2html [ In reply to ]
On Sat, 9 Sep 1995, Ilya Zakharevich wrote:

> Aaron Sherman writes:
> >
> >
> > One request about pod modules: Please make it so that text blocks that
> > have no special attributes are stored as scalars. Why? Space and
> > speed. For instance, [B, [I, "text ", [C, "%foo"] ] ] even feels right to
> > my LISP genes... and is much more efficient than, [B, [I, [text, "text "],
> > [C, [text, "%foo"] ] ] ] which on just this simple example contains 2
> > more RVs, 2 more AVs and 2 more SVs than I think it needs. You can
> > always deal with this correctly because !ref tells you that you've got
> > text.
>
> Well, if space is of any concern, then blessed refs may be a way to
> go. Maybe even revive old idea on
>
> use Overload '""' => \&stringify;

Please, I think I'll have to get _something_ finished first, before I
worry about making it efficient in complex and worrying ways. :-)

> Ilya

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
Re: pod2latex and pod2man differ from pod2html [ In reply to ]
> From: Ilya Zakharevich <ilya@math.ohio-state.edu>
>
> Aaron Sherman writes:
> >
> > One request about pod modules: Please make it so that text blocks that
> > have no special attributes are stored as scalars. Why? Space and
> > speed. For instance, [B, [I, "text ", [C, "%foo"] ] ] even feels right to
> > my LISP genes... and is much more efficient than, [B, [I, [text, "text "],
> > [C, [text, "%foo"] ] ] ] which on just this simple example contains 2
> > more RVs, 2 more AVs and 2 more SVs than I think it needs. You can
> > always deal with this correctly because !ref tells you that you've got
> > text.
>
> Well, if space is of any concern, then blessed refs may be a way to
> go. Maybe even revive old idea on
>
> use Overload '""' => \&stringify;
>
> Ilya
>
Hey, another excuse to post an old message of mine:

----- Begin Included Message -----

Date: Tue, 4 Oct 1994 16:11:30 +0100
Subject: Wow! I have a large lightbulb above my head!

Take a moment to consider these lines:

%OVERLOAD=( '""' => sub { join("", @{$_[0]}) } );

sub html { my($type)=shift; bless ["<$type>", @_, "</$type>"]; }

:-) I *love* Perl 5! Thankyou Larry and Ilya.

Regards,
Tim Bunce.

p.s. If you didn't get it, think about recursive data types: html(html())
p.p.s. I'll turn this into a much more practical example in a day or two.
p.p.p.s. It's a pity that overloads are not inherited. Is this a bug?

----- End Included Message -----

I never did get a round to creating a more practical example.

Tim.
Re: pod2latex and pod2man differ from pod2html [ In reply to ]
>From: Kenneth Albanowski <kjahds@kjahds.com>
>On Sat, 9 Sep 1995, Ilya Zakharevich wrote:
>> Aaron Sherman writes:
>> > One request about pod modules: Please make it so that text blocks that
>> > have no special attributes are stored as scalars. Why? Space and
>> > speed. For instance, [B, [I, "text ", [C, "%foo"] ] ] even feels right to
>> > my LISP genes... and is much more efficient than, [B, [I, [text, "text "],
>> > [C, [text, "%foo"] ] ] ] which on just this simple example contains 2
>> > more RVs, 2 more AVs and 2 more SVs than I think it needs. You can
>> > always deal with this correctly because !ref tells you that you've got
>> > text.
>> Well, if space is of any concern, then blessed refs may be a way to
>> go. Maybe even revive old idea on
>> use Overload '""' => \&stringify;
>Please, I think I'll have to get _something_ finished first, before I
>worry about making it efficient in complex and worrying ways. :-)

Wait a miniute, if we don't mark text explisitly isn't there a problem
with the text strings "B", "I", "C", etc? A paragraph that starts with
text string "B" is going to confuse things. I think that you still
need the [text "text"] notation to fall back on when ever the "text"
could be confused with someother directive. Other non-ambigious
cases can probably use the shorter notation.

--
Mark Biggar
mab@wdl.loral.com
Re: pod2latex and pod2man differ from pod2html [ In reply to ]
: Please, I think I'll have to get _something_ finished first, before I
: worry about making it efficient in complex and worrying ways. :-)

Now you know how I feel all the time. :-)

Larry
Re: pod2latex and pod2man differ from pod2html [ In reply to ]
On Mon, 11 Sep 1995, Mark A Biggar wrote:

> Wait a miniute, if we don't mark text explisitly isn't there a problem
> with the text strings "B", "I", "C", etc? A paragraph that starts with
> text string "B" is going to confuse things. I think that you still
> need the [text "text"] notation to fall back on when ever the "text"
> could be confused with someother directive. Other non-ambigious
> cases can probably use the shorter notation.

No, I assure you that's not an issue. ("B","text") is quite different
from (["B","text"]).

> --
> Mark Biggar
> mab@wdl.loral.com
>

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
Re: pod2latex and pod2man differ from pod2html [ In reply to ]
On Mon, 11 Sep 1995, Tim Bunce wrote:

> Date: Tue, 4 Oct 1994 16:11:30 +0100
> Subject: Wow! I have a large lightbulb above my head!
>
> Take a moment to consider these lines:
>
> %OVERLOAD=( '""' => sub { join("", @{$_[0]}) } );
>
> sub html { my($type)=shift; bless ["<$type>", @_, "</$type>"]; }
>

A perfect example of the type of cleverness I don't think I can use right
now. Or if I do use it, I'm sure it'll give me a headache. ;-) Certainly
the spirit of the thing is there, though.

> :-) I *love* Perl 5! Thankyou Larry and Ilya.
>
> Regards,
> Tim Bunce.
>
> p.s. If you didn't get it, think about recursive data types: html(html())
> p.p.s. I'll turn this into a much more practical example in a day or two.
> p.p.p.s. It's a pity that overloads are not inherited. Is this a bug?
>
> ----- End Included Message -----
>
> I never did get a round to creating a more practical example.
>
> Tim.

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)