Basics of the base PMC class set
Dan Sugalski
the repository over the next day or so. In addition to what's
hopefully a sane example of using morph (which, granted, has a
somewhat limited useful range, but...) I'm going to formally
establish a basic set of parrot PMC classes. We're going to now have:
Undef - The undefined value. Looks like 0, 0.0, false, or the empty
string, depending on how you peer at it. Can transform into any other
type. Assignment of an boolean, integer, float, bignum, or string
turns it into a PMC of type Boolean, Integer, Float, BigNum, or
String.
Boolean - Basic true/false PMC
Integer - Basic integer.
Float - Basic floating point.
BigNum - Basic extended-precision number
String - Basic string
The Boolean, Integer, Float, BigNum, and String types (and yes,
BigNum and String don't exist. Yet) maintain their types and
autoconvert incoming data, Undef morphs itself to the destination
type and goes from there.
These six types will form the basic scalar types for parrot. We'll
work on formally defining them, then move on to the aggregate (hash &
array) types and the IO & event bits. (And no, I've not forgotten
events, IO, or (unfortunately) strings. I'm hoping to overwhelm Leo
for when he gets back. Yeah, that's the ticket! :)
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Matt Fowles
Speaking of basic PMC types, I remember a bunch of basic array PMCs that
were discussed recently, some for each register type, some which
autovivified, some which didn't etc. I believe that a stringarray was
actually inserted (although currently it just extends perlarray). I
currently have a prodigious amount of free time and would be willing to
work on such things but am new to the creation of PMCs and am uncertain
of the exact desired semantics. If anyone would like to give me a
little nudge, I would be more than willing to trudge through much of the
grunt work...
Matt
Dan Sugalski wrote:
> Just to let everyone know, I'm going to make a few minor changes to
> the repository over the next day or so. In addition to what's
> hopefully a sane example of using morph (which, granted, has a
> somewhat limited useful range, but...) I'm going to formally establish
> a basic set of parrot PMC classes. We're going to now have:
>
> Undef - The undefined value. Looks like 0, 0.0, false, or the empty
> string, depending on how you peer at it. Can transform into any other
> type. Assignment of an boolean, integer, float, bignum, or string
> turns it into a PMC of type Boolean, Integer, Float, BigNum, or String.
>
> Boolean - Basic true/false PMC
>
> Integer - Basic integer.
>
> Float - Basic floating point.
>
> BigNum - Basic extended-precision number
>
> String - Basic string
>
> The Boolean, Integer, Float, BigNum, and String types (and yes, BigNum
> and String don't exist. Yet) maintain their types and autoconvert
> incoming data, Undef morphs itself to the destination type and goes
> from there.
>
> These six types will form the basic scalar types for parrot. We'll
> work on formally defining them, then move on to the aggregate (hash &
> array) types and the IO & event bits. (And no, I've not forgotten
> events, IO, or (unfortunately) strings. I'm hoping to overwhelm Leo
> for when he gets back... :)
Dan Sugalski
>All~
>
>Speaking of basic PMC types, I remember a bunch of basic array PMCs
>that were discussed recently, some for each register type, some
>which autovivified, some which didn't etc. I believe that a
>stringarray was actually inserted (although currently it just
>extends perlarray). I currently have a prodigious amount of free
>time and would be willing to work on such things but am new to the
>creation of PMCs and am uncertain of the exact desired semantics.
>If anyone would like to give me a little nudge, I would be more than
>willing to trudge through much of the grunt work...
Yep, I think we were going for
(String|Integer|Float|PMC|BigNum|Boolean)Array classes with a
Resizeable variant. The base version should be of fixed size, while
the Resizeable version should change size to fit the number of
referenced elements. (I don't remember us ever coming up with a
better name than Resizeable, so that'll do)
The semantics are simple--the array should store the named things,
and stores of other types should autoconvert. Fetches should all
convert properly. If you want to get fancy internally right now...
cool. If not, that's fine too, we can always get more space-efficient
later once we've got things that work.
Bernhard Schmalhofer
> I'm going to formally establish a basic set of
> parrot PMC classes. We're going to now have:
>
> Undef - The undefined value. Looks like 0, 0.0, false, or the empty
> string, depending on how you peer at it. Can transform into any other
> type. Assignment of an boolean, integer, float, bignum, or string turns
> it into a PMC of type Boolean, Integer, Float, BigNum, or String.
>
> Boolean - Basic true/false PMC
>
> Integer - Basic integer.
>
> Float - Basic floating point.
>
> BigNum - Basic extended-precision number
>
> String - Basic string
>
> The Boolean, Integer, Float, BigNum, and String types (and yes, BigNum
> and String don't exist. Yet) maintain their types and autoconvert
> incoming data, Undef morphs itself to the destination type and goes from
> there.
Hi,
how about having complex numbers as another basic PMC?
At least QCL, http://tph.tuwien.ac.at/~oemer/qcl.html, C99 and PDL,
http://pdl.perl.org/, have them as a basic type.
CU, Bernhard
--
**************************************************
Bernhard Schmalhofer
Senior Developer
Biomax Informatics AG
Lochhamer Str. 11
82152 Martinsried, Germany
Tel: +49 89 895574-839
Fax: +49 89 895574-825
eMail: Bernhard.S...@biomax.com
Website: www.biomax.com
**************************************************
Dan Sugalski
>Dan Sugalski wrote:
>> I'm going to formally establish a basic set of
>> parrot PMC classes. We're going to now have:
>>
>> Undef - The undefined value. Looks like 0, 0.0, false, or the empty
>> string, depending on how you peer at it. Can transform into any other
>> type. Assignment of an boolean, integer, float, bignum, or string turns
>> it into a PMC of type Boolean, Integer, Float, BigNum, or String.
>>
>> Boolean - Basic true/false PMC
>>
>> Integer - Basic integer.
>>
>> Float - Basic floating point.
>>
>> BigNum - Basic extended-precision number
>>
>> String - Basic string
>>
>> The Boolean, Integer, Float, BigNum, and String types (and yes, BigNum
>> and String don't exist. Yet) maintain their types and autoconvert
>> incoming data, Undef morphs itself to the destination type and goes from
>> there.
>
>Hi,
>
>how about having complex numbers as another basic PMC?
>At least QCL, http://tph.tuwien.ac.at/~oemer/qcl.html, C99 and PDL,
>http://pdl.perl.org/, have them as a basic type.
For right now I want to hold off--the basic PMC types all correspond
to a low-level type, and we don't have a complex low-level type. We
can think about complex numbers later on, probably as part of the
library.
Matt Fowles
Are you suggesting that these things use the PMC classes for
String|Integer|Float or should they use STRING|INTVAL|FLOATVAL? Also,
looking through CVS there appears to already be
array.pmc -- basic resizable array
floatvalarray.pmc -- Array of FLOATVALs
intlist.pmc -- Array of integers
stringarray.pmc -- String-only array class (not actually implemented,
just wraps perl array)
I would suggest that we try and remove/unify these things. I was
planning on starting with the non-resizable variants and calling them
Fixed(String|Int|Float|PMC)Array. Then I was going to replace the above
with Resizable(String|Int|Float|PMC)Array. For the moment, I was
planning on using a simple internal array. Once that is working, maybe
I will feel ambitious.
Comments would be most welcome, especially about the whether they should
store values or basic PMC types.
Matt
Dan Sugalski
>All~
>
>Are you suggesting that these things use the PMC classes for
>String|Integer|Float or should they use STRING|INTVAL|FLOATVAL?
Externally? They should use the classes. When you do a get_pmc_keyed
from a StringArray, the result should be a String PMC. Internally...
well, do what you want, but if it were *me* I'd just allocate a big
wad 'o memory and store the low-level types directly. (That is, an
IntArray of size 100 would have a (sizeof INTVAL)*100 byte chunk of
memory with the individual INTVALs stored inside it)
That, though, is an implementation detail. It's perfectly acceptable
to start by wrapping, say, SArray or PerlArray with code that does a
lot of conversions to get going and rework the internals after the
externally visible functionality's working. (Or, more bluntly, I only
care what it looks like to the outside--the inside workings are all
black box)
> Also, looking through CVS there appears to already be
>
>array.pmc -- basic resizable array
>floatvalarray.pmc -- Array of FLOATVALs
>intlist.pmc -- Array of integers
>stringarray.pmc -- String-only array class (not actually
>implemented, just wraps perl array)
>
>I would suggest that we try and remove/unify these things. I was
>planning on starting with the non-resizable variants and calling
>them Fixed(String|Int|Float|PMC)Array. Then I was going to replace
>the above with Resizable(String|Int|Float|PMC)Array. For the
>moment, I was planning on using a simple internal array. Once that
>is working, maybe I will feel ambitious.
As we go along I'm all for getting rid of the cruft that's there
(deleting, renaming, or moving to the library) and get classes/ all
tidied up.
For now lets leave these things alone and get what we want to
explicitly exist existing. Then we can look at the rest of the stuff
and move it out. (Which'll also give folks who're using parrot for
play or whatever time to move off the stuff that's getting tossed)
Leopold Toetsch
> At 2:38 PM +0200 6/11/04, Bernhard Schmalhofer wrote:
>>how about having complex numbers as another basic PMC?
>>At least QCL, http://tph.tuwien.ac.at/~oemer/qcl.html, C99 and PDL,
>>http://pdl.perl.org/, have them as a basic type.
As well as Python.
> For right now I want to hold off--the basic PMC types all correspond
> to a low-level type, and we don't have a complex low-level type. We
> can think about complex numbers later on, probably as part of the
> library.
Think faster :) I think that a complex PMC type is in order. We can move
it to a Python library later, when we do classes cleanup.
> Dan
leo