Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Array Questions

10 views
Skip to first unread message

Michael Lazzaro

unread,
Jan 7, 2003, 1:04:09 PM1/7/03
to perl6-l...@perl.org
I think this may be another case of "it depends on what the word
'object' means", e.g. we're talking past each other. I hope.

Let's operate from the assumption -- or somebody please CORRECT ME IF
I'M WRONG -- that the following syntax is valid:

my int @a;
my @a returns int;
my @a is Array of int;
my @a is Array returns int;
my int @a is Array;

Those lines are all absolutely synonymous, and all declare an array of
integers, right? Likewise, Arrays have methods:

my int @a = (1..100);
print @a.length; # prints "100"
my @b = @a.grep { $_ > 50 }; # gets 51..100

... which is also known, based on previous Apocalypsii.

If we accept those as valid syntax -- and I *think* they have been --
then P6 Arrays are objects. Or, at minimum, they cannot be _discerned_
from objects, regardless of implementation.

Now, what that looks like in Parrot I have no idea. But I'm assuming
those all will work in P6, because (again, correct me if I'm wrong)
Larry has stated they will.

Is there ANY QUESTION about ANY of that? If so, please let me know
NOW, because the documentation group will writing up the 'Array' and
'Hash' sections in the coming weeks.

The remaining big question, then, is whether you can truly subclass
Array to achieve C<tie>-like behavior:

class MyArray is Array { ... };

my @a is MyArray;

It would seem remarkable if you *couldn't*, right? BUT, that's
pointing out something that might be unexpected... it's actually
instantiating a MyArray object for @a, without you having to do it
yourself. Or it's marking that @a will be instantiated upon first use.
The same thing happens when you say C<my @a is Array>, or even just
C<my @a> -- it's fundamental to the syntax.

And that would imply you can do the same for hashes, and even scalars.
Including arbitrary objects, yes?

my $a is Scalar; # long way of saying C<my $a>
my $a is int;
my $a is Scalar of int; # long way of saying C<my int $a>?
my $a is Scalar returns int; # long way of saying C<my int $a>?

my $a is MyClass; # works for anything
my $a is MyClass('a','b','c'); # so is this OK too?

Which, in turn, implies that the lines:

my Foo $a; # (1)
my $a is Foo; # (2)
my Foo $a is Foo; # (3)

are all subtly different. (2) and (3) (auto)instantiate a Foo, but (1)
does not.

There's a lot of implications here, but it seems self-consistent, based
on sound fundamentals, and all of it seems to be either directly stated
or strongly implied by previous A's and E's and p6l threads. PLEASE
tell me if/where I'm wrong here, ASAP.

MikeL

Jonathan Scott Duff

unread,
Jan 7, 2003, 2:26:59 PM1/7/03
to Michael Lazzaro, perl6-l...@perl.org
On Tue, Jan 07, 2003 at 10:04:09AM -0800, Michael Lazzaro wrote:
> I think this may be another case of "it depends on what the word
> 'object' means", e.g. we're talking past each other. I hope.
>
> Let's operate from the assumption -- or somebody please CORRECT ME IF
> I'M WRONG -- that the following syntax is valid:
>
> my int @a; # 1
> my @a returns int; # 2
> my @a is Array of int; # 3
> my @a is Array returns int; # 4
> my int @a is Array; # 5

>
> Those lines are all absolutely synonymous, and all declare an array of
> integers, right?

Doesn't jive with me. I'm not sure what "returns int" means and numbers
5 and 1 don't read well. The first one says (to me) that this thing
called @a is an int. It doesn't say anything about the contents of @a.
#5 has the same problem.

If this is one of those set-in-molded-clay kinds of things, someone
please point me at the relevant discussion.

> Likewise, Arrays have methods:
>
> my int @a = (1..100);
> print @a.length; # prints "100"
> my @b = @a.grep { $_ > 50 }; # gets 51..100
>
> ... which is also known, based on previous Apocalypsii.
>
> If we accept those as valid syntax -- and I *think* they have been --
> then P6 Arrays are objects. Or, at minimum, they cannot be _discerned_
> from objects, regardless of implementation.
>
> Now, what that looks like in Parrot I have no idea. But I'm assuming
> those all will work in P6, because (again, correct me if I'm wrong)
> Larry has stated they will.
>
> Is there ANY QUESTION about ANY of that?

This all fits with my mental model (except for the declaration syntax).

> The remaining big question, then, is whether you can truly subclass
> Array to achieve C<tie>-like behavior:
>
> class MyArray is Array { ... };
>
> my @a is MyArray;
>
> It would seem remarkable if you *couldn't*, right?

Indeed.

[ snip ]


> Which, in turn, implies that the lines:
>
> my Foo $a; # (1)
> my $a is Foo; # (2)
> my Foo $a is Foo; # (3)
>
> are all subtly different. (2) and (3) (auto)instantiate a Foo, but (1)
> does not.

Um ... ick. I'd hope that "autoinstantiation" wouldn't happen without
some clear syntactical clue. (I don't think "is" that clue. To me
all three of those look like they should just earmark $a to contain a
Foo and this Foo-thing can/will be instantiated later)

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

Mr. Nobody

unread,
Jan 7, 2003, 2:31:13 PM1/7/03
to perl6-l...@perl.org
--- Michael Lazzaro <mlaz...@cognitivity.com> wrote:
> Arrays have methods:
>
> my int @a = (1..100);
> print @a.length; # prints "100"
> my @b = @a.grep { $_ > 50 }; # gets 51..100

.length is unneeded, since an array gives its length in numeric context, so
you can just say +@a. grep shouldn't be an array method either, it should be
like the perl5 grep, as it is often used on lists, "grep /foo/, keys %h" is
far more readable than "@{[keys %h]}.grep(/foo/)".

Some things should be methods on arrays though, like push, pop, shift,
unshift, and splice, since those are only for real arrays anyway.

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Mark J. Reed

unread,
Jan 7, 2003, 3:51:37 PM1/7/03
to Mr. Nobody, perl6-l...@perl.org
On 2003-01-07 at 11:31:13, Mr. Nobody wrote:
> .length is unneeded, since an array gives its length in numeric context, so
> you can just say +@a.
Unneeded, but harmless.

> grep shouldn't be an array method either, it should be
> like the perl5 grep, as it is often used on lists, "grep /foo/, keys %h" is
> far more readable than "@{[keys %h]}.grep(/foo/)".

Didn't we already have the left-to-right vs. right-to-left discussion?
Regardless of how grep works when it's not invoked as a method, it
most definitely should be invokable as one on arrays. It would probably
be defined in a superclass rather than in Array itself, assuming Array
is a specific subclass of a more general collection class
(be it List or Collection or whatever), but that doesn't matter as long
as you can call it on an array.

Also, some of the line noise in your "unreadable" example comes from your
mixing method syntax with other syntax. No need to do all that @{[keys %h]}
stuff - it would just be %h.keys.grep(/foo/), which looks pretty darn readable
to me.

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

Deborah Ariel Pickett

unread,
Jan 7, 2003, 5:05:42 PM1/7/03
to perl6-l...@perl.org
> On 2003-01-07 at 11:31:13, Mr. Nobody wrote:
> > .length is unneeded, since an array gives its length in numeric context, so
> > you can just say +@a.
> Unneeded, but harmless.

Getting off topic here (a bit), but I think it's a Mistake to have
.length mean different things on an array ["Number of elements"] and a
(string) scalar ["number of characters"]. While there will never be any
confusion on the part of Perl, it'll promote Thinking About Things The
Wrong Way among Perl novices, who will try to think of strings as C-like
arrays of characters. We've gone to great lengths to disabuse people of
that notion in Perl5; let's keep it that way.

Perhaps .size for number-of-elements and .length for length-of-string
would work?

--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep deb...@csse.monash.edu.au
"Long and wide, eternity from side to side, lead me through the rapids, guide me
to the shore. There's a place that's far beyond this time and space, when each
of us comes face to face with something more." - _Siren Song_, Alan Parsons

Michael Lazzaro

unread,
Jan 7, 2003, 4:54:30 PM1/7/03
to du...@pobox.com, perl6-l...@perl.org
On Tuesday, January 7, 2003, at 11:26 AM, Jonathan Scott Duff wrote:
> On Tue, Jan 07, 2003 at 10:04:09AM -0800, Michael Lazzaro wrote:
>> Let's operate from the assumption -- or somebody please CORRECT ME IF
>> I'M WRONG -- that the following syntax is valid:
>>
>> my int @a; # 1
>> my @a returns int; # 2
>> my @a is Array of int; # 3
>> my @a is Array returns int; # 4
>> my int @a is Array; # 5
>>
>> Those lines are all absolutely synonymous, and all declare an array of
>> integers, right?
>
> Doesn't jive with me. I'm not sure what "returns int" means and numbers
> 5 and 1 don't read well. The first one says (to me) that this thing
> called @a is an int. It doesn't say anything about the contents of @a.
> #5 has the same problem.
>
> If this is one of those set-in-molded-clay kinds of things, someone
> please point me at the relevant discussion.

I believe they are all set in (reasonably hard) stone. (1) is from
A2/E2, and is set in granite. The other forms came post-Zurich, AFAIK
-- a quick search for them finds a p6l note from Larry dated 10/10/02
("Re: Object Instanciation") that mentions them in the larger context
of how objects work. (It has also been confirmed by Allison and Damian
at various points, but I don't think there's ever been a post-Zurich
thread devoted to it.)

So yeah, I'm pretty sure they're accurate.

MikeL

Piers Cawley

unread,
Jan 7, 2003, 5:12:17 PM1/7/03
to Mark J. Reed, Mr. Nobody, perl6-l...@perl.org
"Mark J. Reed" <mark...@turner.com> writes:

> On 2003-01-07 at 11:31:13, Mr. Nobody wrote:
>> .length is unneeded, since an array gives its length in numeric context, so
>> you can just say +@a.
> Unneeded, but harmless.
>
>> grep shouldn't be an array method either, it should be
>> like the perl5 grep, as it is often used on lists, "grep /foo/, keys %h" is
>> far more readable than "@{[keys %h]}.grep(/foo/)".
> Didn't we already have the left-to-right vs. right-to-left discussion?
> Regardless of how grep works when it's not invoked as a method, it
> most definitely should be invokable as one on arrays. It would probably
> be defined in a superclass rather than in Array itself, assuming Array
> is a specific subclass of a more general collection class
> (be it List or Collection or whatever), but that doesn't matter as long
> as you can call it on an array.
>
> Also, some of the line noise in your "unreadable" example comes from your
> mixing method syntax with other syntax. No need to do all that @{[keys %h]}
> stuff - it would just be %h.keys.grep(/foo/), which looks pretty darn readable
> to me.

Or, even

%h.grep(-> $pair {.key =~ /foo/})

depending on what you actually want (assuming that grep treats %h as a
list of pairs...)

Michael Lazzaro

unread,
Jan 7, 2003, 5:15:46 PM1/7/03
to Deborah Ariel Pickett, perl6-l...@perl.org

On Tuesday, January 7, 2003, at 02:05 PM, Deborah Ariel Pickett wrote:

>> On 2003-01-07 at 11:31:13, Mr. Nobody wrote:
>>> .length is unneeded, since an array gives its length in numeric
>>> context, so
>>> you can just say +@a.
>> Unneeded, but harmless.
>
> Getting off topic here (a bit), but I think it's a Mistake to have
> .length mean different things on an array ["Number of elements"] and a
> (string) scalar ["number of characters"]. While there will never be
> any
> confusion on the part of Perl, it'll promote Thinking About Things The
> Wrong Way among Perl novices, who will try to think of strings as
> C-like
> arrays of characters. We've gone to great lengths to disabuse people
> of
> that notion in Perl5; let's keep it that way.
>
> Perhaps .size for number-of-elements and .length for length-of-string
> would work?

Indeed, Larry mentioned a while back that C<.length> for arrays might
be spelled C<.elems> or something, for that exact reason -- the term
"length" is horribly ambiguous when you're using it on a scalar
(string) value, when you've got Unicode (you need to be saying "chars",
or "bytes", or "elems", or whatever), and so maybe the word should
change for arrays as well.

Not sure what was decided on that particular one, if anything. We need
to confirm. IIRC, C<.length> likely won't exist at all for strings.
It still might exist (?) for arrays.

MikeL

Austin Hastings

unread,
Jan 7, 2003, 5:28:30 PM1/7/03
to Deborah Ariel Pickett, perl6-l...@perl.org

--- Deborah Ariel Pickett <deb...@mail.csse.monash.edu.au> wrote:
> Getting off topic here (a bit), but I think it's a Mistake to have
> .length mean different things on an array ["Number of elements"] and
> a (string) scalar ["number of characters"].


> While there will never be any confusion on the part of Perl,
> it'll promote Thinking About Things The Wrong Way among Perl
> novices, who will try to think of strings as C-like arrays of
> characters. We've gone to great lengths to disabuse people
> of that notion in Perl5; let's keep it that way.

> Perhaps .size for number-of-elements and .length for length-of-string
> would work?

<sarcasm>
This would just cause them to Think About Things A Different But
Equally Wrong Way: as assembly language objects whose SIZE in bytes is
the determining component of their existence.
</sarcasm>

Seriously, if they're smart enough to run a text editor, I think it's
safe to say that they can handle the conceptual difference between the
"length" (mins:secs) of a video, and the "length" (feet:inches) of the
mag-tape that encodes the video. People deal with different inherent
units all the time in the real world -- some of them even remember to
carry the units through their equations when they're doing math. Let's
give some credit to the audience at large.

=Austin


Deborah Ariel Pickett

unread,
Jan 7, 2003, 5:42:18 PM1/7/03
to Austin_...@yahoo.com, perl6-l...@perl.org
> > Perhaps .size for number-of-elements and .length for length-of-string
> > would work?
> <sarcasm>
> This would just cause them to Think About Things A Different But
> Equally Wrong Way: as assembly language objects whose SIZE in bytes is
> the determining component of their existence.
> </sarcasm>

I am happy to see other suggestions for the names. The ones I mentioned
were simply spur-of-the-moment ideas, which I agree have problems.

> Seriously, if they're smart enough to run a text editor, I think it's
> safe to say that they can handle the conceptual difference between the
> "length" (mins:secs) of a video, and the "length" (feet:inches) of the
> mag-tape that encodes the video. People deal with different inherent
> units all the time in the real world -- some of them even remember to
> carry the units through their equations when they're doing math. Let's
> give some credit to the audience at large.

With respect, I have plenty of evidence to suggest that programming
students *won't* handle the difference (many years of teaching
first- and second-year programming at University). I see students at
all levels saying things like:
char *dupString = malloc(sizeof oldString + 1);
when they mean:
char *dupString = malloc(strlen(oldString) + 1);
(Actually, that's a good argument against using "size" to mean
number-of-elements of Perl arrays, isn't it?)

Perhaps you are talking about experienced programmers rather than
students. In that case, I agree with you. But everybody has to learn
Perl once.

Austin Hastings

unread,
Jan 7, 2003, 6:58:34 PM1/7/03
to Deborah Ariel Pickett, perl6-l...@perl.org

--- Deborah Ariel Pickett <deb...@mail.csse.monash.edu.au> wrote:
> > Seriously, if they're smart enough to run a text editor, I think
> it's
> > safe to say that they can handle the conceptual difference between
> the
> > "length" (mins:secs) of a video, and the "length" (feet:inches) of
> the
> > mag-tape that encodes the video. People deal with different
> inherent
> > units all the time in the real world -- some of them even remember
> to
> > carry the units through their equations when they're doing math.
> Let's
> > give some credit to the audience at large.
>
> With respect, I have plenty of evidence to suggest that programming
> students *won't* handle the difference (many years of teaching
> first- and second-year programming at University). I see students at
> all levels saying things like:
> char *dupString = malloc(sizeof oldString + 1);
> when they mean:
> char *dupString = malloc(strlen(oldString) + 1);
> (Actually, that's a good argument against using "size" to mean
> number-of-elements of Perl arrays, isn't it?)

It's a good argument for better-explaining the difference between
pointer and target, not something that's likely to be a problem in
Perl.

One of the things I hated about HTML forms was that some things were
WIDTH= and some things were LENGTH= and some things were SIZE= and some
were COLS=. What crackhead smoked that up?

Much more consistent, readable, harmonious -- better -- to say
something like:

sub postoffice_sort(@items)
{
my @bins[10];


for (my $x = 0; my $x < @items.length; $x++)
{
..
}
}

Austin Hastings

unread,
Jan 7, 2003, 7:00:24 PM1/7/03
to Austin_...@yahoo.com, Deborah Ariel Pickett, perl6-l...@perl.org

Hit the post key too soon, there. Anyway, visualize an example
involving @items.length and $zipcode.length ...

=Austin

Damian Conway

unread,
Jan 8, 2003, 5:13:36 AM1/8/03
to perl6-l...@perl.org
Michael Lazzaro wrote:


> my int @a;
> my @a returns int;
> my @a is Array of int;
> my @a is Array returns int;
> my int @a is Array;
>
> Those lines are all absolutely synonymous, and all declare an array of
> integers, right?

Right. (This week, at least ;-)


> Likewise, Arrays have methods:
>
> my int @a = (1..100);
> print @a.length; # prints "100"
> my @b = @a.grep { $_ > 50 }; # gets 51..100
>
> ... which is also known, based on previous Apocalypsii.

Right.


> If we accept those as valid syntax -- and I *think* they have been --
> then P6 Arrays are objects. Or, at minimum, they cannot be _discerned_
> from objects, regardless of implementation.

The later, I strongly suspect.


> The remaining big question, then, is whether you can truly subclass
> Array to achieve C<tie>-like behavior:
>
> class MyArray is Array { ... };
>
> my @a is MyArray;

Oh yes, I would certainly expect that this has to be possible.

> Which, in turn, implies that the lines:
>
> my Foo $a; # (1)
> my $a is Foo; # (2)
> my Foo $a is Foo; # (3)
>
> are all subtly different. (2) and (3) (auto)instantiate a Foo, but (1)
> does not.

Correct. Though the instantiated Foo is the "implementation object" and
not directly accessible (just as the implementation object in a Perl 5
tie isn't).

BTW, C<my Foo $a is Foo> is just sick!
(i.e. I'll *definitely* be using it ;-)

Damian

Damian Conway

unread,
Jan 8, 2003, 5:17:51 AM1/8/03
to perl6-l...@perl.org

I doubt it. The C<is Foo> tells Perl that this variable is *implemented*
by a (hidden) Foo object. The variable better be able to get in touch with
that "inner Foo" at the point the variable is first used in any way. So
it probably needs to be autocreated at the point of declaration (or, at
least, trampolined into existance before the variable is first used).

Damian


Luke Palmer

unread,
Jan 8, 2003, 7:09:04 AM1/8/03
to deb...@mail.csse.monash.edu.au, Austin_...@yahoo.com, perl6-l...@perl.org
> From: Deborah Ariel Pickett <deb...@mail.csse.monash.edu.au>
> Date: Wed, 8 Jan 2003 09:42:18 +1100 (EST)
>
> [...] But everybody has to learn Perl once.

I agree with you entirely :)

Luke

Michael Lazzaro

unread,
Jan 8, 2003, 1:17:43 PM1/8/03
to perl6-l...@perl.org

Yes, I should have used something more clear than "Foo", and it would
have been more obvious what I was getting at:

my MyScalar $a; # (1)
my $a is MyScalar; # (2)
my MyScalar $a is MyScalar; # (3)

(1) creates a scalar variable that may store a MyScalar value.
(2) creates an untyped variable in which the scalar variable $a is
_implemented_ by an instance of class MyScalar.
(3) creates a variable that stores a MyScalar AND is implemented by an
instance of class MyScalar.

Note that (3) is just plain sadistic. My point was simply that
scalars, like arrays and hashes, also should use the 'is' syntax to
declare an implementor class, and that the implementor class is, by
necessity, always autoinstanciated.

E.G. this is what our new C<tie> syntax is gonna look like, fates
willing.

MikeL

Michael Lazzaro

unread,
Jan 8, 2003, 1:32:13 PM1/8/03
to Damian Conway, perl6-l...@perl.org
On Wednesday, January 8, 2003, at 02:13 AM, Damian Conway wrote:

> Michael Lazzaro wrote:
>> The remaining big question, then, is whether you can truly subclass
>> Array to achieve C<tie>-like behavior:
>> class MyArray is Array { ... };
>> my @a is MyArray;
>
> Oh yes, I would certainly expect that this has to be possible.

OK, next question. Is _THIS_ possible?

class FileBasedHash is Hash { ...stuff... };

my %data is FileBasedHash('/tmp/foo.txt');


And if _that's_ possible, is _THIS_ possible?

my $path = '/tmp/foo.txt';
my %data is FileBasedHash($path);


Sorry, but I gotta ask. :-)

MikeL

Chris Dutton

unread,
Jan 8, 2003, 1:39:49 PM1/8/03
to perl6-l...@perl.org

I would ask, if it's possible to inherit from Array or Hash, is it
possible to inherit from one which has a constrained storage type?

my WeirdHash is int Hash { ... }

Michael Lazzaro

unread,
Jan 8, 2003, 2:02:44 PM1/8/03
to Chris Dutton, perl6-l...@perl.org

On Wednesday, January 8, 2003, at 10:39 AM, Chris Dutton wrote:
> I would ask, if it's possible to inherit from Array or Hash, is it
> possible to inherit from one which has a constrained storage type?
>
> my WeirdHash is int Hash { ... }

Yes, I think that was tentatively confirmed a while back. But it would
be spelled:

class WierdHash is Hash of int { ... }

such that:

my %h is WierdHash; # automatically stores ints!

my str %h is WierdHash; # but this is probably an error


MikeL

Damian Conway

unread,
Jan 9, 2003, 6:24:28 AM1/9/03
to perl6-l...@perl.org
Michael Lazzaro asked:

> OK, next question. Is _THIS_ possible?
>
> class FileBasedHash is Hash { ...stuff... };
>
> my %data is FileBasedHash('/tmp/foo.txt');

Yes. Though we would need a syntax for specifying that string parameter for the
generic C<FileBasedHash> class. And, of course, a mechanism for constructing the
non-generic version of the generic class from the corresponding argument.


> And if _that's_ possible, is _THIS_ possible?
>
> my $path = '/tmp/foo.txt';
> my %data is FileBasedHash($path);

Indeed. In fact, there may even be a standard property that does this kind of
thing:

# Note: this is purely speculative...

my $str is from($filename); # text in file becomes chars in string

my @lines is from($filename); # lines in file become elements in array

my %config is from($filename); # colon-separated fields in file become kv pairs in hash

Damian

Michael Lazzaro

unread,
Jan 10, 2003, 1:28:49 PM1/10/03
to Damian Conway, perl6-l...@perl.org
On Thursday, January 9, 2003, at 03:24 AM, Damian Conway wrote:
> Michael Lazzaro asked:

>> class FileBasedHash is Hash { ...stuff... };
>> my %data is FileBasedHash('/tmp/foo.txt');
> Yes.

>> my $path = '/tmp/foo.txt';


>> my %data is FileBasedHash($path);
> Indeed

Great -- then I have only one more question, I think. In the words of
a certain cartoon character, what's *this* button do?

my $b is $a;

My presumption:

1) If C<my $a = MyScalar>, e.g. $a is set to a class name, it's saying
that $b is implemented by a MyScalar. But I don't know if these two
lines would really have the same result, given rule (2), below:

