Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion PMCs: Should We Use Them?

Newsgroups: perl.perl6.internals
Path: g2news1.google.com!news3.google.com!newsfeed.stanford.edu!nntp.perl.org
Return-Path: <l...@toetsch.at>
Mailing-List: contact perl6-internals-h...@perl.org; run by ezmlm
Delivered-To: mailing list perl6-intern...@perl.org
Received: (qmail 31547 invoked from network); 7 Jul 2005 15:53:57 -0000
Received: from x1a.develooper.com (HELO x1.develooper.com) (216.52.237.111)
  by lists.develooper.com with SMTP; 7 Jul 2005 15:53:57 -0000
Received: (qmail 10329 invoked by uid 225); 7 Jul 2005 15:53:56 -0000
Delivered-To: perl6-intern...@perl.org
Received: (qmail 10324 invoked by alias); 7 Jul 2005 15:53:56 -0000
X-Spam-Status: No, hits=-2.6 required=8.0
	tests=BAYES_00
X-Spam-Check-By: la.mx.develooper.com
Received-SPF: neutral (x1.develooper.com: local policy)
Received: from warsl404pip8.highway.telekom.at (HELO email.aon.at) (195.3.96.102)
    by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Thu, 07 Jul 2005 08:53:51 -0700
Received: (qmail 1746 invoked from network); 7 Jul 2005 15:53:41 -0000
Received: from m2186p000.adsl.highway.telekom.at (HELO lux.leo.home) ([80.123.17.32])
          (envelope-sender <l...@toetsch.at>)
          by smarthub75.highway.telekom.at (qmail-ldap-1.03) with SMTP
          for <m...@diephouse.com>; 7 Jul 2005 15:53:41 -0000
Received: from toetsch.at (giga.leo.home [192.168.1.129])
	by lux.leo.home (Postfix on linux 2.0.36 (i386)) with ESMTP
	id 220C9118023; Thu,  7 Jul 2005 17:53:42 +0200 (MEST)
Message-ID: <42CD50DC.4030108@toetsch.at>
Date: Thu, 07 Jul 2005 17:57:16 +0200
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3
X-Accept-Language: en
MIME-Version: 1.0
To: m...@diephouse.com
Cc: Chip Salzenberg <c...@pobox.com>,
	Perl 6 Internals <perl6-intern...@perl.org>
Subject: Re: PMCs: Should We Use Them?
References: <198c873805070708297e38377a@mail.gmail.com>
In-Reply-To: <198c873805070708297e38377a@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Approved: n...@nntp.perl.org
From: l...@toetsch.at (Leopold Toetsch)

Matt Diephouse wrote:
> Dan wrote an entry on his blog yesterday entitled "WWIT: Universal bytecode":
> 
>     http://www.sidhe.org/~dan/blog/archives/000421.html
> 
> In it, he talks (surprise, surprise) about being able to run bytecode
> across machines without the need of a compiler. If you look at the
> comments, I asked what this meant for PMCs. As it currently stands,
> many of the languages currently targeting Parrot would need their PMCs
> distributed in order to run any programs written in that language.

Well, if you have some mixed environment, you'd probably build parrot on 
all machines with the PMC's needed. Something like:

   perl Configure.pl --with-tcl --with-python

to get these PMCs built on it.

> Are there any thoughts from the new powers that be? Should PMCs be
> avoided when possible? Should there be PIR versions of the PMCs
> available for distributing bytecode? Should as much functionality as
> possible be put into the core PMCs?
> 
> I'd like the ability to distribute bytecode without PMCs; I think it's
> something worth working for. What's the best way to make this work in
> light of PMCs?

I still like to unify ParrotObjects and PMCs more. An Integer PMC 
shouldn't really be much different then a instantiated object of a 
closed ParrotClass with one attribute - the native int value.
When that is done, there is no physical difference between a builtin PMC 
and a class built in a PIR module, so that you can mix these two 
depending on their availability.

leo