On Thu, Mar 07, 2002 at 09:50:01PM +0000, Tim Bunce wrote: > On Thu, Mar 07, 2002 at 01:48:49PM -0500, Dan Sugalski wrote: > > Someone said: > > > > >First, there are basic native types such > > >as num, int, and string, which I'm perfectly fine with. But what bothers > > >me is the fact that bigint's and bignum's are being given a special place > > >in the vtable. > > > > Why? They're base types, really. I'd like to add in support for > > complex numbers too, but I've not yet gone that far. Might next week, > > you never know. > > Why? > > Why should complex numbers be base types?
I really don't think they should. They are used by very few applications, in reality. Most people (of the few that use them at all) who use complex numbers, are interested in speed above almost everything. They will mostly be using C, C++ or Fortran. A language like Perl or Python is just not suitable. In fact, in all the cases I ever dealt with, even C++ was ruled out as being too slow (compared to C). > Why should bigint's and bignum's be given special treatment? > (I understand Brent's point that you want to overflow to bigint's > and bignum's, but that doesn't require special treatment, only that > they be available for creation.) I think BigInt and BigNum are examples of a special sort of type, that which is neither built-in, nor an extension. Consider a hypothetical situation, where we are converting from a language (like Java) which has a very fixed idea of how wide its numeric types are. The type we are dealing with there is AlmostJavaInt - a Parrot representation of a type native to another language. If we want to add that to a SomeLanguageWhichDeterminesWidthsFromHardwareInt then we have to somehow gate the type - by using, essentially a BigInt. This may end up meaning that they have to go in the core, for this reason. Of course, I could be misunderstanding how we're going to handle conversion between types like the ones above. > If parrot is supposed to be fully extensible then let it "eat it's > own dog food". It should use the extensibility it offers to others > to implement it's own extensions. Any special treatment of extra > internal types implies that that special treatment isn't available > to types added at runtime. If we are actually going to be able to support more than one high-level language, I'd say this was pretty much essential. [ Not meaning to open a can of worms, but: ] Has anyone implemented a mapping into Parrot from anything which isn't Perl yet? Ben