$a = MyScalar;
$a = 'MyScalar';

2) If C<my $a = $fooObj>, e.g. it's set to an arbitrary object
instance, it's saying that $b is implemented by the object instance in
$a. So these statements are equiv:

my $a = FileBasedHash.new($path);
my %b is $a;
vs.
my %b is FileBasedHash($path);

If the object in $a doesn't implement the Scalar interface, it's a
runtime error. And note that C<my %b is %a> would be a runtime error,
one would hope.


MikeL

(My original gut desire was that C<my $b is $a> be the ultracool perl6
way of achieving prototype-based (classless) OO, such that $b inherits
its base functionality from $a. As inherently cool as that is, I don't
think that can possibly work, and it would conflict *severely* with
these other meanings. Ah, well.)

Jonathan Scott Duff

unread,
Jan 10, 2003, 2:28:01 PM1/10/03
to Michael Lazzaro, Damian Conway, perl6-l...@perl.org
On Fri, Jan 10, 2003 at 10:28:49AM -0800, Michael Lazzaro wrote:
> Great -- then I have only one more question, I think. In the words of
> a certain cartoon character, what's *this* button do?
>
> my $b is $a;

And no matter what that button does, will this:

my $a $b;

be illegal?

Thom Boyer

unread,
Jan 10, 2003, 3:57:26 PM1/10/03
to Michael Lazzaro, Damian Conway, perl6-l...@perl.org
From: Michael Lazzaro [mailto:mlaz...@cognitivity.com]

