Re: Variable Types Vs Value Types
[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? :) -- It's a testament to the versatility of the human mind that we're so able to compensate for our own incompetence. - Darrell Furhiman
Re: More thougths on DOD
Mitchell N Charity wrote: The attached patch adds a scheme where: - gc flags are in the pool, and - pmc-pool mapping is done with aligned pools and pmc pointer masking. Thanks for that. Observations: - It's fast. (The _test_ is anyway.) Perhaps 4x random, 10x+ linear. I see ~8x/~12x with pmc-pool calculation on my Athlon with -O3. - PMC size doesn't matter here, because we never actually touch them. Yep, for marking. Putting the PMC on the free_list then would still be cheaper for smaller PMCs I think. Mitchell (I assume at some point Dan will say ok, we've demonstrated the minimally required gc performace... so now let's get back to actually writing the thing That will quiet my currently fluttering premature optimization warning flags. ;) I think, we should have some schemes in parallel. I have here my small PMC patch (though w/o morphing or such), separated flags shouldn't be too hard due to the flag accessor macros. Do we already have a general purpose memalign() function and a config test for it - or better, was there some in past? leo
Re: More thougths on DOD
Attached test program shows some additional effects of PMC size and
timing. [...]
Nifty.
The attached patch adds a scheme where:
- gc flags are in the pool, and
- pmc-pool mapping is done with aligned pools and pmc pointer masking.
Observations:
- It's fast. (The _test_ is anyway.) Perhaps 4x random, 10x+ linear.
- PMC size doesn't matter here, because we never actually touch them.
Mitchell
(I assume at some point Dan will say ok, we've demonstrated the
minimally required gc performace... so now let's get back to actually
writing the thing That will quiet my currently fluttering
premature optimization warning flags. ;)
--- tpmc.c Mon Jan 6 14:55:14 2003
+++ r02.c Mon Jan 6 17:24:32 2003
@@ -52,6 +52,11 @@
int fill[3];
} SPMC;
+struct pool_pmc {
+char *flags;
+PMC mem[1];
+} * pool_pmc[N];
+
int main(int argc, char *argv[])
{
@@ -152,6 +157,76 @@
rdtsc(b);
printf(%d empty ticks %10ld\n, i, b - a - e);
+/* alternate aligned pool with sep flags */
+
+#define SIZE2 (SIZE-1)
+#define ALIGN (SIZE*(8*sizeof(int)))
+for (i = 0; i N; i++) {
+pool_pmc[i] = memalign(ALIGN, SIZE*sizeof(PMC));
+pool_pmc[i]-flags = calloc(SIZE, sizeof(char));
+/*printf(pool %d %p\n, i, pool_pmc[i]);*/
+}
+
+for (n = 0; n 3; n++) {
+rdtsc(a);
+for (j = 0; j N; j++) {
+l = (int) ((double)N * rand()/(RAND_MAX+1.0));
+for (i = 0; i SIZE2; i++) {
+k = (int) ((double)SIZE2 * rand()/(RAND_MAX+1.0));
+pool_pmc[j]-flags[i] |= 1;
+}
+}
+rdtsc(b);
+printf(%d linear PMC sep-flags flag-only ticks %10ld\n, i, b - a - e);
+
+rdtsc(a);
+for (j = 0; j N; j++) {
+l = (int) ((double)N * rand()/(RAND_MAX+1.0));
+for (i = 0; i SIZE2; i++) {
+k = (int) ((double)SIZE2 * rand()/(RAND_MAX+1.0));
+pool_pmc[j]-flags[k] |= 1;
+}
+}
+rdtsc(b);
+printf(%d random PMC sep-flags flag-only ticks %10ld\n, i, b - a - e);
+
+#define P2I(ptr) ((unsigned long)(ptr))
+#define CALC(ik) \
+{ \
+PMC *ppmc = (PMC*)(pool_pmc[j]-mem[(ik)]); \
+struct pool_pmc *pool = ((struct pool_pmc *) \
+ (P2I(ppmc) ~(ALIGN-1))); \
+size_t n = ((P2I(ppmc) - P2I((pool-mem[0]))) \
+ /sizeof(PMC)); \
+/*printf( pool %d %p pmc# %d %p -pool %p pmc# %d\n, \
+ j,pool_pmc[j],i,ppmc,pool,n);*/ \
+pool-flags[n] |= 1; \
+}
+
+
+rdtsc(a);
+for (j = 0; j N; j++) {
+l = (int) ((double)N * rand()/(RAND_MAX+1.0));
+for (i = 0; i SIZE2; i++) {
+k = (int) ((double)SIZE2 * rand()/(RAND_MAX+1.0));
+CALC(i);
+}
+}
+rdtsc(b);
+printf(%d linear PMC sep-flags PMC-flag ticks %10ld\n, i, b - a - e);
+
+rdtsc(a);
+for (j = 0; j N; j++) {
+l = (int) ((double)N * rand()/(RAND_MAX+1.0));
+for (i = 0; i SIZE2; i++) {
+k = (int) ((double)SIZE2 * rand()/(RAND_MAX+1.0));
+CALC(k);
+}
+}
+rdtsc(b);
+printf(%d random PMC sep-flags PMC-flag ticks %10ld\n, i, b - a - e);
+
+}
return 0;
}
Re: Variable Types Vs Value Types
Piers Cawley [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Dan Sugalski [EMAIL PROTECTED] writes: An object is a data type, as much as an array or hash is a data type, but that doesn't make an array an object. [insert obligatory all men are Socratese quote here) I really hope you're wrong here Dan. At least in that particular case. Being able to inherit from Array or Hash or whatever as a neater way of implementing, say, Tie semantics would be remarkably useful... Let me suggest two interpretations of Dan's remark that seem reasonable to me: 1. The internal implementation for an array is an optimization beyond that of a generic object. This would not be visible to the programmer, so isn't important wrt the language. 2. There is a primitive array type that is promoted to an objectified Array class when needed. This would be analogous to the int/Int distinction for primitive numbers. This would be visible to programmers, but may be acceptable for the same reason as the int/Int types are. Of course, it's up to Dan to clarify his own intent: these are just my opinions. Dave.
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
[perl #19800] LOL
# New Ticket Created by ([EMAIL PROTECTED]) # Please include the string: [perl #19800] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=19800 Below is the result of your feedback form. It was submitted by [EMAIL PROTECTED] ([EMAIL PROTECTED]) on Tuesday, January 7, 2003 at 12:57:14 --- g4i: Hey!! What's Up? I'm *Debbie* 20/F/San Diego/Webcam Pics. I'm *LIVE* on my *FREE* Webcam mostly 24/7 so if you wanna come in and chat or see me go to my Personal Homepage at http://www.freelivecamgirls.net and i'll talk to you in a bit hun! If you join and the webchat is already full im sorry, just wait like 5 minutes and then you'll be able to see me LIVE!! *Remember* this is my Personal Homepage so of course its *FREE* =) 333 *Debbie* 333 PS.Remember my Personal Homepage is http://www.freelivecamgirls.net and hopefully I can chat with you soon!! oh yah!! If you don't have a webcam of your own its ok!! You can still watch and chat with me then!! ok!! ByE!! 333 *Debbie* 333 7k4y ---
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 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
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
--- Deborah Ariel Pickett [EMAIL PROTECTED] 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
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
Re: [perl #x19800] LOL
At Tue, 07 Jan 2003 18:59:22 GMT, ([EMAIL PROTECTED]) (via RT) wrote: # New Ticket Created by ([EMAIL PROTECTED]) # Please include the string: [perl #19800] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=19800 Smells like spam to me. I've nuked it. X-Spam-Status: No, hits=5.3 required=7.0 tests=BUGGY_CGI,CARRIAGE_RETURNS,FORGED_YAHOO_RCVD,SPAM_PHRASE_02_03,SUPERLONG_LINE version=2.43 If this address starts to get hammered with things getting through the filter, we'll put a human in the loop. -R
[perl #19807] [PATCH] rx.ops doc typos
# New Ticket Created by Jim Radford # Please include the string: [perl #19807] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=19807 I found a few typos while reading through the documentation in rx.ops. -Jim --- parrot-0.0.9/rx.ops.origMon Jan 6 15:28:08 2003 +++ parrot-0.0.9/rx.ops Mon Jan 6 15:38:41 2003 @@ -405,7 +405,7 @@ =item Crx_oneof(in str, inout int, in pmc, inconst int) -Matches if the current character is one of the characters in the second parameter. +Matches if the current character is one of the characters in the third parameter. This op requires that its input be sorted for efficiency. Further, it requires that all ranges (Ca-z) be expanded by the regex compiler. @@ -437,7 +437,7 @@ =item Crx_oneof_bmp(in str, inout int, in pmc, inconst int) -This op has the exact same behavior as Crx_oneof, except that the second parameter +This op has the exact same behavior as Crx_oneof, except that the third parameter is a Pointer to a bitmap generated by Crx_makebmp. =cut @@ -542,10 +542,10 @@ =item Crx_search(in str, out int, inout int, in str, inconst in) -Searches for the literal $4 on the string $1. Sets $2 to the current +Searches for the literal $4 on the string $1 starting at $3. Sets $2 to the current index in the string (after the literal), and $3 to start_index. -Branches to $4 if the literal is not found. +Branches to $5 if the literal is not found. =cut @@ -597,10 +597,10 @@ =item Crx_search_char (in str, out int, inout int, in str, inconst in) -Searches for the char $4 on the string $1. Sets $2 to the current +Searches for the char $4 on the string $1 starting at $3. Sets $2 to the current index in the string (after the char) -Branches to $4 if the char is not found. +Branches to $5 if the char is not found. The char is expressed as an integer representing its codepoint. @@ -914,7 +914,7 @@ set I0, 0 $start: - rx_literal, S0, I1, I0, foobar, $fail + rx_search, S0, I1, I0, foobar, $fail print match branch $end $fail:
Re: [perl #x19800] LOL
On Tue, Jan 07, 2003 at 02:04:25PM -0800, Robert Spier wrote: At Tue, 07 Jan 2003 18:59:22 GMT, ([EMAIL PROTECTED]) (via RT) wrote: # New Ticket Created by ([EMAIL PROTECTED]) # Please include the string: [perl #19800] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=19800 Smells like spam to me. I've nuked it. X-Spam-Status: No, hits=5.3 required=7.0 tests=BUGGY_CGI,CARRIAGE_RETURNS,FORGED_YAHOO_RCVD,SPAM_PHRASE_02_03,SUPERLONG_LINE version=2.43 There's no test for sent-from-a-formmail script? For a bug report that alone ought to sent it over the spam threshold Nicholas Clark
Re: [perl #19729] [PATCH] SPARC JIT support for restart
Applied, thanks. Daniel Grunblatt. On Sunday 05 January 2003 01:10, Jason Gloudon (via RT) wrote: # New Ticket Created by Jason Gloudon # Please include the string: [perl #19729] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=19729 This patch adds JIT support for restart and similar ops.
Re: Array Questions
--- Deborah Ariel Pickett [EMAIL PROTECTED] 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++)
{
..
}
}
Re: Array Questions
--- Austin Hastings [EMAIL PROTECTED] wrote:
--- Deborah Ariel Pickett [EMAIL PROTECTED] 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++)
{
..
}
}
Hit the post key too soon, there. Anyway, visualize an example
involving @items.length and $zipcode.length ...
=Austin
Re: Variable Types Vs Value Types
At 9:47 AM -0800 1/6/03, Dave Whipp wrote: Piers Cawley [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Dan Sugalski [EMAIL PROTECTED] writes: An object is a data type, as much as an array or hash is a data type, but that doesn't make an array an object. [insert obligatory all men are Socratese quote here) I really hope you're wrong here Dan. At least in that particular case. Being able to inherit from Array or Hash or whatever as a neater way of implementing, say, Tie semantics would be remarkably useful... Let me suggest two interpretations of Dan's remark that seem reasonable to me: 1. The internal implementation for an array is an optimization beyond that of a generic object. This would not be visible to the programmer, so isn't important wrt the language. That's sort of like saying that a pointer or a double is an optimization beyond the general object. (Or, more succinctly, No :) 2. There is a primitive array type that is promoted to an objectified Array class when needed. This would be analogous to the int/Int distinction for primitive numbers. This would be visible to programmers, but may be acceptable for the same reason as the int/Int types are. Not unless Larry really insists. Primitive arrays aren't sub-, super-, or side-classes of objects--they aren't objects at all. (They're arrays, hence the name array) You may be able to treat them in some ways as objects, but that doesn't make them objects any more than treating arrays like integers makes them integers. -- 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
On Tue, 7 Jan 2003, Dan Sugalski wrote: 2. There is a primitive array type that is promoted to an objectified Array class when needed. This would be analogous to the int/Int distinction for primitive numbers. This would be visible to programmers, but may be acceptable for the same reason as the int/Int types are. Not unless Larry really insists. Primitive arrays aren't sub-, super-, or side-classes of objects--they aren't objects at all. (They're arrays, hence the name array) You may be able to treat them in some ways as objects, but that doesn't make them objects any more than treating arrays like integers makes them integers. Perhaps you could explain how the $0 object will work in your mind. A5 assert that $0 is a object, and it behaves as an array and a hash, depending on how you subscript it. Typeglobs are gone, and we're all hoping the TIE interface is gone too, so how will this effect be accomplished? ~ John Williams
Re: Variable Types Vs Value Types
On Mon, 6 Jan 2003, Michael Lazzaro wrote:
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:
my Foo $a; # declares $a as holding objects of type CFoo
my $a is Foo; # instantiates $a as a CFoo.
Oh dear. That looks quite wrong.
I'm still not buying the autoinstantiation argument. All the other
(non-M.L.) threads I have read are requiring
my $a is Foo = .new; # or some such...
Both your examples above create the varible $a, but it contains the value
of undef, not an instance of Foo.
OTOH, you can autoinstantiate arrays and hashes like this:
$a[3]{fum};
which will create an array(ref) in $a containing 3 undefs and a hash(ref)
which contains a single key fum with the value of undef.
It would be nice if objects could inherit this sort of functionality
from arrays and or hashes. Or perhaps it's a DIY thing:
class Foo {
method do_it ( $x ) {
$_ //= .new;
...
}
}
which may not be entirely syntactically correct, but hopefully you get the
idea. It would be really easy to do if something like a class invariant
existed which ran _before_ each method...
~ John Williams
Re: Variable Types Vs Value Types
At 12:21 PM +0100 1/7/03, Rafael Garcia-Suarez wrote: 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. I don't see any good reason for that. If we're providing a delegation scheme the delegated class should look like a subclass of the delegatee, even if it's not really and we're actually thunking the heck out of things) How do you override vtable methods from within Perl 6 ? A package/class with properly named subs/methods will do it, though Larry may require a property or attribute. You'll also be able to build them by hand and swap them in and out (potentially on a per-variable basis) if you need to. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
