Re: PDD 2, vtables

Front page | perl.perl6.internals | Postings from February 2001

From:

Tim Bunce

Date:

February 7, 2001 03:23

Subject:

Re: PDD 2, vtables

Message ID:

20010207111553.I12560@ig.co.uk

On Tue, Feb 06, 2001 at 12:28:23PM -0500, Dan Sugalski wrote:
> At 11:26 AM 2/6/2001 +0000, Tim Bunce wrote:
> >[First off: I've not really been paying attention so forgive me if I'm
> >being dumb here.  And many thanks for helping to drive this forwards.]
> >
> >On Mon, Feb 05, 2001 at 05:14:44PM -0500, Dan Sugalski wrote:
> > >
> > > =head2 Core datatypes
> > >
> > > For ease of use, we define the following semi-abstract data types
> >
> >Probably worth stating upfront that it'll be easy to add new types
> >to avoid people argusing for their favorite type to be added here.
> 
> I'm not sure it should be--that'd mean extending the vtables in ways they 
> have little room to grow. Adding new perl datatypes is easy, adding new 
> low-level types is harder.

That's pretty much what I meant. I think it's worth saying.

> > > =item INT
> > > =item NUM
> > > =item STR
> > > =item BOOL
> >
> >What about references?
> 
> Special type of scalar, not dealt with here.

But should be at least mentioned.

> > > =item UTF-32 string
> > > =item Native string
> > > =item Foreign string
> >
> >I'm a little surprised not to see UTF-8 there, but since I'm also
> >confused about what Native string and Foreign string are I'll skip it.
> >Except to say that some clarification here may help, and explicitly
> >mentioning UTF-8 (even to say it won't be a core type and provide a
> >reference to why) would be good.
> 
> I didn't put UTF-8 in on purpose, because I'd just as soon not deal with it 
> internally. Variable length character data's a pain in the butt, and if we 
> can avoid having the internals deal with it except as a source that gets 
> converted to UTF-32, that's fine with me.

I agree with Branden that a default 4x memory bloat would not be popular.

> The native and foreign string data types were an attempt to accommodate 
> UTF-8, as well as ASCII and EBCDIC character data. One of the three will 
> likely be the native type, and the rest will be foreign strings. I'm not 
> sure if perl should have only one foreign string type, or if we should have 
> a type tag along with the other bits for strings.

Umm, one way or another I suspect UTF-8 will be in there.

> > > =item is_same
> > >
> > >    BOOL               is_same(PMC1, PMC2[, key]);
> > >
> > > Returns TRUE if C<PMC1> and C<PMC2> refer to the same value, and FALSE
> > > otherwise.
> >
> >I think that needs more clarification, especially where they are of
> >different types. Contrast with is_equal() below.
> 
> If they're different types they can't be the same. This would be used to 
> check if two references have the same referent, or if two magic variables 
> (database handles, say) pointed to the same thing.

Okay, so say so in the PPD. "refer to the same value" isn't very clear
(the word value is probably the problem).

> > > =item concatenate
> > >
> > >    void               concatenate(PMC1, PMC2, PMC3[, key]); ##
> > >
> > > Concatenates the strings in C<PMC2> and C<PMC3>, storing the result in
> > > C<PMC1>.
> >
> >and insert (ala sv_insert)  etc?
> 
> Hadn't considered them. Care to elaborate on the etc?

Er, I haven't looked at sv.c for ages but basically all the kinds of
string manipulations that ended up in there for good reason will
probably need to be in perl6. sv_insert is a good example (and possibly
the only one :-)

> > > =item logical_or
> > > =item logical_and
> > > =item logical_not
> >
> >Er, why not just use get_bool? The only reason I can think of is to
> >support three-value-logic but that would probably be better handled
> >via a higher-level overloading kind of mechanism. Either way, clarify.
> 
> Well, there's overloading. Plus the potential that a class will do 
> something odd with it--if you || on two custom arrays in list context you 
> might get an array with each pair (left[0] || right [0] and so on) 
> logically or'd.

Okay, don't forget xor then :)

> > > =item match
> > >
> > >    void               match(PMC1, PMC2, REGEX[, key]);
> > >
> > > Performs a regular expression match on C<PMC2> against the expression
> > > C<REGEX>, placing the results in C<PMC1>.
> >
> >Results, plural => container => array or hash. Needs clarifying.
> 
> Yep, especially since I'd considered tossing the match destination 
> entirely. (Though that means special variables, and I'm not sure I want to 
> go there) It'll likely just return true or false. I'll rethink it.

A BOOL return would be good. But "placing the results in C<PMC1>" is
also good (assuming 'results' are equiv to $1, $2 etc in perl5).

> > > =head1 REFERENCES
> > >
> > > PDD 3: Perl's Internal Data Types.
> >
> >Some references to any other vtable based languages would be good.
> >(I presume people have looked at some and learnt lessons.)
> 
> Alas not. This is pretty much head of zeus stuff, modulo some ego. (Mine's 
> not *that* big...)

:-)

Without studying history we may be doomed to repeat it.

So can anyone point to vtable based language implementations?

Tim.