Message from discussion
keyed vtables and mmd
Newsgroups: perl.perl6.internals
Path: archiver1.google.com!news1.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 12016 invoked from network); 28 Apr 2004 18:38:40 -0000
Received: from x1.develooper.com (63.251.223.170)
by onion.develooper.com with SMTP; 28 Apr 2004 18:38:40 -0000
Received: (qmail 15079 invoked by uid 225); 28 Apr 2004 18:38:40 -0000
Delivered-To: perl6-intern...@perl.org
Received: (qmail 15054 invoked by alias); 28 Apr 2004 18:38:33 -0000
X-Spam-Status: No, hits=0.0 required=7.0
tests=
X-Spam-Check-By: la.mx.develooper.com
Received: from mail.nextra.at (HELO mail.nextra.at) (195.170.70.67)
by la.mx.develooper.com (qpsmtpd/0.27.1) with ESMTP; Wed, 28 Apr 2004 11:38:32 -0700
Received: from lux.leo.home (at24a01-dial-178.nextranet.at [195.170.73.178])
by mail.nextra.at (20030919/20030919/nextra) with ESMTP id i3SIcRAL029551;
Wed, 28 Apr 2004 20:38:28 +0200 (MEST)
Received: from thu8.leo.home (thu8.leo.home [192.168.1.5])
by lux.leo.home (Postfix on linux 2.0.36 (i386)) with ESMTP
id 29714118024; Wed, 28 Apr 2004 20:34:30 +0200 (MEST)
Received: (from lt@localhost)
by thu8.leo.home (8.10.2/8.10.2/SuSE Linux 8.10.0-0.3) id i3SIL4t23895;
Wed, 28 Apr 2004 20:21:04 +0200
Message-ID: <200404281821.i3SIL4t23895@thu8.leo.home>
To: d...@sidhe.org (Dan Sugalski)
Subject: Re: keyed vtables and mmd
In-Reply-To: <a06100507bcb57c1f2582@[10.0.1.3]>
References: <a06100507bcb57c1f2582@[10.0.1.3]>
Reply-To: l...@toetsch.at
Cc: perl6-intern...@perl.org
Date: Wed, 28 Apr 2004 20:21:04 +0200
X-Spam-Rating: onion.develooper.com 1.6.2 0/1000/N
Approved: n...@nntp.perl.org
From: l...@toetsch.at (Leopold Toetsch)
Dan Sugalski <d...@sidhe.org> wrote:
> We toss the keyed variants for everything but get and set. And... we
> move *all* the operator functions out of the vtable and into the MMD
> system. All of it. Math, logical ops, bit ops... the works. All
> that's left are the gets, sets, and meta-information entries. (Type,
> class, elements, and suchlike stuff) We rework the current pmc
> processor to take the entries that are getting tossed and
> automatically add them to the MMD tables on PMC load instead.
Sounds good. C<add_p_p_p> and friends isn't really fast now due to some
type checks. And that's only for Perl types. Would be much more for
multiple HLL. Putting in specialized MMD functions for each type
combination is better, but can cause huge tables for too much
[types*vtable_entries]**2.
But anyway I think it's the right thing todo.
But we have to consider "utility" PMCs like C<Env> or C<*struct> that
don't really match the concept of MMD.
leo