Re: Primitive Vs Object types
Mark J. Reed wrote:
Attributes are class-specific for a variable (okay, class instance
specific, if you do Evil Things with multiple copies of a single base
class in different legs of the inheritance tree and override the
default behaviour of the engine) and not queryable at runtime without
really nasty parrot assembly code.
You won't be able to query attributes at run-time? Even within
the class? I rather like the ability to loop through
the attributes of an object with something like this Perl5 code:
foreach my $attr (qw(foo bar baz))
{
print $attr: $this-{$attr}\n;
}
You will. But they won't be entries of a hash. They'll be
separate variables and associated accessor methods.
So maybe something like this:
foreach my $attr (qw(foo bar baz))
{
print $attr: $self.$attr()\n;
}
Damian
Re: Primitive Vs Object types
Luke Palmer wrote:
Could you just look through the lexical scope of the object?
for $this.MY.kv - $k, $v {
print $k: $v\n
}
Or would you look through the class's lexical scope and apply it to
the object?
for keys $this.class.MY {
print $_: $this.MY{$_}\n
}
I think one of those two is possible. (Providing the .class method
exists and DWIMs)
I'm not sure either of those works, exactly. The scope of attributes isn't
precisely lexical in nature. Perhaps instead of a CMY method, an object
would have a (private!) CHAS method, allowing something like:
for $this.HAS - $attr {
print $attr.key(): $attr.value()\n
}
Or maybe not. ;-)
Damian
Re: Primitive Vs Object types
On Thu, Nov 07, 2002 at 04:16:50PM -0500, Dan Sugalski wrote:
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.
But surely there should be no problem passing things as parameters - with a
bit of mundane magic even taking reference to a bit should work quite nicely.
After all, perl5 can already handle the idea of not autovivifying hash lookups
passed as subroutine parameters, and assigning to substrings and substring
references:
#!/usr/local/bin/perl -w
use strict;
use Devel::Peek;
sub rroll {
Dump $_[0];
$_[0] x= 6;
}
sub oll {
Dump $_[0];
${$_[0]} x= 4;
}
$a = Mordor;
rroll (substr ($a, 2, 1));
print '$a'\n;
oll (\substr ($a, -1));
print '$a'\n;
__END__
SV = PVLV(0x1138c0) at 0x1332e8
REFCNT = 1
FLAGS = (PADMY,GMG,SMG,pPOK)
IV = 0
NV = 0
PV = 0x133d98 r\0
CUR = 1
LEN = 2
MAGIC = 0x10e8f0
MG_VIRTUAL = PL_vtbl_substr
MG_TYPE = PERL_MAGIC_substr(x)
TYPE = x
TARGOFF = 2
TARGLEN = 1
TARG = 0x132f10
SV = PV(0xf4580) at 0x132f10
REFCNT = 2
FLAGS = (POK,pPOK)
PV = 0x10c398 Mordor\0
CUR = 6
LEN = 7
'Morrdor'
SV = RV(0x11dee8) at 0xf4284
REFCNT = 1
FLAGS = (ROK)
RV = 0x13336c
SV = PVLV(0x1138f0) at 0x13336c
REFCNT = 2
FLAGS = (PADMY,GMG,SMG,pPOK)
IV = 0
NV = 0
PV = 0x1137e0 r\0
CUR = 1
LEN = 2
MAGIC = 0x10e060
MG_VIRTUAL = PL_vtbl_substr
MG_TYPE = PERL_MAGIC_substr(x)
TYPE = x
TARGOFF = 10
TARGLEN = 1
TARG = 0x132f10
SV = PV(0xf4580) at 0x132f10
REFCNT = 3
FLAGS = (POK,pPOK)
PV = 0x10c398 Morrdor\0
CUR = 11
LEN = 12
'Morrdo'
Nicholas Clark
--
INTERCAL better than perl? http://www.perl.org/advocacy/spoofathon/
Re: Primitive Vs Object types
Larry Wall wrote: ... 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. We are still talking about native types - these with lowercase names in the docs? Why should they have runtime properties? (E2/A2 state, they have none) ... 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... Adding properties to individual Cbits is a PITA as well as appending extra information, e.g undef. A CBIT array could start as a packed array of bits, adding runtime properties would promote this array to an array of PMCs, i.e. objects, which handle these properties. Larry leo
Re: Primitive Vs Object types
--- Michael Lazzaro [EMAIL PROTECTED] wrote: Primitive types were originally intended for runtime speed, thus an int or a bit is as small as possible, and not a lot of weird runtime checking has to take place that would slow it down. It can't even be undef, because that would take an extra bit, minimum, to store. This just ain't so. I once worked on a CPU simulator, and in order to set watch values on arbitrary memory we used a key value that, if present in simulated memory, indicated that a search of the watches table was in order. That key was chosen empirically, based on histogramming the ROM images and active program state, and choosing the lowest frequency value. Thus, the fetch byte primitive would automatically check and notify whenever a 0xA9 was seen. (Sometimes it really meant 0xA9, other times it meant 0x00, but halt execution.) The same can be done here, if the internals folks can make the assumption that the case is really uncommon. To wit: For 'bit', the key value is (eenie, meenie, ...) '1'. Any '1' value will trigger a search for undef bit values. Presuming that bit values will not frequently be undef, the search should be cheap and the storage requirements will be something on the order of C + Num_undef_bits * sizeof(addr_t) Which will be greater than one extra bit when few or no bit objects are used, and will be very much smaller than one extra bit when many bit objects are used. In short: It's possible, even easy, to implement ANY feature (properties, undef, etc) for primitive types in this manner. It absolutely *IS* correct to say That's an implementation detail and leave it to the internals team to figure out HOW they want to do it. So what's the difference REALLY? =Austin __ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2
Re: Primitive Vs Object types
On Thursday, November 7, 2002, at 06:36 AM, Austin Hastings wrote: For 'bit', the key value is (eenie, meenie, ...) '1'. Any '1' value will trigger a search for undef bit values. Presuming that bit values will not frequently be undef, the search should be cheap and the storage requirements will be something on the order of Right. So it's a question of having a little extra storage (at least 1 bit, somewhere, for each undef), but more importantly a question of whether or not there are primitive types that circumvent that check. 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 Cint and Cnum may or may not allow run-time properties. In cases where it is allowed, the intrinsic type must generally be promoted to its corresponding object type (or wrapped in an object that delegates back to the original intrinsic for the actual value). But you really don't want to promote an array of a million bits to an array of a million objects just because you had the hankering to put a sticky note on one of those bits, so in those cases it's likely to be disallowed, or the bit is likely to be cloned instead of referenced, or some such thing. If internals says that there's no runtime speed issue, that's awesome. I think we just have to be aware of one of our implied goals -- that Perl6 can be used for giant data-munging tasks without speed penalties so horrific as to send people to other languages. MikeL
Re: Primitive Vs Object types
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 Cint and Cnum may or may not allow run-time properties. From E2: a Cint will never have attributes or promote to an object. My interpretation: A CINT my start as as Cint as long as the compiler/optimizer doesn't see any attributes/tie/bless or whatever, that would need an object. If so, it promotes to an object. More important: how big is Cmy bool bit_ar is dim(1000,1000). It will be 10^6 / (sizeof(int) * CHAR_BIT) + list_overhead. leo
Re: Primitive Vs Object types
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 Cint and Cnum may or may not allow run-time properties. From E2: a Cint 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. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Primitive Vs Object types
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 Cint and Cnum may or may not allow run-time properties. From E2: a Cint will never have attributes or promote to an object. Attributes aren't properties. I thought: 'attributes' :Perl5 == 'properites' isa Perl6 Can someone point me to Perl6 definitions for both terms? -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
Re: Primitive Vs Object types
On Thu, Nov 07, 2002 at 03:56:04PM -0600, Garrett Goebel wrote:
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 Cint and Cnum may or may not allow
run-time properties.
From E2: a Cint will never have attributes or promote to an object.
Attributes aren't properties.
I thought:
'attributes' :Perl5 == 'properites' isa Perl6
Yeah. Where the Apocalyses and Exegeses say attributes they are
referring to data members of an object:
class Foo {
has $.bar is friendly;
}
$.bar is an attribute (of Foo-ish objects), friendly is a property (of
the $.bar attribute).
Can someone point me to Perl6 definitions for both terms?
It's probably in Michael Lazzaro's documentation somewhere ;-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
RE: Primitive Vs Object types
At 3:56 PM -0600 11/7/02, Garrett Goebel wrote: 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 Cint and Cnum may or may not allow run-time properties. From E2: a Cint will never have attributes or promote to an object. Attributes aren't properties. I thought: 'attributes' :Perl5 == 'properites' isa Perl6 Can someone point me to Perl6 definitions for both terms? Short(ish) answer: perl 6 attributes are much like the hash entries in a perl 5 object (assuming you use a hash as your object), only the keys are fixed at class definition time, and each parent/child/grandchild class can only see its own slots in the objects. And slot names don't collide, so every class in a 47-class inheritance chain can have an attribute Foo. perl 6 properties are more on the order of runtime notations on a variable. (Damian likes the properties-as-PostIt-note metaphor. As do I, come to think of it) Properties will be global to a variable, and queryable at runtime. Attributes are class-specific for a variable (okay, class instance specific, if you do Evil Things with multiple copies of a single base class in different legs of the inheritance tree and override the default behaviour of the engine) and not queryable at runtime without really nasty parrot assembly code. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Primitive Vs Object types
[Recipients list trimmed back to just the list - it was getting ridiculous.
So everyone will get only get one copy and it may take a tad longer to
get there . . .]
On 2002-11-07 at 17:07:46, Dan Sugalski wrote:
Attributes are class-specific for a variable (okay, class instance
specific, if you do Evil Things with multiple copies of a single base
class in different legs of the inheritance tree and override the
default behaviour of the engine) and not queryable at runtime without
really nasty parrot assembly code.
You won't be able to query attributes at run-time? Even within
the class? I rather like the ability to loop through
the attributes of an object with something like this Perl5 code:
foreach my $attr (qw(foo bar baz))
{
print $attr: $this-{$attr}\n;
}
Will something like that not be possible in Perl6?
--
Mark REED| CNN Internet Technology
1 CNN Center Rm SW0831G | [EMAIL PROTECTED]
Atlanta, GA 30348 USA | +1 404 827 4754
Re: Primitive Vs Object types
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Date: Thu, 7 Nov 2002 17:19:28 -0500
From: Mark J. Reed [EMAIL PROTECTED]
Content-Disposition: inline
X-Julian-Day: 2452586.42675
X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
[Recipients list trimmed back to just the list - it was getting ridiculous.
So everyone will get only get one copy and it may take a tad longer to
get there . . .]
On 2002-11-07 at 17:07:46, Dan Sugalski wrote:
Attributes are class-specific for a variable (okay, class instance
specific, if you do Evil Things with multiple copies of a single base
class in different legs of the inheritance tree and override the
default behaviour of the engine) and not queryable at runtime without
really nasty parrot assembly code.
You won't be able to query attributes at run-time? Even within
the class? I rather like the ability to loop through
the attributes of an object with something like this Perl5 code:
foreach my $attr (qw(foo bar baz))
{
print $attr: $this-{$attr}\n;
}
Will something like that not be possible in Perl6?
I'm afraid that statement is false for all values of something :)
Could you just look through the lexical scope of the object?
for $this.MY.kv - $k, $v {
print $k: $v\n
}
Or would you look through the class's lexical scope and apply it to
the object?
for keys $this.class.MY {
print $_: $this.MY{$_}\n
}
I think one of those two is possible. (Providing the .class method
exists and DWIMs)
Luke
Re: Primitive Vs Object types
On 2002-11-07 at 15:28:14, Luke Palmer wrote:
From: Mark J. Reed [EMAIL PROTECTED]
Will something like that not be possible in Perl6?
I'm afraid that statement is false for all values of something :)
Good point. Erratum: for possible, read easy. :)
Could you just look through the lexical scope of the object?
for $this.MY.kv - $k, $v {
print $k: $v\n
}
Or would you look through the class's lexical scope and apply it to
the object?
for keys $this.class.MY {
print $_: $this.MY{$_}\n
}
Either of those would be sufficiently easy. Thanks.
--
Mark REED| CNN Internet Technology
1 CNN Center Rm SW0831G | [EMAIL PROTECTED]
Atlanta, GA 30348 USA | +1 404 827 4754
Re: Primitive Vs Object types
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 Cint and Cnum may or may not allow : run-time properties. : : : From E2: a Cint 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
Re: Primitive Vs Object types
At 6:50 PM -0800 11/6/02, David Whipp wrote: Whenever a value passes through a primitive type, it loses all its run-time properties; and superpositions will collapse. What makes you think so, and are you really sure? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Primitive Vs Object types
Dan Sugalski [mailto:dan;sidhe.org] wrote: At 6:50 PM -0800 11/6/02, David Whipp wrote: Whenever a value passes through a primitive type, it loses all its run-time properties; and superpositions will collapse. What makes you think so, and are you really sure? I was sure up until the time that I read your reply :). Why? I guess its a case of ass/u/me; plus reading other people's assumptions (e.g. Michael Lazzaro's initial Chapter, at cog.cognitivity.com/perl6/val.html). If I am wrong, then I am in need of enlightenment. What is the difference between the primitive types and their heavyweight partners? And which should I use in a typical script? Dave.
RE: Primitive Vs Object types
At 8:24 PM -0800 11/6/02, David Whipp wrote: If I am wrong, then I am in need of enlightenment. What is the difference between the primitive types and their heavyweight partners? And which should I use in a typical script? The big difference is there's no way you can ever truly get a primitive type in perl 6. (At least so primitive that you can't hang properties off it) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Primitive Vs Object types
David Whipp wrote: Dan Sugalski [mailto:dan;sidhe.org] wrote: At 6:50 PM -0800 11/6/02, David Whipp wrote: Whenever a value passes through a primitive type, it loses all its run-time properties; and superpositions will collapse. What makes you think so, and are you really sure? Why? I guess its a case of ass/u/me; plus reading other people's assumptions (e.g. Michael Lazzaro's initial Chapter, at cog.cognitivity.com/perl6/val.html). Oh, no you don't... don't pin this one on me. :-) If I am wrong, then I am in need of enlightenment. What is the difference between the primitive types and their heavyweight partners? And which should I use in a typical script? It has been stated multiple times that primitive types can't take runtime properties or other object-like features, so that they may be as lightweight as possible -- flyweight classes, as it were. Primitive types were originally intended for runtime speed, thus an int or a bit is as small as possible, and not a lot of weird runtime checking has to take place that would slow it down. It can't even be undef, because that would take an extra bit, minimum, to store. Promoted types, on the other hand, can do all that stuff -- that's the whole reason there are two separate versions of each type. It allows some credible possibility of optimal runtime efficiency in Perl6, when it's important to you. It is not necessarily a given that the behavior will hold true for superpositions. In fact, it is hypothetically possible (tho almost certainly unworkable) that typechecking on primitives wouldn't really enforce true primitiveness at all, but merely acts as a suggested type, trading optimal efficiency for more moderate efficiency (but meaning you _could_ store an undef, etc. in a hole meant for a primitive: it'll just have to assume more runtime checks then it originally would for a true primitive.) Or it may be that storing in primitive type does indeed enforce maximal efficiency, and that you should use the promoted types when you don't want that. Dunno. MikeL
RE: Primitive Vs Object types
Dan Sugalski [mailto:dan;sidhe.org] wrote: At 8:24 PM -0800 11/6/02, David Whipp wrote: If I am wrong, then I am in need of enlightenment. What is the difference between the primitive types and their heavyweight partners? And which should I use in a typical script? The big difference is there's no way you can ever truly get a primitive type in perl 6. (At least so primitive that you can't hang properties off it) I hope I'm not being stupid here, but isn't that a lack-of difference. Michael has just confirmed that 'It has been stated multiple times that primitive types can't take runtime properties or other object-like features', so now I'm confused. Here's a list of things that ints/Ints might do, and my previous understanding of if they can: int Int 1 store 32-bit number YY 2 store larger number NY 3 store undef NY 4 have properties NY 5 be junctions NY It appears that you're saying that (4) is incorrect; and if this is wrong, then (3) is probably wrong too. I wouldn't be surprised if this means that (5) is wrong also, so this would just leave (2): Ints are bigger than ints. My original proposal still stands: represent these differences as a (compile-time) property, not a new type. Failing that, use typenames that are more distinctive (e.g. BigInt, or int32). Dave.
Re: Primitive Vs Object types
I gotta admit that this issue is bugging me too. Larry mentions (in http://groups.google.com/groups?hl=enlr=ie=UTF-8selm=Pine.LNX.4.44.0210140927520.20533-10%40london.wall.org) that all-uppercase is ugly and has boundary conditions. Maybe it would be helpful to know what conditions are causing problems. All-lowercase implies that we want them to be used *more* than the object types. But it seems like we should encourage the use of the object types. Maybe that's because we want to discourage undef values, but I've been programming databases too long, so I like undefs now. We certainly don't want to discourage using the autopromoting Int - Long - Bignum features of the object types, do we? Also the typecasting functions have been defined in all lower case, which would suggest to the naive user that they will typecast to primitive types, and perhaps even throw an exception when an undef is cast. On Wed, 6 Nov 2002, Michael Lazzaro wrote: David Whipp wrote: Dan Sugalski [mailto:dan;sidhe.org] wrote: At 6:50 PM -0800 11/6/02, David Whipp wrote: Whenever a value passes through a primitive type, it loses all its run-time properties; and superpositions will collapse. What makes you think so, and are you really sure? If I am wrong, then I am in need of enlightenment. What is the difference between the primitive types and their heavyweight partners? And which should I use in a typical script? It has been stated multiple times that primitive types can't take runtime properties or other object-like features, so that they may be as lightweight as possible -- flyweight classes, as it were. Primitive types were originally intended for runtime speed, thus an int or a bit is as small as possible, and not a lot of weird runtime checking has to take place that would slow it down. I don't think the point is to store them as small as possible, but as efficiently as possible. That is, in whatever register size the hardware works best on. We don't want to compact unrelated bits into a single hardware address, because then we are forced to do extra masking and shifting everytime we want to use the value. ~ John Williams
