Tcl and Parrot (VM for Perl6)?
Mike Greaves
building a new VM, called Parrot, for Perl6. They seem to be claiming
that it is also suitable for languages other than Perl, such as Tcl or
Python. They also claim that it will be fast as hell. See:
http://www.parrotcode.org/
Does anyone here think it would be sensible to replace the Tcl
bytecode compiler with a compiler to Parrot bytecode. I'm an
experienced Tcl programmer, but I really don't know enough about the
Tcl core, or about Parrot, to comment on the feasibility or
desirability of this idea. I assume that it would be lots of work...
Any more informed commentators care to weigh in?
(It occurred to me to cross-post this to comp.lang.perl.*, but I was
afraid of the consequences... ;-)
Mike Greaves
Donal K. Fellows
> As some of you probably know, the folks working on the Perl core are
> building a new VM, called Parrot, for Perl6. They seem to be claiming
> that it is also suitable for languages other than Perl, such as Tcl or
> Python. They also claim that it will be fast as hell.
I know some of the Python people were cooperating, but I'm not aware of any
great collaboration on the Tcl side. Because...
> Does anyone here think it would be sensible to replace the Tcl
> bytecode compiler with a compiler to Parrot bytecode. I'm an
> experienced Tcl programmer, but I really don't know enough about the
> Tcl core, or about Parrot, to comment on the feasibility or
> desirability of this idea. I assume that it would be lots of work...
>
> Any more informed commentators care to weigh in?
The problem is the bytecode sets and semantics are different, very different.
Parrot includes quite a bit of stuff for handling of objects (I believe) whereas
Tcl benefits more from specialised functionality for handling (and avoiding)
shimmering. This puts it into the same class of things as Jacl...
IIRC, there may also issues due to differences in security model. Could be
wrong on that though.
If someone wishes to take this on, essentially as a little research project,
please do not let my comments dissuade you from doing this. It would be very
interesting to see a different perspective on what we are doing.
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- I may seem more arrogant, but I think that's just because you didn't
realize how arrogant I was before. :^)
-- Jeffrey Hobbs <je...@ActiveState.com>
Mike Greaves
> The problem is the bytecode sets and semantics are different, very different.
> Parrot includes quite a bit of stuff for handling of objects (I believe) whereas
> Tcl benefits more from specialised functionality for handling (and avoiding)
> shimmering. This puts it into the same class of things as Jacl...
Thanks very much for the info; I'll have a quick look into some of these issues.
Mike Greaves
Andreas Otto
Hi,
> As some of you probably know, the folks working on the Perl core are
> building a new VM, called Parrot, for Perl6. They seem to be claiming
> that it is also suitable for languages other than Perl, such as Tcl or
> Python. They also claim that it will be fast as hell. See:
> http://www.parrotcode.org/
>
> Does anyone here think it would be sensible to replace the Tcl
> bytecode compiler with a compiler to Parrot bytecode. I'm an
> experienced Tcl programmer, but I really don't know enough about the
> Tcl core, or about Parrot, to comment on the feasibility or
> desirability of this idea. I assume that it would be lots of work...
I have a working Tcl "Compiler" which produce something that I
call "MetaCode" other people call that "ByteCode" or "Intermediate
Language" but this doesn't matter.
http://www.compiler-factory.com
The core is that I use my Meta-Code to create "optimized Tcl" or "C"
with the help of something that I call "Back-End". The goal would
be to use the "MetaCode" and a other "Back-End" to create the perl
bytecode to see what happen.
The core problem is the Tcl "eval" command which has 2 meanings
1) to convert a list into arguments
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
proc OTTO {list} {
global newlist
eval lappend newlist $list
}
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
proc OTTO {cmds} {
eval exec $cmds
}
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
which can be done with a other language too.
2) to evaluate dynamic crated Tcl code like:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
set tclcode "MyCommand $arg1 $arg2; set arg1 nothing"
eval $tclcode
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
which will not work with a non Tcl language.
case 2 is not quite often (if you use plain tcl) and you can ignore
this case but you have to remember it's a big job to do even the basic
stuff
but by the way ( POWER-Tcl ) is much better as perl and python together
( in terms of speed, usability and programming model )
mfg
aotto :)
--
=================================================================
(C) Compiler-Factory, Dipl.-Ing Andreas Otto, Business Solutions
http://www.compiler-factory.com, mailto:in...@compiler-factory.com
C, C++, Java, Tcl, Perl, HTML, DB, Sql, Shell, M4, GUI, Package
Benjamin Goldberg
>
> Hi,
>
> > As some of you probably know, the folks working on the Perl core are
> > building a new VM, called Parrot, for Perl6. They seem to be
> > claiming that it is also suitable for languages other than Perl,
> > such as Tcl or Python. They also claim that it will be fast as
> > hell. See: http://www.parrotcode.org/
> >
> > Does anyone here think it would be sensible to replace the Tcl
> > bytecode compiler with a compiler to Parrot bytecode.
It's not just a question of "would it be sensible?" It's a question of,
would it be useful?" And in this case, I believe that the answer is,
"yes." If you could write a compiler which converts tcl source to perl6
bytecode, and another compiler which converts perl6 bytecode, then you
could have part of your project written by your tcl guy, and another
part written by your perl guy, and both modules would be able to
efficiently be run by one program.
> > I'm an
> > experienced Tcl programmer, but I really don't know enough about the
> > Tcl core, or about Parrot, to comment on the feasibility or
> > desirability of this idea. I assume that it would be lots of
> > work...
>
> I have a working Tcl "Compiler" which produce something that I
> call "MetaCode" other people call that "ByteCode" or "Intermediate
> Language" but this doesn't matter.
>
> http://www.compiler-factory.com
>
> The core is that I use my Meta-Code to create "optimized Tcl" or "C"
> with the help of something that I call "Back-End". The goal would
> be to use the "MetaCode" and a other "Back-End" to create the perl
> bytecode to see what happen.
If you're trying to start with TCL, and make it understand perl, too,
you would want to try and design a second "Back-End" which can
understand perl code, and turn it into tcl Meta-Code.
If you're trying to start with perl, and make it understand tcl, too,
you would want to try and design a second parser which can understand
tcl code, and turn it into perl bytecode.
Besides the fact that perl is much much cooler, I don't see any
advantage of one over the other.
> The core problem is the Tcl "eval" command which has 2 meanings
>
> 1) to convert a list into arguments
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> proc OTTO {list} {
> global newlist
> eval lappend newlist $list
> }
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
> or
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> proc OTTO {cmds} {
> eval exec $cmds
> }
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
> which can be done with a other language too.
Yeah... In perl, it's called "eval" :)
> 2) to evaluate dynamic crated Tcl code like:
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> set tclcode "MyCommand $arg1 $arg2; set arg1 nothing"
> eval $tclcode
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
> which will not work with a non Tcl language.
Erm, perl has this kind of eval, too. It's also called "eval."
> case 2 is not quite often (if you use plain tcl) and you can ignore
> this case but you have to remember it's a big job to do even the
> basic stuff
Or in other words, you can't write a program which does nothing more
than execute metacode/bytecode; you always have to include the whole
parser, because eval needs it.
> but by the way ( POWER-Tcl ) is much better as perl and python
> together ( in terms of speed, usability and programming model )
Sure, and if you believe that, I've got a bridge to sell you :)
Got some benchmarks to prove it?
--
print reverse( ",rekcah", " lreP", " rehtona", " tsuJ" )."\n";
Bob Techentin
news:3C71C14F...@earthlink.net...
>
> If you could write a compiler which converts tcl source to perl6
> bytecode, and another compiler which converts perl6 bytecode, then you
> could have part of your project written by your tcl guy, and another
> part written by your perl guy, and both modules would be able to
> efficiently be run by one program.
You can already do that. Perl is just one of the many little :-)
libraries you can load into Tcl. See libperl at
http://jfontain.free.fr/
Bob
--
Bob Techentin techenti...@mayo.edu
Mayo Foundation (507) 538-5495
200 First St. SW FAX (507) 284-9171
Rochester MN, 55901 USA http://www.mayo.edu/sppdg/
A.M. Kuchling
> Does anyone here think it would be sensible to replace the Tcl
> bytecode compiler with a compiler to Parrot bytecode. I'm an
Perhaps, but it's too early to tell because Parrot is still only a toy
at this stage.
I wrote a crude first cut at a Python-to-Parrot compiler (you can find
it in the Python CVS tree under nondist/sandbox/parrot) that can only
handle integer types and variable assignment. I would have liked to
have implemented a more interesting subset next -- say, supporting
only integers, strings, and simple functions, plus Python's control
structures -- but that's not really possible because there are no
opcodes for storing variables in any sort of memory yet; you have the
32 registers, and that's it. Fill all 32 registers, and there's
little you can do except report a compiler error.
This means that currently no one has ever tried implementing a real
language in Parrot. The source tree includes a little toy language
called Jako that maps very closely to the Parrot VM's opcodes, a toy
version of Perl, and a toy version of Scheme (no 'defun', for
example). None of these are serious-enough implementations so that
you can call the VM seriously tested.
Worse still, people now seem to be hacking on projects that interest
them but don't really advance the VM's usefulness. So, for example,
there are already opcodes for regular expressions, an I/O abstraction
layer, and a JIT compiler for x86 -- but if you can't actually
implement a reasonable language to use them from, all of these
features are pointless. I'm also worried that people are already
succumbing to the lure of premature optimization -- counting the
number of opcodes executed per second, trying to save a pointer
dereference here or there -- before the VM has been shown to be useful
as a language target.
So at this point, there's little for an outsider implementor to do,
unless you want to join the Parrot project and actually implement the
necessary bits of it.
(Hmmm... I should probably write this up as a rant and send it to the
Parrot list.)
--amk (www.amk.ca)
They say the atmosphere there was so full of goodness that evil just
shrivelled up and died. Maybe that's why I never went there.
-- The Doctor, in "The Keeper of Traken"
Andreas Otto
Hi,
>> 2) to evaluate dynamic crated Tcl code like:
>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> set tclcode "MyCommand $arg1 $arg2; set arg1 nothing"
>> eval $tclcode
>> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>>
>> which will not work with a non Tcl language.
>
> Erm, perl has this kind of eval, too. It's also called "eval."
>
>> case 2 is not quite often (if you use plain tcl) and you can ignore
>> this case but you have to remember it's a big job to do even the
>> basic stuff
>
> Or in other words, you can't write a program which does nothing more
> than execute metacode/bytecode; you always have to include the whole
> parser, because eval needs it.
you always have to include the parser because:
1) eval -> work on dynamic code which will created on runtime
2) work with the source(Tcl) or ????(perl) always need the special
interpreter
>
>> but by the way ( POWER-Tcl ) is much better as perl and python
>> together ( in terms of speed, usability and programming model )
>
> Sure, and if you believe that, I've got a bridge to sell you :)
>
> Got some benchmarks to prove it?
http://www.compiler-factory.com/performance-result.html
the only possibility to work together is by using something that
I call "common api's"
example: perl has the better regexp engine
pull the regexp out of perl and put it into a dyn library
-> everybody can use it
possible targets for api's are:
regexp, fileio, gui, system, complex data structure,
if it would be possible to share (and get more time by time) code
would help everybody.
just to get the languages perl,phyton and tcl uses the same basic api's
will do a better job as try to run a tcl written prog in perl
there is one big common thing already available, this is called
C/C++. You can
1) handle pointers
2) call procedures
3) using complex C-Data-Structures
if we have a good working set of apis that would be the right answer
for something M$ calls "multiple language programming" or java
call "class library".
The big battle is not the language the big battle is the library.
Donal K. Fellows
> Fill all 32 registers, and there's
> little you can do except report a compiler error.
There's some CS theory that states that 2 registers (admittedly of unbounded
with; better declare them as BIGINTs) are all you need (along with only two
kinds of instruction, INCrement and DECrement-and-test-for-zero) to implement a
Turing Machine. I wouldn't want to use it as the basis for a scripting language
though.
(In fact, you can even do useful evaluation without any registers using
combinator calculus. But that's even weirder and is only really of use to
people doing those parts of information theory relating to a formal definition
of randomness...)
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- The guy who sells me my audio hardware explained that a computer will never
produce the same level of sound quality that a stereo will b/c stereo have
transistors and sound cards don't. --Matthew Garson <mga...@world.std.com>
Cameron Laird
Donal K. Fellows <fell...@cs.man.ac.uk> wrote:
>"A.M. Kuchling" wrote [about the Parrot VM]:
>> Fill all 32 registers, and there's
>> little you can do except report a compiler error.
>
>There's some CS theory that states that 2 registers (admittedly of unbounded
>with; better declare them as BIGINTs) are all you need (along with only two
>kinds of instruction, INCrement and DECrement-and-test-for-zero) to implement a
>Turing Machine. I wouldn't want to use it as the basis for a scripting language
>though.
>
>(In fact, you can even do useful evaluation without any registers using
>combinator calculus. But that's even weirder and is only really of use to
>people doing those parts of information theory relating to a formal definition
>of randomness...)
.
.
... which happens to interest me.
You're strong with the aphorisms today: "I wouldn't want
to use two registers and two instructions as the basis for
a scripting language.
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
Don Porter
> There's some CS theory that states that 2 registers (admittedly of unbounded
> with; better declare them as BIGINTs) are all you need (along with only two
> kinds of instruction, INCrement and DECrement-and-test-for-zero) to implement
> a Turing Machine. I wouldn't want to use it as the basis for a scripting
> language though.
What luxury! The EEs know that all you really need is a really big pile
of NAND gates, and proper wiring.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Donal K. Fellows
> What luxury! The EEs know that all you really need is a really big pile
> of NAND gates, and proper wiring.
Unless you have an unbounded amount of NANDs, that's (strictly) computationally
less powerful. Of course, you are relying on the timing properties of the gates
when you do that.
Mind you, I once figured out how to build a computer using a really large train
set. IIRC, you needed three different kinds of points:
Simple switched (see diagram: the train pushes the switcher as part of coming
from the right to set what direction you go when you come from the left.)
/ /
____/_/__
_________
Simple sprung (like above, but a spring ensures that trains coming from the
left always go the same way.)
Dual-linked switched (a pair of simple switched points with a joining bar so
that the pair of points are always configured the same way. Also note that
the action of this point configuration can be simulated by an infinite number
of the other two pairs of points.)
Given enough of those (also normal rails) and one engine, you can build a Turing
Machine. However, I don't propose to illustrate this with ASCII graphics in any
newsgroup; the paper version was bad enough and that used a lot of
hard-to-reproduce visual shorthand... :^)
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- If that's dead, sign me up for necrophilia classes.
-- Mark Loy <ml...@iupui.edu>
lvi...@yahoo.com
According to Donal K. Fellows <fell...@cs.man.ac.uk>:
:Mind you, I once figured out how to build a computer using a really large train
:set.
While the referenced posting has little to do with Tcl, perhaps someone
will start a 'Most interesting off topic postings in comp.lang.tcl' gallery
and make certain that this posting is in the initial set of nominations!
--
"I know of vanishingly few people ... who choose to use ksh." "I'm a minority!"
<URL: mailto:lvi...@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
Benjamin Goldberg
>
> Hi,
>
> >> 2) to evaluate dynamic crated Tcl code like:
> >>
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> set tclcode "MyCommand $arg1 $arg2; set arg1 nothing"
> >> eval $tclcode
> >> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> >>
> >> which will not work with a non Tcl language.
> >
> > Erm, perl has this kind of eval, too. It's also called "eval."
> >
> >> case 2 is not quite often (if you use plain tcl) and you can
> >> ignore this case but you have to remember it's a big job to do
> >> even the basic stuff
> >
> > Or in other words, you can't write a program which does nothing more
> > than execute metacode/bytecode; you always have to include the whole
> > parser, because eval needs it.
>
> you always have to include the parser because:
>
> 1) eval -> work on dynamic code which will created on runtime
>
> 2) work with the source(Tcl) or ????(perl) always need the special
> interpreter
2 is not needed since the source code [whether Tcl or Perl] is no longer
needed once it's been parsed into metacode/bytecode.
> >> but by the way ( POWER-Tcl ) is much better as perl and python
> >> together ( in terms of speed, usability and programming model )
> >
> > Sure, and if you believe that, I've got a bridge to sell you :)
> >
> > Got some benchmarks to prove it?
>
> http://www.compiler-factory.com/performance-result.html
This only compares different versions of Tcl to each other.
It does not compare Tcl with Perl or with Python.
> the only possibility to work together is by using something that
> I call "common api's"
>
> example: perl has the better regexp engine
>
> pull the regexp out of perl and put it into a dyn library
> -> everybody can use it
Already been done, it's called "PCRE"
> possible targets for api's are:
>
> regexp, fileio, gui, system, complex data structure,
I already mentioned PCRE. Perl5.6's fileio is just a wrapper around
stdio, I don't know if the "perlio" stuff from perl5.6 can be/will be
seperated into a library. Perl doesn't have a builtin gui any more than
Tcl does ... one generally uses Tk. What do you mean by "system" and
"complex data structures?" Perl's data structures are relatively
simple: There are scalars, arrays, lookups. That's just about it (I'll
ignore typeglobs and references to basic types as an implementation
detail)
> if it would be possible to share (and get more time by time) code
> would help everybody.
>
>
> just to get the languages perl,phyton and tcl uses the same basic
> api's will do a better job as try to run a tcl written prog in perl
>
> there is one big common thing already available, this is called
> C/C++. You can
>
> 1) handle pointers
> 2) call procedures
> 3) using complex C-Data-Structures
>
> if we have a good working set of apis that would be the right answer
> for something M$ calls "multiple language programming" or java
> call "class library".
>
> The big battle is not the language the big battle is the library.
Well, you're right it's not the language itself... but it's not really
the APIs, either. It's getting everything to play nicely with each
other.
It's things like garbage collection, and things like different languages
each wanting to use it's own malloc library, and garbage collection, and
signal handlers, and threading, and so on and so forth.