> But I don't know if these two
> lines would really have the same result, ...

>
> $a = MyScalar;
> $a = 'MyScalar';

Hrmm. Didn't Larry decree that there are no bare words, but that a class
name will evaluate to the string representing the spelling of the class
name? In otherwords, aren't those two assignments identical by definition?
=thom
"Never try to out-stubborn a cat." --Lazarus Long

Luke Palmer

unread,
Jan 10, 2003, 5:36:53 PM1/10/03
to tbo...@cogitoinc.com, mlaz...@cognitivity.com, dam...@conway.org, perl6-l...@perl.org
> From: Thom Boyer <tbo...@CogitoInc.com>
> Date: Fri, 10 Jan 2003 13:57:26 -0700

>
> From: Michael Lazzaro [mailto:mlaz...@cognitivity.com]
> > But I don't know if these two
> > lines would really have the same result, ...
> >
> > $a = MyScalar;
> > $a = 'MyScalar';
>
> Hrmm. Didn't Larry decree that there are no bare words, but that a class
> name will evaluate to the string representing the spelling of the class
> name? In otherwords, aren't those two assignments identical by definition?

You're correct in that there are no barewords. But, IIRC, a class
name doesn't just evaluate to a string representing the spelling of
the class name. Classes are first-class objects in Perl 6, just as
subroutines were in Perl 5.

