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.
