Parrot
Ian Bell
multi-platform languages. Any plans for Tcl/Tk to adopt/exploit it?
Ian
Uwe Klein
Donal K. Fellows
> I just read an article about Parrot being an ideal VM for interpreted
> multi-platform languages. Any plans for Tcl/Tk to adopt/exploit it?
Well, I'm not too sure about "ideal" but there's been work done on
ParTcl that you might be interested in. To be fair, it's not yet
anywhere close to being the mainline Tcl interpreter, but it is an
interesting piece of work.
I'd probably feel the same way about an implementation of Tcl in C#.NET
(As usual, there are links and background material in the Wiki.)
Donal.
Ian Bell
> Ian Bell wrote:
>> I just read an article about Parrot being an ideal VM for interpreted
>> multi-platform languages. Any plans for Tcl/Tk to adopt/exploit it?
>
> Well, I'm not too sure about "ideal" but there's been work done on
> ParTcl that you might be interested in.
My inclusion of the word 'ideal' was prompted by Parrot's aim of being
platform agnostic unlike java and .net for example i.e code should run
unmodified on any parrot platform.
Ian
Ian Bell
Doh! For once I thought this would be so new I did not even bother to check
the wiki ;-)
Ian
David N. Welton
> Doh! For once I thought this would be so new I did not even bother to check
> the wiki ;-)
Parrot's been out there for a numbe of years and hasn't really made that
much progress, from what I gather.
--
David N. Welton
- http://www.dedasys.com/davidw/
Linux, Open Source Consulting
- http://www.dedasys.com/
Ian Bell
> Ian Bell wrote:
>
>> Doh! For once I thought this would be so new I did not even bother to
>> check the wiki ;-)
>
> Parrot's been out there for a numbe of years and hasn't really made that
> much progress, from what I gather.
>
I mistakenly thought it was new because a) I had not heard of it and b)
there is an article on it in this month's Linux Format.
Ian
Cameron Laird
It was real as a project at least by the time of the Little
Languages workshop at MIT in 2001. There had been quite a
bit of chatter since the previous summer.
Gerry Snyder
>
> Parrot's been out there for a numbe of years and hasn't really made that
> much progress, from what I gather.
>
All statements to the effect that this parrot is a going concern are
from this point inoperative.
Gerry
Ian Bell
You mean........... it's an ex-parrot????
Ian
Donal K. Fellows
> You mean........... it's an ex-parrot????
No, it's just pining for the fjords.
(No, I've no idea how the integration of Parrot with Qt is going...)
Donal.
Donal K. Fellows
> My inclusion of the word 'ideal' was prompted by Parrot's aim of being
> platform agnostic unlike java and .net for example i.e code should run
> unmodified on any parrot platform.
That was always an assertion about Parrot that I didn't like. This is
because it needs to be qualified with (at least) one of two assertions:
1: "... as long as you ignore the large platform-specific libraries
that we are doing foreign function calls into", and/or
2: "... as long as you accept that we're going to be dog slow for a lot
of stuff by virtue of having to duplicate what compiled C/C++ has
done for years but with less optimization".
Maybe I'm overly cynical, but I view generic bytecodes as something of a
waste of time. If you're going to do a bytecode system, you should at
least make sure it is specialized to overcoming the bottlenecks that you
measure. (You did do some bottleneck analysis, yes?)
Donal (sings "Parrot is a WOMBAT, Parrot is a WOMBAT, ...")
Donal K. Fellows
> My inclusion of the word 'ideal' was prompted by Parrot's aim of being
> platform agnostic unlike java and .net for example i.e code should run
> unmodified on any parrot platform.
But you can say that about JVM bytecodes too. In my experience, they're
quite thoroughly platform-agnostic (the same code is a resource-hog on
every platform!) The same might be true of .NET too, but I can't speak
from a position of knowledge there.
Of more interest is the Parrot operating model and the selection of
bytecodes that they've chosen to implement. Apparently, it's supposed to
be a better choice for implementing a dynamic language on top of, though
their model is more of Perl or Python than Tcl. FWIW and AIUI, Tcl tends
to put the cut-points in the API at different levels, with the result
that the bytecode set used by the Tcl core is a better fit for the language.
I can remember when Parrot was starting out, we (the TCT) had a look at
it and decided that it wasn't worth a lot of our time, but that if any
third-party (Will Coleida as it happens) wanted to work on it, we'd
happliy see how they got on. Myself, I think Will should have submitted
a talk on what he's been up to to the Tcl conference. :-)
In any case, given all the above, "ideal" really needs to be taken with
a large pinch of salt and a bunch of side conditions that explain what
assumptions you are making. OK, it makes the story more complicated and
less of a pithy one-liner for USENET, but it has the advantage of making
the story *real*.
Donal.
Coke
a while. I've recently picked up a few more committers, which has
improved both the quality of our existing code, and the number of
implemented features.
Current state: Trying to target 8.5 functionality
- Only some of the builtins are implemented
- partcl was recently converted from an interpreter to a (naive)
compiler. Of the builtins that are currently implemented, some are
available in an inline-able fashion. You can run partcl with the --pir
command line option to see what PIR code is generated.
- Able to run the cvs-latest tcl test suite, by running the tests
through a naive converter: that yields about 10% pass-rate if you skip
the test-heavy clock. (Obviously we'd like to run the tests natively,
but there are a lot of builtins used in tcltest)
-svn-latest has a few broken tests as a result of switching to the
compiler. Some of these are a result of TODOs in parrot, some are in
partcl itself.
On the short list:
- namespaces (courtesty Matt Diephouse)
-inline [proc] and [expr] (Both of which currently compile into parrot
already, but do so separately from the top level compiler, so their
results do not appear when you dump with --pir)
To see the latest partcl, first get a copy of svn-latest parrot:
http://www.parrotcode.org/source.html
Once you get the parrot source, first build parrot itself (perl
Configure.pl; make). Then, cd to languages/tcl and build partcl (make).
This compiles all the runtime/library code.
To run a .tcl script from that directory, you need parrot:
../../parrot tcl.pbc foo.tcl
I'd of course be interested in feedback, suggestions, and, if at all
possible, patches. =-)
Enjoy.
Ian Bell
To quote from the article in Linux Format:
'Even though Java and .net are cross-platform they don't treat each platform
evenly, so moving to another platform may not work'
which seems a tad vague to me, and
'Also, Java and .net have their own native languages -'
As I said I have zero knowledge in this area but I am not surprised parrot
is yet to make an impact.
Ian
Donal K. Fellows
programmers to (effectively) a very small POSIX subset when interacting
with the rest of the OS. The problem is that the OSes themselves vary
too much and in ways beyond reasonable control. This sucks. But unless
parrot is this restrictive (and I believe it should *not* be; it should
focus on being a useful tool if it wishes to live at all) there will be
inherent unevenness.
Platform Independence? Meet Real Life.
Donal.