The two variables would only behave the same in certain situations
because of symbolic dereferencing. But, they couldn't go by name,
because then what would $foo be here:

$foo = class { has $.bar is public };

As far as the example:

$a = MyScalar;
$b = $a is $a;

(Or something like that) I would imagine that would only work if $a
was known at compile time:

BEGIN { $a = MyScalar; }
$b = $a is $a;

Maybe. Actually, that's quite a difficult question; is MyScalar a
property or a behavior class? Is there a difference, or is the latter
a subset of the former?

But, AFAIK, the two statements are not equivalent.

Luke

Michael Lazzaro

unread,
Jan 12, 2003, 3:17:26 PM1/12/03
to Luke Palmer, tbo...@cogitoinc.com, dam...@conway.org, perl6-l...@perl.org
Luke Palmer wrote:
> I would imagine that would only work if $a was known at compile time:

I think we could do it at runtime too. You could conceivably use
runtime resolution to, for example, choose from between several
different caching behaviors to be passed to a complex routine:

sub get_cached_foo( HashImplementor $implementor ) { # syntax???
my %foo is $implementor;
...
return \%foo;
}

my $foo = &get_cached_foo( LRU_Cache );

That should be OK... we have to know what C<$implementor> is when we
actually do the C<my %foo>, but it doesn't have to be known at compiletime.


