Every primitive type has an associated object type, whose name differs only
by capitalized first letter. A few posts back, Larry mentioned that perhaps
similar things should look different: this may be a good case to apply this
principle.

Whenever a value passes through a primitive type, it loses all its run-time
properties; and superpositions will collapse. I worry that this could cause
very obscure bugs: made worse by the invisibility of the difference between
primitive and object types. I would propose that, at the very least, users
should be required to C<use primitives qw(int)> before using such things.
Furthermore, I can't help feeling that it would be better to use the
lower-case versions for the common-case: the object-types (and rename the
pimitives to something like C<_prim_int32>, or C<int is primitive>). I am
hopeful that the optimiser will be sufficiently clever to notice the obvious
cases where a primitive can be used, so why distract the user?

Dave.

--
Dave Whipp, Senior Verification Engineer,
Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086
tel: 408 523 8071; http://www.fast-chip.com
Opinions my own; statements of fact may be in error.

At 6:50 PM -0800 11/6/02, David Whipp wrote:

What makes you think so, and are you really sure?
--
                                         Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
d...@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk

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.

 Why? I guess its a case of ass/u/me; plus reading other

Oh, no you don't... don't pin this one on me.  :-)

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

At 8:24 PM -0800 11/6/02, David Whipp wrote:

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
d...@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk

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       Y        Y
2 store "larger" number     N        Y
3 store undef               N        Y
4 have properties           N        Y
5 be junctions              N        Y

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.

I gotta admit that this issue is bugging me too.  Larry mentions (in
<http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=Pine.LNX.4.44...>)
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.

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

--- Michael Lazzaro <mlazz...@cognitivity.com> wrote:

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

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 C<int> and C<num> 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

 From E2: a C<int> will never have attributes or promote to an object.

My interpretation: A C<INT> my start as as C<int> 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 C<my bool @bit_ar is dim(1000,1000)>. It will
be  10^6 / (sizeof(int) * CHAR_BIT) + list_overhead.

leo

At 8:29 PM +0100 11/7/02, Leopold Toetsch wrote:

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
d...@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk

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          garr...@scriptpro.com

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).

It's probably in Michael Lazzaro's documentation somewhere ;-)

-Scott
--
Jonathan Scott Duff
d...@cbi.tamucc.edu

At 3:56 PM -0600 11/7/02, Garrett Goebel wrote:

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
d...@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk

On 2002-11-07 at 15:28:14, Luke Palmer wrote:

Good point.  Erratum: for "possible", read "easy". :)

Either of those would be sufficiently "easy".  Thanks.

--
Mark REED                    | CNN Internet Technology
1 CNN Center Rm SW0831G      | mark.r...@cnn.com
Atlanta, GA 30348      USA   | +1 404 827 4754

[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:

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      | mark.r...@cnn.com
Atlanta, GA 30348      USA   | +1 404 827 4754

                           ^^^^^^^^^^^^^^^^^^^^^^^^

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

: At 8:29 PM +0100 11/7/02, Leopold Toetsch 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

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)

Adding properties to individual C<bit>s is a PITA as well as appending
extra information, e.g undef. A C<BIT> 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.

leo

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 rrrrrroll {
  Dump $_[0];
  $_[0] x= 6;

sub rrrroll {
  Dump $_[0];
  ${$_[0]} x= 4;

$a = "Mordor";

rrrrrroll (substr ($a, 2, 1));

print "'$a'\n";

rrrroll (\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
'Morrrrrrdor'
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 "Morrrrrrdor"\0
    CUR = 11
    LEN = 12
'Morrrrrrdorrrr'

Nicholas Clark
--
INTERCAL better than perl?      http://www.perl.org/advocacy/spoofathon/

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

I'm not sure either of those works, exactly. The scope of attributes isn't
precisely lexical in nature. Perhaps instead of a C<MY> method, an object
would have a (private!) C<HAS> method, allowing something like:

       for $this.HAS -> $attr {
           print "$attr.key(): $attr.value()\n"
       }

Or maybe not. ;-)

Damian

: 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";
:       }

Note that if you call the accessor method, you may in fact be getting
a subclass's wrapper around the actual attribute.  To get at the actual
attributes, you'd need something like:

        foreach my $attr (qw(foo bar baz))
        {
             no strict 'syms';
             print "$attr: $.$attr\n";
        }

Which is another good reason for the "." secondary sigil.  For some
value of "good"...

Larry