From: roberson@... (Walter Roberson)
Date: 2002-11-08T16:31:09+09:00
Subject: Re: A vision for Parrot

In article <aqbimo$a36$1@news.ox.ac.uk>, Frodo Morris  <""> wrote:
:Perdantick bast.  :-)

Hmmm, according to OED, "bast" means "sanctuary, refuge, asylum".

:Imagine if parrot could understand all currently- and popularly- 
:implemented interpreted languages.

Such as Forth, Word Perfect Macros, Microsoft Visual Basic,
and Befunge?? (You haven't been very specific on the meaning of
'popularly'.)


Now, Parrot is intended for interpreted languages, right? And
the fundamental feature of such languages is that you should
be able to compute a string and then execute the string as
a statement. So Parrot will have to know how to execute statements
in arbitrary source languages. This means that it isn't enough
to have a (say) bash-to-parrot translator that translates
the program and hands it off to parrotd: the entire translator
is going to have to be input along with the translated source.

This indirectly raises an interesting point. If parrotd is glued into
the operating system as part of exec() as has been proposed (as opposed
to the counter proposal to just liet #!  do its standard job) then the
implication is that there is only one parrot implimentation per system.
How would one then test new versions of Parrot? With #! it's easy: you
just name the path to the alternative interpreter and the kernel
invokes it. But if parrotd is built right into exec() then in order to
support multiple versions of Parrot, you would have to build the new
versions -in- Parrot and pass them in as yet another layer of
interpreter. e.g., parrotd version 6.302 is running and it has been
passed a copy of the bash2parrot 4.19 translator in case it needs to
interpret a computed string that invokes a program that needs to layer
on the experimental parrotd 6.4.9 interpreter that has to be passed the
perl2parrot translator in case it needs to interpret a computed string
that invokes a program that needs to have -another copy- of parrotd
6.302 layered on [you can't count on parrotd 6.4.9 running parrotd
6.302 programs the same way that parrotd 6.302 would run them] that has
the <etc.> interpeter layered on to run <etc.>.

Scheme is right at home at dealing with these kinds of layering issues,
using a process called "reflection" [well developed by Brian Reid and
Jeem Desriviers]. They aren't straight-forward issues: think about
debugging, and think about re-entrancy, and think about problems in
cross-layer pollution -- you don't want a wild pointer in the fifth
layer down to affect your third layer, right?


Speaking of layers: I take it that some thought has been put into
how to do operating-system escapes? So that one can (for example)
handle graphics? Or even just sockets? Seeing as some of the most popular
interpreted languages are by no means restricted to text-only
and have networking capabilities? But of course the appropriate calls
could come within one of the computed strings, so any escape cannot
be absolute and must instead be handled via the interpretation layer
(c.f. the above in which I showed that parrotd must be built in
Parrot if you want parrotd to be handled at the exec() level...)
--
   "The human genome is powerless in the face of chocolate."
   -- Dr. Adam Drewnowski