My only concern with this particular example:

my $a = MyCache; # (1) $a contains a class identifier
my %b is $a; # (2)
vs.
my $a = 'MyCache'; # (3) $a contains a string
my %b is $a; # (4)

is that 1-2 should work as intended, but 3-4 probably doesn't... because
in (3) $a is just a string, *not* a class. Since a string instance
doesn't implement the interface to be a Scalar implementor, (4) would
give a runtime error. So I *think* the first example should work, and
the second example should not.

> Actually, that's quite a difficult question; is MyScalar a
> property or a behavior class? Is there a difference, or is the latter
> a subset of the former?

Yeah. In the words of another cartoon character, "I *don't* know."

:-/

MikeL

Piers Cawley

unread,
Jan 14, 2003, 5:24:16 AM1/14/03
to Michael Lazzaro, Damian Conway, perl6-l...@perl.org
Michael Lazzaro <mlaz...@cognitivity.com> writes:

> On Thursday, January 9, 2003, at 03:24 AM, Damian Conway wrote:
>> Michael Lazzaro asked:
>>> class FileBasedHash is Hash { ...stuff... };
>>> my %data is FileBasedHash('/tmp/foo.txt');
>> Yes.
>
>>> my $path = '/tmp/foo.txt';
>>> my %data is FileBasedHash($path);
>> Indeed
>
> Great -- then I have only one more question, I think. In the words of
> a certain cartoon character, what's *this* button do?
>
> my $b is $a;

