Re: Variable Types Vs Value Types
--- Michael Lazzaro [EMAIL PROTECTED] wrote: These lines all declare @a to be an array that stores ints. That would imply that the is Array part is actually instantiating (Cnewing) the array... you're not saying that @a can someday hold an array obj, you're saying it already _is_ an array obj. So we're using is Blah here as a method of creating an already-instantiated object, not just typing a variable(?) But that, in turn, would imply that: When you declare a variable, but don't assign to it, what value is stored in it? This answer could be: nothing -- its autovivified on its first use. If that first use is an assignment, then the variable's type determines what constructor to use. Thus: my (@a,@b,@c) is MyArray; ... @a = (1,2,3); # calls MyArray.new(List) @b = Array.new(1,2,3); # calls MyArray.new(Array) print int(@c); # calls MyArray.new() This could easily be extended to Scalars: we could autovivify on first use of an uninitialized variable. The default Scalar class's .new method would create an undef value; but other classes could do something more interesting. Dave. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Variable Types Vs Value Types
At 9:30 AM + 1/7/03, Simon Cozens wrote: [EMAIL PROTECTED] (Dan Sugalski) writes: Well, you'll certainly be able to use delegation to get in the way if nothing else. Beyond that I'm not sure, but anything that's not based on the parrot Object PMC (which we've not quite yet defined) won't necessarily be directly inheritable from. So make Hashes and Arrays based on the Parrot Object PMC. Why let implementation get in the way of a really good language? :) Ah, it's too early for a good rejoinder, but rest assured I almost had one. :) The short answer, I suppose, is that we're not recreating Smalltalk--at least some small nod is being made towards Practicality. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Variable Types Vs Value Types
[EMAIL PROTECTED] (Dan Sugalski) writes: The short answer, I suppose, is that we're not recreating Smalltalk--at least some small nod is being made towards Practicality. I really don't follow your argument here. What's impractical about being able to inherit from Arrays? -- Familiarity breeds facility. -- Megahal (trained on asr), 1998-11-06
Re: Variable Types Vs Value Types
At 10:54 AM + 1/7/03, Simon Cozens wrote: [EMAIL PROTECTED] (Dan Sugalski) writes: The short answer, I suppose, is that we're not recreating Smalltalk--at least some small nod is being made towards Practicality. I really don't follow your argument here. What's impractical about being able to inherit from Arrays? Nothing, the impractical part is making arrays objects--they aren't, and we're not particularly going to go out of our way to make them so. Like I said, you can always use delegation to subclass an array, or limit yourself to an odd and restrictive subset of behaviour. (Basically just vtable method overriding) I'm dropping a dump of parrot's object model thursday, at which point everyone can rip into me properly and with good facts to back up theories of my crack-headedness. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Variable Types Vs Value Types
[EMAIL PROTECTED] (Dan Sugalski) writes: Nothing, the impractical part is making arrays objects--they aren't, Hang on. We're saying that they should be. You're saying that they're not. You haven't produced any reasons *WHY* they're not. Why *aren't* they arrays? It's perfectly practical; most other scripting languages do it. If Parrot wants to support them, Parrot will have to do it too. So what's the big problem? and we're not particularly going to go out of our way to make them so. Your argument seems to be: We can't make arrays objects because they aren't objects and we aren't making them objects. I don't find that a very strong argument; at best, it's a case of imposing your particular favourite implementation method on the language design, and at worst it's completely circular. -- In matters of principle, stand like a rock; in matters of taste, swim with the current. -- Thomas Jefferson
Re: Variable Types Vs Value Types
[EMAIL PROTECTED] (Simon Cozens) writes: they arrays? Bluh, I mean objects. Getting carried away; this is something I do actually care about, and I'll be quite unhappy if we screw it up. -- The Blit is a nice terminal, but it runs emacs.
Re: Variable Types Vs Value Types
Dan Sugalski [EMAIL PROTECTED] wrote: Like I said, you can always use delegation to subclass an array, or limit yourself to an odd and restrictive subset of behaviour. (Basically just vtable method overriding) Delegation has drawbacks compared to inheritance : you can't use a object that delegates to class Foo where an instance of Foo is expected. Unless Foo and the class that delegates to Foo both inherit from a common (abstract) superclass (ArrayInterface ? Dictionary ?) (Duh, this is just starting to sound like Java.) How do you override vtable methods from within Perl 6 ?
Array Questions
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 Ctie-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 Cmy @a is Array, or even just
Cmy @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 Cmy $a
my $a is int;
my $a is Scalar of int; # long way of saying Cmy int $a?
my $a is Scalar returns int; # long way of saying Cmy 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
Re: Array Questions
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 Ctie-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
[EMAIL PROTECTED]
Re: Array Questions
--- Michael Lazzaro [EMAIL PROTECTED] 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
Re: Array Questions
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 | [EMAIL PROTECTED]
Atlanta, GA 30348 USA | +1 404 827 4754
Re: Array Questions
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 [EMAIL PROTECTED] 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
Re: Array Questions
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
Re: Array Questions
Mark J. Reed [EMAIL PROTECTED] 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...)
Re: Array Questions
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. -- Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED] 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
