Re: For your christmas reading pleasure.
Michele Dondi
On Fri, 24 Dec 2004 22:58:04 GMT, Ian Hutchinson
<hu...@hutchinson.belmont.ma.us> wrote:
>complete TeX parser cannot be built using lex. I should know, since I
>have built what is probably the most powerful incomplete one (TtH) built
>with (f)lex. The reason is, of course, that everything in TeX (including
>tokenization) depends on the context (as the xii.tex wizardry magically,
>and for today topically, demonstrates).
This has been discussed many times here. It somehow reminds me of
similar discussions about Perl. (History has been repeating also wrt
Perl6 which some user hoped to be somewhat "more regular", instead
rumors have it that not only the following will continue to be true
about it: "nothing but perl can parse Perl", but that the much
stronger will hold too "nothing but Perl can parse Perl".)
Now it occurs to me that even if all of these discussions are highly
hypothetical, in another thread informed TeXperts expressed the need
for a thorough reimplementation in a suitable language to overcome
some of its current limitations. I dared to suggest Perl6 (making the
issue even more hypthetical, if possible), with its extensive support
for grammars, but then David Kastrup, who is a very knowledgeable
person, answered that in any case it would lack the necessary
structures, to which I replied asking if he knew what Perl6 is
supposed to look like (and he said he did, but I still have doubts).
So the question/hint for a discussion is this: could Perl6 -still
*hypothetically* speaking- be the base for the implementation of a
modern TeX successor?
Michele
--
>It's because the universe was programmed in C++.
No, no, it was programmed in Forth. See Genesis 1:12:
"And the earth brought Forth ..."
- Robert Israel in sci.math, thread "Why numbers?"
David Kastrup
> So the question/hint for a discussion is this: could Perl6 -still
> *hypothetically* speaking- be the base for the implementation of a
> modern TeX successor?
Shrug. There is no particular advantage making Perl particularly
suited to the task: the list data structures are not particularly
suited to Perl, the stuff Perl offers for parsing and scanning is not
well-suited for TeX, the main control structures and concepts in TeX
(optimization and parallel execution, which are mostly hard-coded in
current TeX) don't map well to Perl and would still require mostly
hard-coding.
In short: there is nothing that would particularly recommend Perl.
Add to that the fact that Perl is a _huge_ complex system that tends
to get replaced every few years, I don't see why one would want to
base a large code base with a _much_ longer shelf life on it.
Of _course_ you could make Perl6 the base for the implementation of
some successor. It is a programming language, after all. But I don't
see why anyone would want to do that.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
UKTUG FAQ: <URL:http://www.tex.ac.uk/cgi-bin/texfaq2html>
Michele Dondi
>Michele Dondi <bik....@tiscalinet.it> writes:
>
>> So the question/hint for a discussion is this: could Perl6 -still
>> *hypothetically* speaking- be the base for the implementation of a
>> modern TeX successor?
>
>Shrug. There is no particular advantage making Perl particularly
Well it's well suited for text processing. Perl5 is already able to do
a decent job in this sense: even if basic regular expressions (even
taking into account extended patterns) are not well suited to match
e.g. balanced text, it can be parsed by means of Text::Balanced. And
there are dedicated modules for dealing with xml, for example. And
there's Parse::RecDescent. Of course TeX is a whole another thing.
This is why I thought of Perl6.
>suited to the task: the list data structures are not particularly
Why?!?
>suited to Perl, the stuff Perl offers for parsing and scanning is not
>well-suited for TeX, the main control structures and concepts in TeX
>(optimization and parallel execution, which are mostly hard-coded in
>current TeX) don't map well to Perl and would still require mostly
>hard-coding.
So what? Perl already supports binary extensions. Rumors have it that
creating such extensions will be much easier under Perl6.
Perl6 development is twofold: on the one hand you have the design of a
new language (new syntax, new semantic, new features), different from
the current one but similar enough to allow for automatic translation,
and on the other one you have the runtime environment (Parrot[*], see
<http://www.parrotcode.org>). Other rumors have it that Parrot will be
able to run natively bytecode for other virtual machines, including
Java, for example. Which is good news IMO!
>In short: there is nothing that would particularly recommend Perl.
Certainly it would be better suited than other languages.
>Add to that the fact that Perl is a _huge_ complex system that tends
>to get replaced every few years, I don't see why one would want to
>base a large code base with a _much_ longer shelf life on it.
This is a good point! Not exactly as in your words, but somewhat like
that. I don't know how things will be like for Perl6: of course I
can't know, since not only it doesn't exist yet, but it won't even
exist for quite a lot of time too. However much care is being taken
exactly to make it stable enough from scratch, although 6.0 may
resonably enough lack some of the most exotic features.
>Of _course_ you could make Perl6 the base for the implementation of
>some successor. It is a programming language, after all. But I don't
>see why anyone would want to do that.
Other than I love it? Well, as I said I think that even in its current
version it could be better suited than some other languages. But the
few things I know of Perl6, having the patience of waiting for hell to
freeze, suggest me that it will be *particularly* well suited. That is
just MHO, anyway...
[*] Designed to be the basis, as a virtual machine, not only for Perl6
but for quite a lot of other languages as well. Ponie is a project to
port Perl5 to parrot.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
David Kastrup
> On Tue, 28 Dec 2004 22:53:11 +0100, David Kastrup <d...@gnu.org> wrote:
>
>>Michele Dondi <bik....@tiscalinet.it> writes:
>>
>>> So the question/hint for a discussion is this: could Perl6 -still
>>> *hypothetically* speaking- be the base for the implementation of a
>>> modern TeX successor?
>>
>>Shrug. There is no particular advantage making Perl particularly
>
> Well it's well suited for text processing.
TeX's input processing has very little to with standard text
processing, and in fact I don't see any advantage Perl would offer
here. You could probably use Perl's hash tables for control
sequences, but that's pretty much all. The table of equivalents does
not map comfortably to anything Perl would offer.
> Perl5 is already able to do a decent job in this sense: even if
> basic regular expressions (even taking into account extended
> patterns) are not well suited to match e.g. balanced text, it can be
> parsed by means of Text::Balanced. And there are dedicated modules
> for dealing with xml, for example. And there's Parse::RecDescent. Of
> course TeX is a whole another thing. This is why I thought of
> Perl6.
So what would Perl6 offer that would be less painful than just
explicit coding in some more efficient language?
>>suited to the task: the list data structures are not particularly
>
> Why?!?
Why what?
>>suited to Perl, the stuff Perl offers for parsing and scanning is
>>not well-suited for TeX, the main control structures and concepts in
>>TeX (optimization and parallel execution, which are mostly
>>hard-coded in current TeX) don't map well to Perl and would still
>>require mostly hard-coding.
>
> So what? Perl already supports binary extensions. Rumors have it
> that creating such extensions will be much easier under Perl6.
So where is _any_ advantage?
> Perl6 development is twofold: on the one hand you have the design of
> a new language (new syntax, new semantic, new features), different
> from the current one but similar enough to allow for automatic
> translation, and on the other one you have the runtime environment
> (Parrot[*], see <http://www.parrotcode.org>). Other rumors have it
> that Parrot will be able to run natively bytecode for other virtual
> machines, including Java, for example. Which is good news IMO!
>
>>In short: there is nothing that would particularly recommend Perl.
>
> Certainly it would be better suited than other languages.
That is a blanket statement for which I see no support at all. You
have not pointed out anything in which Perl would offer something of
particular value for TeX programming.
>>Add to that the fact that Perl is a _huge_ complex system that tends
>>to get replaced every few years, I don't see why one would want to
>>base a large code base with a _much_ longer shelf life on it.
>
> This is a good point! Not exactly as in your words, but somewhat
> like that. I don't know how things will be like for Perl6: of course
> I can't know, since not only it doesn't exist yet, but it won't even
> exist for quite a lot of time too. However much care is being taken
> exactly to make it stable enough from scratch, although 6.0 may
> resonably enough lack some of the most exotic features.
>
>>Of _course_ you could make Perl6 the base for the implementation of
>>some successor. It is a programming language, after all. But I
>>don't see why anyone would want to do that.
>
> Other than I love it? Well, as I said I think that even in its
> current version it could be better suited than some other
> languages. But the few things I know of Perl6, having the patience
> of waiting for hell to freeze, suggest me that it will be
> *particularly* well suited.
How can you love a language that does not even yet exist? Anyway, if
we want vaporware, there is no shortage of it in the TeX world.
Anyway, I see quite more compelling arguments for something like ML
derivatives. Not to a degree that I'd be really gung-ho on some
solution there, but at least quite more useful than what I've seen
from Perl, including Perl6, for TeX-like tasks up to now.
Michele Dondi
to clpmisc to hear the cmts from other contributors there, but it
seems it hasn't attracted much people for which I see two main
reasons: (i) people there (here) are more concerned with how to do
things in perl than in speculative issues about Perl, (ii) the subject
line was not effective at all. So I changed it, something I should
have done in the first place (interested readers can check the
original thread for reference)...
On Thu, 30 Dec 2004 15:31:46 +0100, David Kastrup <d...@gnu.org> wrote:
>>>Shrug. There is no particular advantage making Perl particularly
>>
>> Well it's well suited for text processing.
>
>TeX's input processing has very little to with standard text
>processing, and in fact I don't see any advantage Perl would offer
>here. You could probably use Perl's hash tables for control
>sequences, but that's pretty much all. The table of equivalents does
>not map comfortably to anything Perl would offer.
Perl parsing already is "a little" different than standard text
processing. Perl6 will go so far that the parser will be radically
modifiable at compile time. Pardon me if I'm wrong, but this (and
other charachteristics) will make it much more similar to TeX than
anything else I can think of...
>> course TeX is a whole another thing. This is why I thought of
>> Perl6.
>
>So what would Perl6 offer that would be less painful than just
>explicit coding in some more efficient language?
Grammars!
Regular expressions are already not really much regular any more, but
they will be made so powerful and different from the current behaviour
that their name will be changed to "rules". Not only! Just like (in
some sense) classes group methods, a new concept will be introduced:
that of a grammar, such that grammars will group rules and
incidentally this will be much more than a passing similarity.
>>>suited to the task: the list data structures are not particularly
>>
>> Why?!?
>
>Why what?
Why Perl shouldn't be "well suited to handle list data structures"?
While this is not strictly true, IMHO, even of Perl5, it will be
completely false for Perl6 that will allow both for named and
anonymous lists as well as named and anonymous arrays (arrays are
already different from lists, even if there are obvious
relationships).
>>>suited to Perl, the stuff Perl offers for parsing and scanning is
>>>not well-suited for TeX, the main control structures and concepts in
>>>TeX (optimization and parallel execution, which are mostly
>>>hard-coded in current TeX) don't map well to Perl and would still
>>>require mostly hard-coding.
I would like to hear someone else's opinion about this.
>> So what? Perl already supports binary extensions. Rumors have it
>> that creating such extensions will be much easier under Perl6.
>
>So where is _any_ advantage?
That if you're concerned about Perl's ability to cope with certain
tasks you can rely on the possibility of writing the problematic code
in some other language you consider to be more well suited to it.
>>>In short: there is nothing that would particularly recommend Perl.
>>
>> Certainly it would be better suited than other languages.
>
>That is a blanket statement for which I see no support at all. You
>have not pointed out anything in which Perl would offer something of
>particular value for TeX programming.
I hope I have done so above...
>> Other than I love it? Well, as I said I think that even in its
[snip]
>How can you love a language that does not even yet exist? Anyway, if
>we want vaporware, there is no shortage of it in the TeX world.
Indeed! The point is however, that I love Perl, I've tried other
languages, but could stick fundamentally only with it. I understand
perfectly well that it's not well suited for _any_ kind of
application, but that's "my" language. Perl6 will be a different
language and most certainly (seeing the discussions about what we know
of it, e.g. on p6l) every Perl programmer will find one of its
charachteristics or another to be unattracting, but it will definitely
still be Perl, so I know I'll love it too. And OTOH I'm eager to see
its new features.
>Anyway, I see quite more compelling arguments for something like ML
>derivatives. Not to a degree that I'd be really gung-ho on some
Huh?!?
If you are thinking of that path because of the side-effects-freedom
implicit in functional languages, and of the inherent reliability,
then I can take your point, because indeed Perl will allow you to
write any bad code you like: it's (_mostly_) up to you to write it
good in the first place.
If you're only saying that because of generic functional languages
features, then indeed Perl6 will support most of them: e.g. currying,
closures (they're _already_ supported too), etc.
>solution there, but at least quite more useful than what I've seen
>from Perl, including Perl6, for TeX-like tasks up to now.
Have you seen much from Perl6 for TeX-like tasks?!?
This is a whole another matter, however: believe me! In fact an actual
issue with Perl is the extreme abundance of extremely bad code lying
around. That's unpleasant, but that's how things are: it may well be
that you're judging Perl from some bad perl code.
For example I gave a peek into texdoctk and I can sincerely tell you
that it's the kind of code for which a newbie could be severely bashed
on clpmisc.
David Kastrup
> On Thu, 30 Dec 2004 15:31:46 +0100, David Kastrup <d...@gnu.org> wrote:
>
>>>>Shrug. There is no particular advantage making Perl particularly
>>>
>>> Well it's well suited for text processing.
>>
>>TeX's input processing has very little to with standard text
>>processing, and in fact I don't see any advantage Perl would offer
>>here. You could probably use Perl's hash tables for control
>>sequences, but that's pretty much all. The table of equivalents does
>>not map comfortably to anything Perl would offer.
>
> Perl parsing already is "a little" different than standard text
> processing.
Well, a chainsaw is quite different from a screwdriver, but that still
does not make it the right tool to drive nails.
Please state _any_ part of implementing TeX where Perl would offer a
significant advantage over hard-coded stuff. And no, the simple
parsing rules of TeX really don't look relevant here.
> Perl6 will go so far that the parser will be radically modifiable at
> compile time. Pardon me if I'm wrong, but this (and other
> charachteristics) will make it much more similar to TeX than
> anything else I can think of...
We are not talking about producing similar problems, we are talking
about _solving_ the same problems. And I don't see why Perl would
help here, and you don't have specified _anything_ of more than
superficial value.
>>> course TeX is a whole another thing. This is why I thought of
>>> Perl6.
>>
>>So what would Perl6 offer that would be less painful than just
>>explicit coding in some more efficient language?
>
> Grammars!
So what do you intend to use them for?
> Regular expressions are already not really much regular any more,
> but they will be made so powerful and different from the current
> behaviour that their name will be changed to "rules". Not only! Just
> like (in some sense) classes group methods, a new concept will be
> introduced: that of a grammar, such that grammars will group rules
> and incidentally this will be much more than a passing similarity.
So what would Perl6 offer for TeX and its ilk that would be less
painful that just explicit coding in some more efficient language?
Please don't just deliver buzzwords, but a concrete implementation
problem that you can solve for TeX.
>>>>suited to Perl, the stuff Perl offers for parsing and scanning is
>>>>not well-suited for TeX, the main control structures and concepts
>>>>in TeX (optimization and parallel execution, which are mostly
>>>>hard-coded in current TeX) don't map well to Perl and would still
>>>>require mostly hard-coding.
>
> I would like to hear someone else's opinion about this.
How about your own? Pick any nontrivial part from "TeX, the Program"
or a useful significant extension for it and develop an argument why
this particular part would be much more naturally expressed, coded and
managed in Perl6. By sketching the outline in Perl6 as opposed to
Pascal.
>>> So what? Perl already supports binary extensions. Rumors have it
>>> that creating such extensions will be much easier under Perl6.
>>
>>So where is _any_ advantage?
>
> That if you're concerned about Perl's ability to cope with certain
> tasks you can rely on the possibility of writing the problematic
> code in some other language you consider to be more well suited to
> it.
C interfaces with everything, too. I don't need Perl6 for that.
>>>>In short: there is nothing that would particularly recommend Perl.
>>>
>>> Certainly it would be better suited than other languages.
>>
>>That is a blanket statement for which I see no support at all. You
>>have not pointed out anything in which Perl would offer something of
>>particular value for TeX programming.
>
> I hope I have done so above...
I don't see where. You are giving a few buzzwords about some areas
which you think might be relevant to TeX, but don't point out why and
where.
> Have you seen much from Perl6 for TeX-like tasks?!?
>
> This is a whole another matter, however: believe me!
You are free to code parts of TeX in Perl6 (like the TeX parser) to
demonstrate the superiority of it for this task.
Michele Dondi
>I don't see where. You are giving a few buzzwords about some areas
>which you think might be relevant to TeX, but don't point out why and
>where.
Well, I pointed out all that I knew. And it seemed to me to be
relevant. But due to your hugely superior knowledge (no joke
intended), well at least about TeX, I'll take your word for it. I
don't really know what I could add.
>You are free to code parts of TeX in Perl6 (like the TeX parser) to
>demonstrate the superiority of it for this task.
You bet I'd do it, if only I had the necessary skills and time and...
oh, but wait a minute: I will certainly do it - just gimme a working
Perl6 compiler!! ;-)
Jon Ericson
> First of all sorry for replying so late. I had originally
> crossposted to clpmisc to hear the cmts from other contributors
> there, but it seems it hasn't attracted much people for which I see
> two main reasons: (i) people there (here) are more concerned with
> how to do things in perl than in speculative issues about Perl, (ii)
> the subject line was not effective at all. So I changed it,
> something I should have done in the first place (interested readers
> can check the original thread for reference)...
Add: (iii) it's not entirely clear what is being proposed. I *think*
the idea is to implement the tex program in Perl6, in which case I'm
not sure what the advantage would be.
On the other hand, I can see an advantage in replacing (or at least
augmenting) the TeX macro system with something more perlish. But we
already have PerlTeX (on CTAN at macros/latex/contrib/perltex/), which
scratches that itch (at least for me).
Jon
Michele Dondi
<Jon.E...@jpl.nasa.gov> wrote:
>> something I should have done in the first place (interested readers
>> can check the original thread for reference)...
>
>Add: (iii) it's not entirely clear what is being proposed. I *think*
>the idea is to implement the tex program in Perl6, in which case I'm
>not sure what the advantage would be.
There's been some talking in the past about limitations of current TeX
engine(s), hypothetical replacements and hypothetical possibilities
for the actual choice of a language for the implementation, always
taking into account the peculiarities of TeX that indeed would most
probably still be there in any "replacement".
Now it occurs to me that (i) Perl6 will be somewhat similar to TeX in
that it will allow the parser to be configurable at compile time, i.e.
it will allow its grammar to be changed on the fly and (ii) it will be
powerful enough to parse at least one language of that complexity:
namely, itself. Please note that this won't be implemented by means of
some exotic as hoc code, but by means of a series of basic features of
the language (rules/grammars).
Now what I was proposing was a highly theoretical (call it vaporware
if you prefer) discussion about wether Perl6 could be a suitable
language for such a TeX-like program or TeX successor.
Of course Perl6 itself or a suitably restricted subset of it may
become the basis for the macro expansion language itself.
>On the other hand, I can see an advantage in replacing (or at least
>augmenting) the TeX macro system with something more perlish. But we
>already have PerlTeX (on CTAN at macros/latex/contrib/perltex/), which
>scratches that itch (at least for me).
Of course I've tried PerlTeX ("obviously!"), but it wouldn't be too
bad to have a tighter integration, especially taking into account how
much clearer/easier/more powerful _well written_ Perl code is if
compared to the sort of technicalities required to perform even
seemingly simple tasks with TeX.
It was just my opinion, David's opinion is different, and I'm
definitely taking it into account by virtue of his immense knowledge
about TeX. I am still under the impression that he doesn't really know
(please do not take this as an ad homonem argument) about Perl, not to
say Perl6. In particular the claim that Perl wouldn't be well suited
at handling lists IMHO is not well founded. Oh and while we're here
not only Perl6 will have a better support in this sense, but it will
also have -amongst many other things- real macros a la lisp.