Compile time error. 'is' is a compile time property, scalar values
aren't.

Piers Cawley

unread,
Jan 14, 2003, 5:22:12 AM1/14/03
to Damian Conway, perl6-l...@perl.org
Damian Conway <dam...@conway.org> writes:

> Michael Lazzaro wrote:
>> Which, in turn, implies that the lines:
>> my Foo $a; # (1)
>> my $a is Foo; # (2)
>> my Foo $a is Foo; # (3)
>> are all subtly different. (2) and (3) (auto)instantiate a Foo, but
>> (1) does not.
>
> Correct. Though the instantiated Foo is the "implementation object" and
> not directly accessible (just as the implementation object in a Perl 5
> tie isn't).
>
> BTW, C<my Foo $a is Foo> is just sick!
> (i.e. I'll *definitely* be using it ;-)

Surely anyone who does C<< my Array @foo >>, or C<< my Scalar $foo >>
will be using it, albeit indirectly.

Michael Lazzaro

unread,
Jan 14, 2003, 12:23:16 PM1/14/03
to Piers Cawley, Damian Conway, perl6-l...@perl.org
On Tuesday, January 14, 2003, at 02:24 AM, Piers Cawley wrote:

> Michael Lazzaro <mlaz...@cognitivity.com> writes:
>> Great -- then I have only one more question, I think. In the words of
>> a certain cartoon character, what's *this* button do?
>>
>> my $b is $a;
>
> Compile time error. 'is' is a compile time property, scalar values
> aren't.

That's what I first thought, but... why is that a compiletime error, if
the previous example

my %data is FileBasedHash($path);

is not?

Or, to rephrase the question, I would assume that the above allows
$path to be resolved runtime, not just compiletime, or its utility
seems sadly limited. So if implementor classes can be instantiated at
runtime, are they really C<is> compile-time properties, or are they
'is' meaning 'isa', and is that runtime-settable? [*1]

(Thinking aloud) Perhaps this is an example of why having both "is"
and "isa" as keywords might be a good idea. Because 'is' implies
compiletime, but implementor classes aren't really properties, they're
a form of (pseudo?)inheritance. So maybe

my %data isa FileBasedHash($path);
-or-
my $b isa $a;

Might be clearer(???) than reusing C<is> for this purpose. Dunno. [*2]

MikeL

[*1] It almost seems like
my %data but FileBasedHash($path);
would be more appropriate, but I think we can agree that's *horrid*.

[*2] This ties strongly into the whole issue of allowing some form of
prototype-based (classless) inheritance. I try to avoid it, but damn
it, *it keeps pulling me back in*! Right now I just need to know what
'is' is, for the sake of arrays and hashes.

:-/

Dan Sugalski

unread,
Jan 14, 2003, 12:52:49 PM1/14/03
to Michael Lazzaro, Piers Cawley, Damian Conway, perl6-l...@perl.org
At 9:23 AM -0800 1/14/03, Michael Lazzaro wrote:
>On Tuesday, January 14, 2003, at 02:24 AM, Piers Cawley wrote:
>>Michael Lazzaro <mlaz...@cognitivity.com> writes:
>>>Great -- then I have only one more question, I think. In the words of
>>>a certain cartoon character, what's *this* button do?
>>>
>>> my $b is $a;
>>
>>Compile time error. 'is' is a compile time property, scalar values
>>aren't.
>
>That's what I first thought, but... why is that a compiletime error,
>if the previous example
>
> my %data is FileBasedHash($path);
>
>is not?

I'm not sure either of them *has* to be an error, as the compile-time
properties that is imparts need to be evalutated and applied at
runtime. The "my $foo is $bar" would mean that we couldn't do any
compile-time type checking, but that's not a huge deal as presumably
you wouldn't *want* any type checing in that case.

Whether it is a good idea or not from a maintenance/programmer-brain
standpoint is a separate issue. I think I'd rather dislike having to
maintain code that did it, but I can see a few good reasons to do it.
--
Dan

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

Simon Cozens

unread,
Jan 15, 2003, 6:52:37 PM1/15/03
to perl6-l...@perl.org
mlaz...@cognitivity.com (Michael Lazzaro) writes:
> Great -- then I have only one more question, I think. In the words of
> a certain cartoon character, what's *this* button do?
>
> my $b is $a;

I think at this stage it's probably worth reminding everyone that not
every string of characters *needs* to be syntactically valid Perl 6,
despite our best efforts.

--
"Do not meddle in the affairs of cats, for they are subtle and will piss on
your computer." --Bruce Graham

Damian Conway

unread,
Jan 18, 2003, 1:27:45 AM1/18/03
to perl6-l...@perl.org
Michael Lazzaro wrote:

> Great -- then I have only one more question, I think. In the words of a
> certain cartoon character, what's *this* button do?
>
> my $b is $a;

Syntax error, I'd expect. Though the desired effect could probably be achieved
with the C<prop> meta-property:

my $b is prop($a);

Damian

Damian Conway

unread,
Jan 18, 2003, 1:29:37 AM1/18/03
to perl6-l...@perl.org
Jonathan Scott Duff wrote:

> will this:
>
> my $a $b;
>
> be illegal?

I certainly hope so!

Damian

Damian Conway

unread,
Jan 18, 2003, 1:32:22 AM1/18/03
to perl6-l...@perl.org
Piers Cawley observed:

>>BTW, C<my Foo $a is Foo> is just sick!
>>(i.e. I'll *definitely* be using it ;-)
>
> Surely anyone who does C<< my Array @foo >>, or C<< my Scalar $foo >>
> will be using it, albeit indirectly.

Of course, but without the brain-twisting effect of the
repeated classname.

;-)

Damian

0 new messages