On Thu, Nov 07, 2002 at 04:16:50PM -0500, Dan Sugalski wrote: : At 8:29 PM +0100 11/7/02, Leopold Toetsch wrote: : >Michael Lazzaro wrote: : > : >> : >>On Thursday, November 7, 2002, at 06:36 AM, Austin Hastings wrote: : >> : >>>For 'bit', the key value is (eenie, meenie, ...) '1'. : > : > : >> From A2 we have: : >> : >>"Run-time properties really are associated with the object in : >>question, which implies some amount of overhead. For that reason, : >>intrinsic data types like C<int> and C<num> may or may not allow : >>run-time properties. : > : > : >From E2: a C<int> will never have attributes or promote to an object. : : Attributes aren't properties. : : Basically anything you can potentially find in a symbol table or : lexical scratchpad will potentially be able to have a property : attached to it. The only way that we'll be able to reasonably : restrict (and optimize) the use of low-level data types is to keep : them out of the symbol tables, which then makes using them in string : evals and suchlike things somewhat problematic. (And not allowing : properties on them will require us to throw runtime errors) It'll : also make passing them in as parameters interesting, as we'd then : need to construct temporary full variables that held them, which'd be : somewhat interesting to deal with.
I don't much care about single scalar bits or ints, but I do care that an array of a million bits be represented by a million bits or so, especially in the absence of any properties. I can see ways of binding properties to a location without growing the location itself, but I think stuffing a junction of ints into a single location is somewhat problematical. As for undef, it *could* just be a property, but for efficiency it would be nice to represent it in-band for those types that can so represent it, and it ought to be possible to tell the million bit array whether or not it is willing to store undef properties off to the side. We can argue whether the default should be yes or no... Larry
