All~
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 wrote:
At 3:56 PM -0500 6/10/04, Matt Fowles wrote:
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.
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... :)
