Re: Parrot: maximizing the audience
At 12:26 AM -0400 9/4/02, Bryan C. Warnock wrote: >IANADan, but he's aware of these issues, and is/has been thinking about >them. Heh. Well, I am. Lucky me. :) This is something I've been thinking about since we formally announced we were going semi-language-neutral. >Separating Parrot isn't as trivial as s/erl/arrot/g, and probably won't >be done *completely*. Nope. What's more likely is that Parrot will accumulate bits from other languages--rather than losing Perl we'll gain Ruby and Python. Maybe others too. >We're not going to fool anyone that this isn't a Pet Perl Project, and >while other communities are eyeing us, it's not clear that the amount of >work to obliterate that line is going to be worth the cost. Once there's sufficient reason, and I'm pretty easy on this, we'll switch to a more neutral look. Or if there turns out to be a good time, we can switch then too. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Parrot: maximizing the audience
On Tue, 3 Sep 2002, Markus Laire wrote: > > * the name "perl6-internals" is really too restrictive (but this point has > > already been discussed last week). > Would it be possible to rename "perl6-internals" now to something > better like "parrot-internals"? +1. > There probably are some big problems in renaming an active list, but > this could give us more non-perl developers interested in parrot. [EMAIL PROTECTED] was renamed at one point, due to conflict related to the name. The old addresses for it still work, but it's renamed as far as the outside world's concerned. R.
RE: atomicness and \n
On Tue, 2002-09-03 at 23:57, Luke Palmer wrote: > On Tue, 3 Sep 2002, Brent Dax wrote: > > > > How can you be sure that is implemented as a character > > class, as opposed to (say) an alternation? > > What's the difference? :) > > Neglecting internals, semantically what I the difference? > One *possible* semantic difference is a guaranteed matching order. Nothing (historically) has ever really dictated that character classes must match left-to-right, as alternation does. That's mainly because character classes have always been of a uniform width, in which case it is only going to match one thing and one thing only. Whether that will be an issue with variable-width characters in a class is largely going to rely on the semantics that are dictated. -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
A show of hands of the non-perl people?
Can I get a quick show of hands for the folks working on Parrot, even peripherally, who *aren't* perl folks? Private e-mail's fine, if you don't want to admit to it publically. :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[web-PATCH] parrot logo
whoever put the parrot logo on www.parrotcode.org, make your penances, because you are in sin! you will find attached a replacement for that logo which doesn't hurt like a kick in the eye, and above all does s/GIF/PNG/g :-) cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print; multicol.png Description: PNG image
Re: Parrot: maximizing the audience
On Wed 04 Sep 2002 03:47, Richard Soderberg <[EMAIL PROTECTED]> wrote: > On Tue, 3 Sep 2002, Markus Laire wrote: > > > > * the name "perl6-internals" is really too restrictive (but this point has > > > already been discussed last week). > > > Would it be possible to rename "perl6-internals" now to something > > better like "parrot-internals"? > > +1. > > > There probably are some big problems in renaming an active list, but > > this could give us more non-perl developers interested in parrot. > > [EMAIL PROTECTED] was renamed at one point, due to conflict related to the > name. The old addresses for it still work, but it's renamed as far as the > outside world's concerned. Most (90%) of the smoke report still flow in through [EMAIL PROTECTED] only very few use [EMAIL PROTECTED] /maybe/ I should change my sig :P -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3, WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: [EMAIL PROTECTED] http:[EMAIL PROTECTED]/ [EMAIL PROTECTED] send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
Re: Multimethod Dispatch
David Wheeler wrote: > Ah, yes, the same thing exists in Java. I remember, now. I thought Java only has over loading? Over loading is what C++ has. It is not the same as multi-dispatch. The trouble with over loading is that the compiler uses static (compile-time) type information to select the over loaded method. This can create subtle bugs when people try to re-use code by sub-classing. - Ken
Re: [web-PATCH] parrot logo
At 12:30 PM +0200 9/4/02, Aldo Calpini wrote: >whoever put the parrot logo on www.parrotcode.org, >make your penances, because you are in sin! Sheesh, it's an *image*. Sin's hardly the appropriate word here--it's not like someone robbed a bank or kicked a nun or something. >you will find attached a replacement for that logo >which doesn't hurt like a kick in the eye, and above >all does s/GIF/PNG/g :-) The logo as currently used suffers from scaling issues, as it looks like the full-size one's used with a size specified. We should definitely use a custom-scaled version, as trusting browsers to scale well's a bit of a dodgy thing. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Parrot: maximizing the audience
Sean O'Rourke wrote: > ... I don't see how giving the list a > different name will have any real effect ... ? It will have a huge psychological effect, at least outside our tight little club. But if that's only as far as you can see... -- John Douglas Porter
Re: Parrot: maximizing the audience
Bryan C. Warnock wrote: > IANADan, but he's aware of these issues, and is/has been thinking about > them. Fine. But what does Larry think? > We're not going to fool anyone that this isn't a Pet Perl Project, and > while other communities are eyeing us, it's not clear that the amount of > work to obliterate that line is going to be worth the cost. Hm. We can make it possible, or we can make it impossible. Which way, which way -- John Douglas Porter
Re: Parrot: maximizing the audience
Dan Sugalski wrote: > What's more likely is that Parrot will accumulate bits from > other languages--rather than losing Perl we'll gain Ruby and Python. > Maybe others too. But that doesn't address the real issue, which is -- Are we really serious about enabling other languages to target this machine? Or do we want them always to be, at best, second-class citizens? > Once there's sufficient reason, and I'm pretty easy on this, we'll > switch to a more neutral look. Some folks seem to think that sufficient reason exists now. > Or if there turns out to be a good time, we can switch then too. How could any time later than now be a better time than now? -- John Douglas Porter
Re: Parrot: maximizing the audience
At 7:34 AM -0400 9/4/02, John Porter wrote: >Sean O'Rourke wrote: >> ... I don't see how giving the list a >> different name will have any real effect ... > >? > >It will have a huge psychological effect, at least outside our tight >little club. But if that's only as far as you can see... Really? At the moment, how many people outside the tight little club actually care about the name of the mailing list? And how many more would really care if we changed the name? -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #16962] [PATCH] add ICU to the glossary
At 1:31 PM + 9/3/02, Kevin Falcone (via RT) wrote: >Someone asked on IRC this morning about what ICU is. They mentioned >not finding it in the glossary, so here is an explanation and a link. Applied, thanks. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Parrot: maximizing the audience
At 7:36 AM -0400 9/4/02, John Porter wrote: >Bryan C. Warnock wrote: >> IANADan, but he's aware of these issues, and is/has been thinking about >> them. > >Fine. But what does Larry think? Hadn't particularly asked him. Does it really matter? -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Parrot: maximizing the audience
On Wed, 4 Sep 2002, Dan Sugalski wrote: > Nope. What's more likely is that Parrot will accumulate bits from > other languages--rather than losing Perl we'll gain Ruby and Python. > Maybe others too. Parrot: There's more than one language to do it. Sorry but I couldn't resist, Rod -- "Open Source Software - Sometimes you get more than you paid for..."
Re: Parrot: maximizing the audience
At 7:40 AM -0400 9/4/02, John Porter wrote: >Dan Sugalski wrote: > > Once there's sufficient reason, and I'm pretty easy on this, we'll >> switch to a more neutral look. > >Some folks seem to think that sufficient reason exists now. That's fine. You don't have to convince some folks. You have to convince me. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[perl #16992] [PATCH] multiarray fixes
# New Ticket Created by Josef Höök
# Please include the string: [perl #16992]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16992 >
I've noticed that the key patch defunced some function in
multiarray ( somehow replaced key->next->next with key_next ).
This patch fixes it. This patch also replaces [perl #16931].
/Josef
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/36507/29473/0ea887/multiarray_020903.patch
--- multiarray.pmc.orig Sun Sep 1 20:32:13 2002
+++ multiarray.pmc Tue Sep 3 22:37:39 2002
@@ -10,7 +10,7 @@
* (y-1)X0+x
*
* Where X0 is the length of X-base (fig 1.1). We use this equation in
- * calc_offset to get offset from the buffer we store our data in.
+ * calc_offset_multi to get offset from the buffer we store our data in.
* Lets say we want to store (2,2) in a buffer. We then take values and do:
* (2-1)3 + 2 = 5.
*
@@ -36,12 +36,12 @@
* Current code has complexity:
*
*O(1) writing.
- *O(1) reading.
+ *O(?) reading.
* History:
- *Initial revision by Josef HËËk
+ *Initial revision by Josef Hook <[EMAIL PROTECTED]>
* Notes:
- *Future plan is to make calc_offset_multi polymorphic
- *and to make it handle multidimensions: done
+ *Future plan is to handle multidimensions: done
+ *Move code into vtable functions:
* References:
*/
@@ -100,15 +100,16 @@
INTVAL loop_i;
INTVAL inner_loop_i;
dim_key = cell_data->dimension;
-
-my_key = key_next(interpreter, k);
+my_key = k;
if(cell_data->cell_buffer != NULL && dim_key != NULL && my_key != NULL ) {
/* first part of alg.
* (i + (j-1)*Ni
*/
- offset = key_integer(interpreter, k) + key_integer(interpreter, my_key) *
key_integer(interpreter, dim_key);
+ offset = key_integer(interpreter, k);
+ k = key_next(interpreter, k);
+ offset += key_integer(interpreter, k) * key_integer(interpreter, dim_key);
/* add the rest of algoritm
* ... + (k-1)*Ni*Nj + (l-1)*Ni*Nj*Nk ...
@@ -120,20 +121,19 @@
*
*/
loop_i = 2;
-my_key = key_next(interpreter, my_key);
- while ( my_key != NULL ) {
- inner_loop_i = loop_i;
-
+
+ while ( key_next(interpreter, key_next(interpreter, my_key)) != NULL ) {
+ inner_loop_i = loop_i;
while ( inner_loop_i > 0 && key_next(interpreter, dim_key) != NULL ) {
prod_of_dims *= key_integer(interpreter, dim_key);
dim_key = key_next(interpreter, dim_key);
inner_loop_i--;
+
}
- offset += key_integer(interpreter, my_key) * prod_of_dims;
-
+ offset += key_integer(interpreter, key_next(interpreter,
+key_next(interpreter, my_key))) * prod_of_dims;
my_key = key_next(interpreter, my_key);
loop_i++;
}
@@ -141,6 +141,7 @@
/* only 1 dim */
offset = key_integer(interpreter, k);
}
+
return offset;
}
@@ -184,8 +185,6 @@
}
-
-
static CELL_B *new_marray( Interp *interpreter )
{
CELL_B *b = (CELL_B *)new_bufferlike_header(interpreter, sizeof(*b));
@@ -217,12 +216,11 @@
oldkey = key;
size = 1;
-
-while (key_next(interpreter, key) != NULL) {
-
- size *= key_integer(interpreter, key);
- key = key_next(interpreter, key);
-
+while (key != NULL) {
+
+size *= key_integer(interpreter, key);
+key = key_next(interpreter, key);
+
}
marray->size = size;
@@ -230,7 +228,7 @@
Parrot_reallocate(interpreter, marray->cell_buffer, marray->size * sizeof(CELL));
memset(marray->cell_buffer->bufstart, 0, marray->size * sizeof(CELL));
marray->dimension = oldkey;
-
+
}
@@ -245,6 +243,10 @@
INTVAL offs = 0;
INTVAL ret_val = 0;
+INTVAL dead_val = 0;
+INTVAL my_val = 0;
+INTVAL iterate_count = 0;
+
offs = calc_offset_multi(interpreter, mg_marray, key);
base = (CELL *)mg_marray->cell_buffer->bufstart;
@@ -261,7 +263,48 @@
if(virtual_addr == buffer_ptr_virt) {
ret_val = buffer_ptr->data.int_val;
} else {
- /* PANIC */
+ /* OK here's the deal. We should never come to this point BUT if we have
+* something must have happened to our cell buffer. Code below is
+* a cut-paste from my matrix code though structures differs
+ * it should work anyway. TODO: verify its validity
+ */
+
+ dead_val = buffer_ptr->virtual_addr; // save our begin val
[perl #16993] ScanMail Message: To Sender, action taken by attachment blocking.
# New Ticket Created by System Attendant # Please include the string: [perl #16993] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=16993 > ScanMail for Microsoft Exchange has blocked a file attachment(s). Place = [EMAIL PROTECTED] Sender = Josef "Hvvk Subject = [perl #16992] [PATCH] multiarray fixes Delivery Time = September 04, 2002 (Wednesday) 08:48:14 Action on file attachment(s): Quarantine 'multiarray_020903.patch' to C:\Program Files\Trend\Smex\blocked_attachments at Marc Belgrave Message from recipient's administrator: As part of Algorithmics Security Policy on e-mail, this attachment has been blocked from entering our mail system. The attachment name can be found in this message. For Algorithmics Employees who require more information on how to send and receive e-mail with attachments, please refer to the following: http://algoweb/it/docs/documentation/virus-faq.html . For people external to Algorithmics, please contact the intended recipient for further informaton.
Re: Multimethod Dispatch
From: Ken Fox [EMAIL PROTECTED] > Over loading is what C++ has. It is not the same as > multi-dispatch. The trouble with over loading is that the > compiler uses static (compile-time) type information to > select the over loaded method. This can create subtle > bugs when people try to re-use code by sub-classing. So, just to clarify, does that mean that multi-dispatch is (by definition) a run-time thing, and overloading is (by def) a compile time thing? -Miko mail2web - Check your email from the web at http://mail2web.com/ .
Re: Parrot: maximizing the audience
On Wed, Sep 04, 2002 at 07:42:24AM -0400, Dan Sugalski wrote: > At 7:34 AM -0400 9/4/02, John Porter wrote: > >Sean O'Rourke wrote: > >> ... I don't see how giving the list a > >> different name will have any real effect ... > > > >? > > > >It will have a huge psychological effect, at least outside our tight > >little club. But if that's only as far as you can see... > > Really? At the moment, how many people outside the tight little club > actually care about the name of the mailing list? And how many more > would really care if we changed the name? I'd much prefer someone to implement something that allows python programs to run on parrot. Not that I've ever used python, let alone hacked its innards. My reasons are: 1: I'd like some other existing mainstream language to be working 2: The impression I get is that python would be the easiest. (in that it I believe that it has external bytecode of a well-known format) 3: It ought to be easier than either (full) perl5 or (not yet fully written) perl6 However, I confess I'm not sufficiently concerned about this to actually try it. (There are too many things I still want to do with the perl5, it seems) Nicholas Clark
Re: Parrot: maximizing the audience
Dan Sugalski wrote: > At 7:40 AM -0400 9/4/02, John Porter wrote: > > > >Some folks seem to think that sufficient reason exists now. > > That's fine. You don't have to convince some folks. You have to > convince me. Being ultra-pragmatic, the name change: - costs nothing - might make some folks happier So it's a win-win, isn't it? Even if, of course, it doesn't really matter at all. Although symbols do matter sometimes, specially in politics, which is just what we are talking about. -angel
RE: atomicness and \n
On 4 Sep 2002 at 0:22, Aaron Sherman wrote: > On Wed, 2002-09-04 at 00:01, Sean O'Rourke wrote: > > > None, I think. Of course, if we ignore internals, there's no > > difference bewteen that and "rx / | 1 | 7/". > > Then, why is there a C<+>? Why not make it C<|>? > > $foo = rx/ <||[cde]>|f / Because it's good to have MTOWTDI. (= More than one way to do it) -- Markus Laire 'malaire' <[EMAIL PROTECTED]>
RE: Argument aliasing for subs
From: Peter Behroozi [EMAIL PROTECTED]
> Has anyone considered a syntax for allowing
> subroutines to have many different names for
> the same argument? For example, in CGI.pm, many
> methods support the "-override" parameter but
> can also accept the alias of "-force":
Yes. See the thread starting at
http:[EMAIL PROTECTED]/msg09551.html . The
end result was that Damian liked the idea and leans towards a syntax like
this:
sub load_data (
$filename_tainted is named('filename'),
$version_input is named('version','ver') //= 1)
{...}
-Miko
mail2web - Check your email from the web at
http://mail2web.com/ .
Re: Multimethod Dispatch
At 9:10 AM -0400 9/4/02, [EMAIL PROTECTED] wrote: > >From: Ken Fox [EMAIL PROTECTED] >> Over loading is what C++ has. It is not the same as >> multi-dispatch. The trouble with over loading is that the >> compiler uses static (compile-time) type information to >> select the over loaded method. This can create subtle >> bugs when people try to re-use code by sub-classing. > >So, just to clarify, does that mean that multi-dispatch is (by definition) >a run-time thing, and overloading is (by def) a compile time thing? No. They can be both compile time things or runtime things, depending on the characteristics of the language. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Multimethod Dispatch
On Wednesday, September 4, 2002, at 06:58 AM, Dan Sugalski wrote: > No. They can be both compile time things or runtime things, depending > on the characteristics of the language. So if it's compile-time for a given language, how is it different from the Java concept of overloading? And will Perl 6 do it at compile-time or at run-time? Thanks, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Perl 6 parser, built in rules, etc.
It seems to me that what I mostly do is wave my arms about my head with a concern and then stay silent whenever praise is required. Everyone - consider yourselves praised :-) On to the concern (which I am fairly confident someone will obviate). I've never touched the Perl internals (and P5P should be thankful of that) so I'm not sure how much the parser changes. I worry that, since the rules that the Perl 6 grammer uses to parse the language are exposed to the users, that we could be forced to have an ever growing Perl 6 grammer to keep bakcwards compatability. If a reorganization of the parser ever occured, the language level rules would need to be maintained so that a) lexically scoped grammer changes do not break and b) those rules which are useful to all different kinds of parsing tasks (such as parsing quoted constructs) are still there for those programs which will inevitably use them. How are we planning on dealing with this, or do the implementers consider it a non issue? It seems to me that we are forced to do it (meaning the parser) right and cleanly the first time, which is a reasonable but heavy burden. -Erik Is your boss reading your email? Probably Keep your messages private by using Lycos Mail. Sign up today at http://mail.lycos.com
Re: Multimethod Dispatch
At 7:31 AM -0700 9/4/02, David Wheeler wrote: >On Wednesday, September 4, 2002, at 06:58 AM, Dan Sugalski wrote: > >>No. They can be both compile time things or runtime things, >>depending on the characteristics of the language. > >So if it's compile-time for a given language, how is it different >from the Java concept of overloading? It probably isn't, though I'm unfamiliar enough with Java to say for sure. >And will Perl 6 do it at compile-time or at run-time? Runtime. There's no way we could do it at compile-time--too much uncertainty. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl 6 parser, built in rules, etc.
On Wed, 4 Sep 2002, Erik Steven Harrison wrote: > How are we planning on dealing with this, or do the > implementers consider it a non issue? Well, to me this is a non-Yet issue, but a very real issue. I'm hoping that when Perl 6 goes 1.0, the grammar will have seen a lot of testing, and will be in some sort of final form. To me a language's grammar, once defined, shouldn't do a lot of changing, internally or otherwise. When was the last time C's grammar changed? Or even gcc's implementation of it? Of course, before 1.0 the grammar will likely undergo some major tweaking, fixing, and refactoring. It seems reasonable to expect people who do grammar mods before then to keep up with changes. /s
Re: Perl 6 parser, built in rules, etc.
-- On Wed, 4 Sep 2002 07:45:37 Sean O'Rourke obviated: To me a language's grammar, once >defined, shouldn't do a lot of changing, internally or otherwise. When >was the last time C's grammar changed? Or even gcc's implementation of >it? Granted . . .mostly. Were talking about Perl, the language designed to evolve. How much did the Perl grammer (even if there was no definitive one in the Perl 6 lex-on-the-fly sense) change between Perl 1 and Perl 5? Perl 5 and Perl 5.8? I think the answer to the first question (which I suspect is "a lot") point to perhaps a different issue - how much do we expect Perl to change after this rewrite, and how are we accomodating Perl's inevitable evolution? The answer to the second question (which I think is probably "a little, but some") is more to the point here. Parsing small or experimental features (vstrings and subroutine attricute come to mind) will probably cause changes to the parser. I'd like to keep the potential to introduce such features without breaking existing code. All that said, perhaps there is a solution. I'm not much of a Python programmer, but as I understand it Python offers an internal module called 'future' which holds features planned for inclusion in the next stable release. The idea here is that old code gets a chance to refactor in anticipation of language changes while still bringing new features into the language. Code which uses those features simply imports from the future modules. Hugo is working on the perl6ish pragma which already brings the concept to Perl. Perhaps a Perl 6 pragma can control these feature inclusions to help protect code which accesses the parser? -Erik Is your boss reading your email? Probably Keep your messages private by using Lycos Mail. Sign up today at http://mail.lycos.com
User-defined character classes and repeat counts
On Wed, 2002-09-04 at 00:22, Aaron Sherman wrote:
> Then, why is there a C<+>? Why not make it C<|>?
>
> $foo = rx/ <||[cde]>|f /
This brings to mind a few big things that have been batting around in my
head about user-defined rules for a while now These things fall out
nicely from A5, I think, but correct me if there's some reason I'm wrong
on that.
It would be nice to be able to flag a rule as being either a pure
character class or a generic rule. At the very least this lets the
compiler issue clearer errors, perhaps earlier. Something like:
rule abc :cc { <[abc]> }
Perhaps the engine could even try to coerce non-character classes so
that this would work (not that this simple example would happen, but if
you're working with a rule-chain it might be useful):
rule abc :cc { a | b | c }
Along that line, inline closures can do quite a bit, but it would be
nice if they could be used as counts (instead of the more painful
process of controlling backtracking via commit. Let's assume that C<<
<={...}> >> is used this way. Here's an example of its use:
/<[\x0d\x0a]><={ .count == 1 || (.count == 2 && .atom eq "\x0d\x0a") }>/
Now that's a very expensive way to say C, but a
much more complicated count might make it worth-while. I'm assuming the
following things:
C<.count> is method on the state object that would return the number of
repetitions of the preceding atom have been tried
C<.atom> is the preceding atom as it would appear if backtracking
stopped now.
The return value of a count closure is boolean.
So, for example here are some translations of existing operators:
+ <={.count > 0}>
* <={1}>
*? <={1}>?
<8> <={.count == 8}># No optimization possible!
? <={.count < 2}>
Again, it would be nice to be able to flag these to the compiler in a
rule:
rule thrice :count { <={.count < 4}> }
/ a? /
Note that the C would cause the thrice count-rule to be matched
non-greedily because the regex parser knows that it's a count, not a
generic rule.
Re: Multimethod Dispatch
Just some thoughts (and an idea):
I have found the whole context thing in Perl5 easier to understand when I regard it as
overloading based on the return type. We all know that languages like C, C++ and Java
throw a compile-time error if two function
definitions differ in their return type only. Perl does something close to return type
overloading with many of its builtin functions. At least, that's the impression you
get from the outside (and I have never looked inside, so
excuse my lack of knowledge about the Perl5 internals ;-) )
Now my suggestion: Couldn't context sensivity in Perl6 be implemented by extending
multi-method dispatch to include return types? That could be generalized and would
allow things like:
my PNG $png = PNG.new("images/img0001.png");
my JPEG $jpeg = $png.convert();
my GIF $gif = $png.convert();
Of course you could have convertToJPEG() and convertToPNG(), but that's the whole
point of overloading and multimethod dispatch, isn't it?
The usual list context / scalar context distinction would of course still be possible.
It's just about _extending_ context sensivity.
[Comments | Suggestions | Criticism] welcome.
Re: Perl 6 parser, built in rules, etc.
At 8:03 AM -0700 9/4/02, Erik Steven Harrison wrote: > >-- > >On Wed, 4 Sep 2002 07:45:37 > Sean O'Rourke obviated: >To me a language's grammar, once >>defined, shouldn't do a lot of changing, internally or otherwise. When >>was the last time C's grammar changed? Or even gcc's implementation of >>it? > >Granted . . .mostly. Were talking about Perl, the >language designed to evolve. How much did the Perl >grammer (even if there was no definitive one in the >Perl 6 lex-on-the-fly sense) change between Perl 1 and >Perl 5? Perl 5 and Perl 5.8? Perl's grammar didn't change much between 5.00 and 5.8. Once we ship the final grammar, we'll maintain it in a backward-compatible way, and document the places you can count on it to wedge in changes. Then we maintain it as long as Larry says so. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Multimethod Dispatch
The specific definitions of these terms vary from language to language. In Java, for instance, a method is said to be "overloaded" and/or "overridden". An "overloaded" method is actually two or more methods with the same name but differing numbers/types of parameters (which Java calls the "signature" of the method). I believe this is what has been referred to as "multimethod dispatch" on this thread. An "overridden" method is two methods with the same name AND type signature in two different classes, where one class is a subclass of the other. The child class's method is said to "override" the parent class's implementation. The similarity of names is a little confusing, but the distinction between the two mechanisms is important. When an overridden method is called, the actual implementation that gets executed depends on the RUNTIME type of the INVOCANT. When an overloaded method is called, the implementation that is executed depends on the COMPILE-TIME type of the PARAMETERS. Many folks get bitten trying to use overloaded methods as if the implementation were chosen based on on run-time type information. But that's all off-topic. Back to Perl6, although it seems that we won't find out the details of Perl6 O-O until Apoc 12 comes out. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754 -- grasshopotomaus: A creature that can leap to tremendous heights . . . once.
RE: atomicness and \n
On Wed, 2002-09-04 at 09:55, Markus Laire wrote: > On 4 Sep 2002 at 0:22, Aaron Sherman wrote: > > > On Wed, 2002-09-04 at 00:01, Sean O'Rourke wrote: > > > > > None, I think. Of course, if we ignore internals, there's no > > > difference bewteen that and "rx / | 1 | 7/". > > > > Then, why is there a C<+>? Why not make it C<|>? > > > > $foo = rx/ <||[cde]>|f / > > Because it's good to have MTOWTDI. (= More than one way to do it) But, there isn't. There's only one way to indicate character-class unions, and that's C<+>. If we had C<+> and C<|> as synonyms, I'd be ok with that, though I'd only tell people about C<|> to avoid the confusion (mind if we call you Bruce?)
RE: Parrot: maximizing the audience
From: Dan Sugalski > > At the moment, how many people outside the tight little club > actually care about the name of the mailing list? And how > many more would really care if we changed the name? Answer: You can hardly require a realistic answer to that question because you won't know until you do. Jeez, you'd think this was a contentious issue ;) Who cares? Why not add a [EMAIL PROTECTED] alias instead of taking perl6-internals away? What is lost with an alias gained? A rose by any other name is still a rose. If Ask is willing, why not have him put it on the TODO list? Reducing the number of times people are forced to see the word "Parrot" tied together with "Perl" would be conducive to weakening that "tight little club" mentality. Anyone disagree with that? It seems like a no brainer. Even if it is just a language neutral symbol. Hell, if you really want parrot to be dynamic language neutral, then Dan and Jeff ought to be wooing Python and Ruby internals gurus for the job of Parrot heir apparent. Anything less than that is empty words and promises. It is pretty evident that in the current state of affairs all other languages are second class citizens. But it would be nice to see the door to the club house opened a little wider. -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
Re: A show of hands of the non-perl people?
On Wed, 2002-09-04 at 04:31, Dan Sugalski wrote: > Can I get a quick show of hands for the folks working on Parrot, even > peripherally, who *aren't* perl folks? I am not a perl person. I haven't done much work on parrot, and it seems that most of what I have done is on hold or up in the air still (my patch in [perl #16797] for example). But I am hoping to somehow get more involved. Also, for what it is worth, I personally don't much care what the email list is called. -- Jonathan Sillito
Re: [netlabs #801] [PATCH] PerlArray in scalar context
[OSCON has left me way behind in reading my mail, so apologies for the late reply] On Wed, 14 Aug 2002 16:45:09 -0500 (CDT), David M. Lloyd wrote: > Here's how I'd expect these expressions to be executed internally, in > gross pseudocode, ignoring for the moment the multimethod vaporware: > > $r = $a + $b; # $a->add($a, $b, $r) > $r = @a + $b; # $t = @a->get_pmc(@a); $t->add($t, $b, $r) > $r = $a + @b; # $t = @b->get_pmc(@b); $t->add($a, $t, $r) > $r = @a + @b; # $t = @a->get_pmc(@a); $u = @b->get_pmc(@b); > # $t->add($t, $u, $r); get_pmc() seems a bit vague to me. Shouldn't it be get_scalar(), or even get_number()? I've reordered the next bit to make my point more obvious. > @r = @a ^+ @b;# @a->add(@a, @b, @r), easy As Sean says in his reply, making the array vtable perform hyper operations probably means having some code duplication. However, you can get around this by using a helper function which will do the hyper bits, iterating through a pair of array PMCs, applying a supplied function (with a supplied default for the case where one array is exhausted). This means that array vtable functions would mostly just consist of calls to the helper function. However, see below. > @r = @a ^+ $b;# Does this distribute? If so, > # @a->add(@a, $b, @r) else see above It does distribute. However, you can't do the detection of this case entirely in the vtable, because then C< @a ^+ $b > and C< @a ^+ @$b > would end up being indistinguishable (though you probably wouldn't do the first very often with an arrayref). Having the iteration done in the bytecode could make this simpler, although at the expense of needing more bytecode. You can probably have bytecode ops specifically for hyping operators though, so it might not be too bad. Also, it means we can use the same mechanism for hyping non-vtable methods. > @r = $a ^+ @b;# See above Yes, but I'm not convinced that scalar-type PMCs should be responsible for detecting array-type PMCs passed as the second operand. Having the bytecode do the iteration in this case means that the appropriate vtables get used, and the scalar-type vtable routines don't get complicated with hyperoperator decisions, which will probably be a minority of cases for the first operand being a scalar. > @r = $a ^+ $b;# Something that makes one-elment arrays and > # uses add method on array object? Or perhaps > # error Bytecode iteration means that this just ends up calling the normal scalar op, and stuffing the result into an array. Looks like I'm in favour of bytecode iteration for hyperoperators after all. -- Peter Haworth [EMAIL PROTECTED] I is for indent, which rarely amuses, and J is for join, which nobody uses. K is for kill, which makes you the boss, while L is for lex, which is missing from DOS. -- The ABC's of Unix
Re: User-defined character classes and repeat counts
Aaron Sherman wrote:
> So, for example here are some translations of existing operators:
>
> + <={.count > 0}>
> * <={1}>
> *?<={1}>?
> <8> <={.count == 8}># No optimization possible!
Could it be done this way?:
@c:=(.)* <( @c == 8 )>
Surely inefficient, but it works right (I think). Would there be a more
efficient way to do it within the existing system?
It's easy to do non-greedy, too. Just slap a question mark on the end of
that star.
Luke
Re: Hypothetical variables and scope
Ken Fox wrote:
>> / $x := (gr\w+) /vs/ (gr\w+) { let $x = $1 } /
>>
>>Shouldn't they both use C< := > ?
They should. The second version is a typo. It should be:
/ (gr\w+) { let $x := $1 } /
> Depends on what you want. The "$x :=" in the rule binds the
> first match to $x -- it does not copy the value. The "$x ="
> in the code block copies the value of the first match. You
> can use either binding or assignment in the code block.
But not with the C keyword. That requires binding.
> Both of them will be "undone" during backtracking. It's more
> efficient to bind, but the copy guarantees changes to $x and $1
> are independent.
This is not what Larry has said previously. He said that only
binding can be used with C variables and that only C
variable assignments are undone on backtracking.
Damian
Re: Hypothetical variables and scope
Aaron Sherman wrote:
> Hmm... I had not thought of the copy aspect. Certainly, the code version
> is more flexible. You could define C<$x> above as anything. For example:
>
> / (gr\w+) {let $x = Gr_Thing.new($1)} /
>
> The binding version is just a simple, fast version of one special case,
> no?
No. It's the *only* way to set hypotheticals. Of course, you *can* always
do:
/ (gr\w+) { $x = Gr_Thing.new($1)} /
without the C, but that won't be undone on backtracking.
Damian
Re: atomicness and \n
Jonathan Scott Duff wrote: > How can you be sure that is > implemented as a character class instead of being some other arbitrary > rule? An answer is that perl should know how these things are > implemented and if you try arithmetic on something that's not a > character class, it should carp appropriately. Another answer might be > that <+[17]> is actually syntactically illegal and you MUST > perform character class arithmetic as <[abc]+[def]>. > > Somehow I prefer the former to the latter. It will definitely be the former, since we have to support named character classes like , , , etc. Damian
Re: Argument aliasing for subs
Peter Behroozi wrote:
> Has anyone considered a syntax for allowing subroutines to have many
> different names for the same argument?
If it were allowed, it would probably be done via properties instead:
sub hidden (str $name, int $force, int $override is aka($force)) { ... }
Damian
Re: Argument aliasing for subs
From: Damian Conway [EMAIL PROTECTED]
> If it were allowed, it would probably be done
> via properties instead:
>
> sub hidden (str $name, int $force, int $override is aka($force))
>{ ... }
Would the following be simpler...?
sub hidden (str $name, int $force is aka($override))
{ ... }
Damian's statement says to me that there is an argument named $force, and
another argument named $override which is also known as $force... that
sounds conflicting. The revised statement simply says that there's an
argument named $force and it is also known as $override.
BTW, the aka thing is cool. It could be complementary to "is named":
# can't use force_tainted as argument:
sub hidden (int $force_tainted is named($force))
# can use force_tainted as argument:
sub hidden (int $force_tainted is aka($force))
mail2web - Check your email from the web at
http://mail2web.com/ .
Re: Argument aliasing for subs
From: Damian Conway [EMAIL PROTECTED]
> If it were allowed, it would probably be done
> via properties instead:
>
> sub hidden (str $name, int $force, int $override is aka($force))
>{ ... }
How does this method affect the non-parameter-based calling scheme? It
looks like it is possible to use three arguments in the call to
hidden(). While this doesn't matter for this case, it might if another
named argument was tacked on to the end, like this:
sub hidden (str $name, int $force, int $override is aka($force),
int $pretty_print);
print hidden('name',1,1); #<-- What does this do?
I think that the slight modification of Damian's original solution is
the best:
sub hidden (str $name, int $force is aka('override')) { ... }
Then there is no question that "override" is Just Another Name for
"force" (eliminating weird things like "$force is aka(@override)"), the
problem of argument order in normal sub calls goes away, and there is a
happy minimum of extra syntax.
By the way, thanks for pointing out the original discussion; I haven't
been on the list long enough to have known that it existed.
Peter Behroozi
Re: Parrot: maximizing the audience
[Please CC: me on any responses.]
I follow the perl6-internals list through checking the archive, and
noticed Jerome's posting. I wrote the parrot-gen.py script that he
pointed to. Here are my comments on this issue.
(Note that I do not speak for the python-dev gang as a whole, but
AFAIK I'm the only current or former python-dev'er who's looked at
Parrot in any detail.)
First, the mailing list name is a complete non-issue; I don't care.
Having it be @perl.org doesn't matter, either.
First reason I don't work on it very much:
1. Frankly, it's not much fun. I can spend my free time writing
Python code, an environment I like, or I can work in the unfamiliar
and uncomfortable Parrot build environment and source code, grepping
through it looking for examples to help me figure out what's going on.
Guess which option wins most often?
I initially wrote parrot-gen.py because I wanted to play a bit with
Parrot and see what it took to generate Parrot bytecode from Python.
Parsing Python code is trivial with the Compiler/ package in 2.2, so
it was just a matter of code generation. Every so often, I'll update
my copy of the Parrot CVS tree and try to update the script to match
it. I also have incomplete PythonString.pmc and PythonFloat.pmc files
lying around someplace, and got halfway through updating the code to
use imcc instead of assemble.pl, but the task isn't enough fun to make
me bother finishing those off.
Some larger reasons:
2. No clear benefit to using Parrot.
What new possibilities does Parrot provide for Python? Stacklessness?
Better GC? A new I/O layer? Language interop? None of these is more
than mildly interesting to me, and none is a killer application.
Personally, I'm skeptical of the claims of cross-language interop
because I don't think a library written in Perl will provide an Python
interface that looks at all idiomatic, and vice versa. You could
write a Python wrapper to make a Perl library look more natural, but
now 1) we're all writing wrapper code that will introduce more bugs,
2) as a user chasing a problem, I now have to debug the interface
between the library and the wrapper code, 3) as a user, now I'll have
to read Perl/Ruby/Scheme/whatever code in the underlying library. The
way things are now, at least I only need to know 2 languages, Python
and C.
A big benefit for Python might be if someone writes a Parrot to
{machine code,.NET} compiler, but there are existing alternatives such
as Pyrex and no one has written such a Parrot compiler yet, so that's
not too convincing.
If every other language was using Parrot, there would be some pressure
to join them, but given the lukewarm response by other language
communities, that's not a factor at the moment.
3. Lack of any real languages on Parrot
I'm slightly worried that Parrot is already succumbing to the lure of
premature optimization -- counting the number of opcodes executed per
second, trying to save a C pointer dereference here or there -- before
the Parrot VM has been shown to be useful as a language target. No
one is running real programs in Perl or Python or Scheme or anything
on the VM (right?), so any optimizations at this point are just
guesses, and may not actually be relevant to real programs. This
makes me wonder if the Parrot implementation will just retrace the
same path as the Perl5 implementation.
I'd rather see a full implementation of a single real language that
people actually use (Scheme, Python, whatever) on top of an
unoptimized Parrot VM, instead of the existing situation of a bunch of
half-implemented or toy languages on top of an optimized VM. That
would be a more convincing proof that Parrot can actually handle a
real language, and gives other languages something to test
interoperability with.
--amk (www.amk.ca)
Then the shadows began to gather; first little furtive ones under the table,
and then bolder ones in the dark panelled corners.
-- H.P. Lovecraft, "The Strange High House in the Mist"
[perl #17000] [PATCH] Re: IRIX64 alignment problem
# New Ticket Created by Andy Dougherty # Please include the string: [perl #17000] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=17000 > On Sat, 31 Aug 2002, Steven W McDougall wrote: > parrot t/pmc/perlhash_1.pbc > > produced a bus error. > > I chased the error down to parrot/hash.c: new_bucket(), > bucket->value = *value; BUS ERROR HERE [long interesting discussion about how bucket->value got to be 4-byte aligned, but gcc needs 8-byte alignment for floats.] Superp detective work! > The align_1 parameter to mem_allocate() does not--as you might > think--control the alignment of the allocated block. Rather, it > controls the *size* of the allocated block, rounding it up to the next > multiple of the power of 2 indicated by align_1. This means that the > alignment of a block returned by mem_allocate() is dependent on the > *previous* calls to mem_allocate(). In retrospect, that's an, err, odd design. > I don't know how this thing is supposed to work, so I don't know how > to fix it. Logically, there are a few possibilities. > > 1. Fix gcc on IRIX64 to permit assignment of unions with arbitrary >alignment. I suspect that's unlikely to happen soon. This is a long-standing problem. Also, it affects SPARC as well as IRIX64. > 2. Add a parameter to mem_alloc() (or use align_1) to control the >alignment of the allocated block. Yes, this sounds very sensible to me. (Specifically, using align_1.) > 3. Require all callers of mem_alloc() to pass an align_1 parameter >big enough to meet the alignment requirements of the platform. >(Seems like the Wrong Thing.) Agreed, but it would work in the short term. The following patch effectively implmements #3. I think it's a temporary hack, and mem_allocate() ought to implement #2 above instead, but that will take more thought and time than I have today. (Such checks should be made conditional on various Configure-determined cpp #defines so that that checks would be performed only on platform configurations where they were required. It should also be possible to make Configure-time space/speed tradeoffs (e.g. always requiring 8-byte alignment at the cost of some wasted space)). This patch should help IRIX64. It also fixes gcc/SPARC, which currently crashes in the same way as detailed above. It may also help Tru64, which is plagued by unaligned access errors. Or it may not. I don't think it will hurt :-). diff -r -u parrot-orig/include/parrot/headers.h parrot-andy/include/parrot/headers.h --- parrot-orig/include/parrot/headers.hFri Aug 23 03:55:22 2002 +++ parrot-andy/include/parrot/headers.hWed Sep 4 12:20:10 2002 @@ -17,7 +17,8 @@ #include "parrot/parrot.h" #define BUFFER_ALIGNMENT 16 -#define STRING_ALIGNMENT 4 +/* XXX Temporary alignment hack. See mem_allocate in resources.c */ +#define STRING_ALIGNMENT 16 /* was 4 */ static void * diff -r -u parrot-orig/resources.c parrot-andy/resources.c --- parrot-orig/resources.c Sat Aug 24 01:31:20 2002 +++ parrot-andy/resources.c Wed Sep 4 12:26:08 2002 @@ -69,6 +69,15 @@ return new_block; } +/* Alignment problems: align_1 sets the size, but not the alignment +of the memory block we are about to allocate. The alignment of *this* +block is currently determined by the align_1 sent in by the +*previous* allocation. See +http://archive.develooper.com/perl6-internals%40perl.org/msg12310.html +for details. +Currently, we work around it by forcing all the *ALIGNMENT +#defines in include/parrot/*.h to be the same :-). +*/ /* Allocates memory for headers */ static void * mem_allocate(struct Parrot_Interp *interpreter, size_t *req_size, -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
[perl #17002] [PATCH] Configure deleting config/gen/platform/generic.?
# New Ticket Created by Andy Dougherty # Please include the string: [perl #17002] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=17002 > Configure.pl's 'copy_if_diff()' function was actually calling rename() and moving the file. The net result was that if you tried to re-run Configure.pl, it failed at the MANIFEST check point because the config/gen/platform/generic.? files had been moved. This patches replaces the rename() call by File::Copy::copy (which is available at least as far back as 5.005_03). diff -r -u parrot-orig/lib/Parrot/Configure/Step.pm parrot-andy/lib/Parrot/Configure/Step.pm --- parrot-orig/lib/Parrot/Configure/Step.pmTue Sep 3 10:28:29 2002 +++ parrot-andy/lib/Parrot/Configure/Step.pmWed Sep 4 13:52:10 2002 @@ -2,6 +2,7 @@ use strict; use Exporter; +use File::Copy (); use vars qw(@ISA @EXPORT @EXPORT_OK %EXPORT_TAGS); @ISA=qw(Exporter); @@ -68,7 +69,7 @@ return if $from_sum == $to_sum; } -rename($from, $to); +File::Copy::copy($from, $to); # Make sure the timestamp is updated my $now=time; -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
[Info] African Grey update
For anybody who may be interested, the latest news from the pirate cave follows. Recent changes: * New aligned memory page allocator * Above allocator used for PMC/buffer header arenas and memory pool pages; this has allowed removal of the pointer from buffer headers to their pool header * Calculation of reclaimable space in memory pools removed, as it is currently unreliable (COW and early-exit from compact_pool) * string_compare uses memcmp for compatible strings * new string vtable function for extracting substrings (only implemented for singlebyte in current patch) Latest results of life.pasm: African Grey 5000 generations in 59.180210 seconds. 84.487703 generations/sec A total of 131072 bytes were allocated A total of 61024 DOD runs were made A total of 1105 collection runs were made Copying a total of 614136 bytes There are 71 active Buffer structs There are 914 total Buffer structs Parrot 5000 generations in 121.385124 seconds. 41.191209 generations/sec A total of 774724 bytes were allocated A total of 43105 DOD runs were made A total of 45 collection runs were made Copying a total of 728860 bytes There are 24 active Buffer structs There are 1024 total Buffer structs The 'total bytes allocated' for grey refers to the aligned page allocator, and therefore now includes headers. 72k patch not attached. -- Peter Gibbs EmKel Systems
Re: [perl #17002] [PATCH] Configure deleting config/gen/platform/generic.?
On Wed, Sep 04, 2002 at 06:00:17PM +, Andy Dougherty wrote: > > Configure.pl's 'copy_if_diff()' function was actually calling rename() > and moving the file. The net result was that if you tried to re-run > Configure.pl, it failed at the MANIFEST check point because > the config/gen/platform/generic.? files had been moved. > > This patches replaces the rename() call by File::Copy::copy > (which is available at least as far back as 5.005_03). What idiot wrote a function that *renamed* a file and then called it copy_if_diff()?! Oh, wait... Thanks, applied.
Re: User-defined character classes and repeat counts
On Wed, 2002-09-04 at 12:41, Luke Palmer wrote:
> Aaron Sherman wrote:
> > So, for example here are some translations of existing operators:
> >
> > + <={.count > 0}>
> > * <={1}>
> > *? <={1}>?
> > <8> <={.count == 8}># No optimization possible!
>
> Could it be done this way?:
>
> @c:=(.)* <( @c == 8 )>
>
> Surely inefficient, but it works right (I think). Would there be a more
> efficient way to do it within the existing system?
>
> It's easy to do non-greedy, too. Just slap a question mark on the end of
> that star.
What you suggest is just a special-case of what I'm suggesting, so I
agree :)
Adding the syntax of C<< <={...}> >> just gives you the ability to do
this for arbitrary expressions without saving the results (unless you
want to).
Re: Hypothetical variables and scope
On Wed, Sep 04, 2002 at 11:27:46AM +, Damian Conway wrote:
> This is not what Larry has said previously. He said that only
> binding can be used with C variables and that only C
> variable assignments are undone on backtracking.
It seems odd to require two syntactic elements to achieve one semantic.
And actually, after looking at A5, that's not what Larry wrote:
my $x;
/ (\S*) { let $x = .pos } \s* foo /
After this pattern, $x will be set to the ending position of
$1--but only if the pattern succeeds. If it fails, $x is
restored to undef when the closure is backtracked
I don't see any binding there, just letting.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
regex args and interpolation
In Perl5, I might write:
sub set_date {
my ($self, $date) = @_;
$date =~ /(\d{4})-(\d{2})-(\d{2})/ or croak "bad date format";
@$self{qw/year month day/} = ($1,$2,$3);
}
I could then call:
$foo->set_date('2002-09-04')
In Perl6 I can write:
sub set_date ( $date is rx// )
{
($.year, $.month, $.day) = $date{qw/year month day/}
}
(aside: is this the correct syntax for a Perl6 hashref slice? Could I use
%date instead of $date as my match object?)
Anyway, ignoring the syntax errors, I think I have some valid Perl6 here. I
could now write:
$foo.set_date 2002-09-04;
But can I use a non-constant date?
Perl5: $day = "04"; $foo->set_date("2002-09-$day");
Perl6: $day = "04"; $foo.set_date 2002-09-$day; # ERROR -- doesn't match
regex
Perl6: $day = "04"; eval "\$foo.set_date 2002-09-$day"; # clunky
Obviously we could put the onus on the module writer to write super-flexible
rules/grammars. But will there be an easy way to force interpolative context
onto this type of regex-valued subroutine arg?
Eagerly awaiting A6,
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.
Re: Hypothetical variables and scope
On Wed, 2002-09-04 at 14:38, Jonathan Scott Duff wrote:
> my $x;
> / (\S*) { let $x = .pos } \s* foo /
>
> After this pattern, $x will be set to the ending position of
> $1--but only if the pattern succeeds. If it fails, $x is
> restored to undef when the closure is backtracked
>
> I don't see any binding there, just letting.
I think the confusion here is that "let" is creating a binding, but the
binding is between the named variable (e.g. C<$x>) and the storage in
the result object (e.g. C<$0.{x}>). What C<$0.{x}> is is kind of beside
the point. It may be a binding as in:
... {let $x := $1} ...
or a stand-alone value as in:
... {let $x = $1 + 100} ...
Does this make sense? As I understand it, the let statement is
translated to something like this:
... { $self.{x} = sub {$1 + 100}; $x := $self.{x} } ...
Which will then be evaluated and the result substituted:
$0.{x} = $0.{x}.();
once backtracking is complete to avoid evaluating C<$1 + 100> before a
final understanding of what C<$1> contains is reached.
Is that roughly correct?
Defaulting params (reprise)
It was settled a while ago that sub arguments would be defaulted like this:
sub load_data ($version / /=1) {...}
(The space between / and / is on purpose, my emailer has problems if they
are together) I and a few others had issues with the slash-slash-equals
thing, but were unable to persuade Damian, Larry, et al to change. I'd
like to make one more proposal for defaulting. Damian seems to like
properties for arguments, how 'bout this construct:
sub load_data ( $version is default(1) ) {...}
It's clean, fits the existing syntax, and immediately understandable.
Thoughts?
-Miko
--
"If you reprise the songs, we'll reprise the jokes." - George S. Kaufman
mail2web - Check your email from the web at
http://mail2web.com/ .
Re: [netlabs #801] [PATCH] PerlArray in scalar context
On Wed, 4 Sep 2002, Peter Haworth wrote:
> Having the iteration done in the bytecode could make this simpler,
> although at the expense of needing more bytecode.
And fewer temporaries, by translating this:
@a = @b ^+ @c ^+ @d;
into this:
for @a; @b; @c ; @d -> $a, $b, $c, $d is rw {
$d = $a + $b + $c;
}
/s
Re: [netlabs #801] [PATCH] PerlArray in scalar context
On Wed 04 Sep 2002 20:31, "Sean O'Rourke" <[EMAIL PROTECTED]> wrote:
> On Wed, 4 Sep 2002, Peter Haworth wrote:
> > Having the iteration done in the bytecode could make this simpler,
> > although at the expense of needing more bytecode.
>
> And fewer temporaries, by translating this:
>
> @a = @b ^+ @c ^+ @d;
>
> into this:
>
> for @a; @b; @c ; @d -> $a, $b, $c, $d is rw {
> $d = $a + $b + $c;
$a = $b + $c + $d;
I might hope
> }
>
> /s
--
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: [EMAIL PROTECTED]
http:[EMAIL PROTECTED]/ [EMAIL PROTECTED]
send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
Re: Parrot: maximizing the audience
I'm actually somewhat surprised at how little Parrot is tied to Perl. Most of the active developers seem to be working on parrot for its merits as a VM. Perl6, for me at least, mostly provides evidence that this isn't just an exercise in intellectual masturbation, as Simon would say -- there will be at least one real language that targets it. But even if it's tied to Perl less than one might expect, I don't disagree that it still smells strongly of Perl. Which isn't surprising, given its origins. The reason why it came into existence was Perl6; the early developers thus came from the Perl community, or at least the Perl-using community, and so implemented the supporting build system etc. with Perl; and the design of many things, particularly the more incidental things such as specific PMCs, was done from a Perl-centric perspective. Dan's designs tend to be more language-independent than others', probably because he has language independence as a stated goal while the rest of us rabble tend to only worry about getting specific concrete examples to work, and those examples are most often based on Perl. But let's remember again what the point of Parrot is, other than providing a way of running Perl6 code. To me, it all comes back to decoupling a VM from a language's compiler, which provides the following benefits: - The two to be worked on independently, allowing more freedom to improve each without worrying about backwards-compatibility or incompatible development philosophies. - It's easier to find experts in just one of the two components, rather than requiring an expert in both VMs and the target language. - Optimization is easier, since performance problems can be easily isolated in either the VM or the compiler. - Multiple languages can target the same VM, so more people are motivated to improve the VM (and thus hopefully improving all languages). But that's what we're talking about. These advantages exist equally for languages other than Perl, but all languages but Perl6 have one thing in common: they already have a perfectly functional runtime execution engine of some sort. Not only that, but they have an established group of experts for that runtime engine. And those are very good reasons not to switch. That means that Parrot has to offer some pretty convincing practical benefits, not just theoretical ones. And any perceived obstructions, real or otherwise, are going to make switching much less likely. If I imagine that I am a Python developer digging into Parrot for the first time, this is what I'd see: first, development is done on a list named perl6-internals. Hmm... I wonder how Perl-centric it is? That address is going to make it a lot harder to convince myself that Parrot isn't fundamentally bound to Perl. (The @perl.org doesn't bother me; if I have that much of a kneejerk reaction to the word Perl, I'm not going to touch Parrot until you drag me to it, kicking and screaming.) Second, the build system is written in Perl. Okay, that will be a nuisance, but I don't expect to work on that anyway. As long as it does its job, I'm happy, and if it doesn't then I'm not going to waste any time trying to fix it -- my time is better spent elsewhere, far away from Parrot. Third, the whole thing just seems too immature to be a realistic target yet. These PMC things sound fine, but my language requires a somewhat different set of operations and I can't find any working examples of arbitrary method invocation. It runs a tinderbox, but some machines have still been failing for a long time. The currently existing PMCs have strange gaps and tangles where a low-level one calls a higher-level one (and that higher-level one often has Perl in its name!). The documentation seems to be written for someone else who already understands more of Parrot than I do. Et cetera. In summary, I think we should try to remove the obstructions, partly because it's the right thing to do and partly in hopes that we'll be able to get more eyes and hands working on Parrot. But the main focus should be continue to make Parrot as robust, fast, and flexible a target as possible, because in the end that's the only thing that will persuade people to switch. And I'm guessing that the best way to that goal is to use Perl6 as the driver, at least until something else shows up, because that's the only way to derive realistic requirements for what needs to be accomplished.
Python::Bytecode seems not functional
Or at least I can't get it going. Fixing it's a project for the interested. (I'd ask Simon but, well, he doesn't do that stuff any more) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Hypothetical variables and scope
On Wed, 2002-09-04 at 07:28, Damian Conway wrote:
> Aaron Sherman wrote:
>
> > Hmm... I had not thought of the copy aspect. Certainly, the code version
> > is more flexible. You could define C<$x> above as anything. For example:
> >
> > / (gr\w+) {let $x = Gr_Thing.new($1)} /
> >
> > The binding version is just a simple, fast version of one special case,
> > no?
>
> No. It's the *only* way to set hypotheticals. Of course, you *can* always
> do:
>
> / (gr\w+) { $x = Gr_Thing.new($1)} /
You chopped off some context. The discussion was about
/ $x := (gr\w+) /vs/ (gr\w+) { let $x := $1 } /
Not hypotheticals in particular. So, the question was is binding C<$x>
to C<$1> via the former statement the same as binding C<$x> to C<$1> via
the latter. I the replied that the former was in fact doable using the
latter syntax, but was more efficient (no closure to execute) while not
offering the flexibility of something like:
/ (gr\w+) {let $x = Gr_Thing.new($1)} /
I think you were saying the same thing as I was (e.g. that you could
only assign a hypothetical to a complex value this way).
Re: Defaulting params (reprise)
On Wed, Sep 04, 2002 at 04:01:50PM -0400, [EMAIL PROTECTED] wrote:
> It was settled a while ago that sub arguments would be defaulted like this:
>
> sub load_data ($version / /=1) {...}
>
> (The space between / and / is on purpose, my emailer has problems if they
> are together) I and a few others had issues with the slash-slash-equals
> thing, but were unable to persuade Damian, Larry, et al to change.
Hopefully those problems had nothing to do with you MUA ;-)
> I'd like to make one more proposal for defaulting. Damian seems to
> like properties for arguments, how 'bout this construct:
>
> sub load_data ( $version is default(1) ) {...}
>
> It's clean, fits the existing syntax, and immediately understandable.
> Thoughts?
So, how would you write the equivalent to this:
$foo //= $a // $b // $c;
Or are you proposing to *only* replace //=? Or are you proposing to
*only* replace //= in subroutine declarations?
What issues did you have with //=? It seems clear and concise to me.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Defaulting params (reprise)
From: Jonathan Scott Duff [EMAIL PROTECTED] > Or are you proposing to *only* replace //=? Or are you > proposing to *only* replace //= in subroutine declarations? Only augment //= in subroutine declarations, //= would also work. > What issues did you have with //=? It seems clear and concise to me. I love the //= operator, but in the context of sub declarations it's confusing as the *only* way to default an argument. I still think = makes sense as an argument defaulter... but that issue's been settled for now and I'm not advancing it again. :-) -Miko mail2web - Check your email from the web at http://mail2web.com/ .
Re: Defaulting params (reprise)
On Wed, Sep 04, 2002 at 04:43:25PM -0400, [EMAIL PROTECTED] wrote: > Only augment //= in subroutine declarations, //= would also work. > I love the //= operator, but in the context of sub declarations it's > confusing as the *only* way to default an argument. Oh. You want default() to be synonymous with //= but only in subroutine declarations. That seems a tad odd. Why not make it synonymous everywhere? my $foo is default(23); # same as ... my $foo //= 23; -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Defaulting params (reprise)
From: Jonathan Scott Duff [EMAIL PROTECTED]
> Oh. You want default() to be synonymous with //= but only in
> subroutine declarations. That seems a tad odd. Why not make it
> synonymous everywhere?
>
> my $foo is default(23); # same as ...
> my $foo //= 23;
Well, for "is default" to DWIM in a function call, it would almost have to
not DWIM outside a function call. Why? Well, the concept (as seen through
my too-human eyes) would be that the function arguments would be created
and populated something like this: 1) create the variable 2) if the
argument is sent, set the value of the variable using the sent value 3)
else set the value using the default property.
OK, that makes sense so far, but outside of a function call, I'm not sure
where it would be decided that the variable was never set, and so it would
never get the default value. Yes, "is default" could populate the variable
as soon as it is created, but that seems wasteful.
Is there a general rule that a property must make sense in all contexts?
If Perl6 has the "is named" property for sub arguments, does that mean that
it must also make sense outside a function...
my $foo is named('bar');
(Hmm, maybe it does... you could have two variables aliased to each other.
OK, bad example. Work with me here.)
-Miko
mail2web - Check your email from the web at
http://mail2web.com/ .
[perl #17007] [PATCH] Re: HP-UX state report
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #17007]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17007 >
On Wed, 9 Jan 2002, Andy Dougherty wrote:
> > >For perl5, the main makefile calls (essentially)
> > >
> > > $(CC) -o perl
> > >
> > >while the parrot Makefile calls
> > >
> > > $(LD) -o test_main
> On Wed, 9 Jan 2002, Dan Sugalski wrote:
> >
> > It's a platform-independence issue. Non-Unix platforms need to call the
> > linker, unix ones don't.
[Me again, still from January:]
> I think we've got lots of things mixed up on all ends. Perl5's
> Unix-centric Configure is showing up again.
>
> Specifically, Perl5's $Config{ld} is documented as follows:
>
> ld: This variable indicates the program to be used to link
> libraries for dynamic loading. On some systems, it is 'ld'.
> On ELF systems, it should be $cc. Mostly, we'll try to respect
> the hint file setting.
>
> The problem is that we really need at least *three* variables, something
> like the following:
>
> Variable description
> ccCompiler -- used to turn .c files into object files.
> (Usually cc or cl, or something like that.)
> link Linker, used to link object files (plus libraries) into
> an executable. Usually $cc on Unix-ish systems. VMS and
> Win32 might use "Link".
> ldTool used to build dynamically loadable libraries. Often
> $cc on Unix-ish systems, but apparently sometimes it's ld.
> Perl5's Configure/Makefile.SH build system incorrectly _assumes_ that
> linker=$cc.
> One possible "fix" for now is to introduce these *three* variables into
> parrot's Configure, and letting ${link} default to ${cc} for now,
> unless overridden by a hints file. The parrot Makefile would then call
> (essentially)
> $(LINK) -o test_main
> and HP/UX would work again.
Here, at long last, is a patch to implement that "fix". I'd appreciate
folks testing it on HP/UX and on non-Unix platforms.
I'm not particularly wedded to the names qw(cc link ld). Any reasonable
set will do.
If this patch is accepted, some hints files which set ldflags may need
revisiting -- it's not clear to me if they were being set for passing
to $link or $ld.
diff -r -u parrot-orig/config/gen/makefiles/root.in
parrot-andy/config/gen/makefiles/root.in
--- parrot-orig/config/gen/makefiles/root.inWed Sep 4 09:00:38 2002
+++ parrot-andy/config/gen/makefiles/root.inWed Sep 4 15:46:23 2002
@@ -5,6 +5,7 @@
RM_RF = ${rm_rf}
AR_CR = ${ar} cr
RANLIB = ${ranlib}
+LINK = ${link}
LD = ${ld}
LD_SHARED = ${ld_shared}
LD_OUT = ${ld_out}
@@ -116,6 +117,7 @@
###
CFLAGS = ${ccflags} ${cc_warn} ${cc_inc} ${cc_hasjit} ${cg_flag}
+LINKFLAGS = ${linkflags}
LDFLAGS = ${ldflags}
C_LIBS = ${libs}
@@ -161,7 +163,7 @@
mops : examples/assembly/mops${exe} examples/mops/mops${exe}
$(TEST_PROG) : test_main$(O) $(GEN_HEADERS) $(O_DIRS) $(O_FILES)
lib/Parrot/OpLib/core.pm lib/Parrot/PMC.pm
- $(LD) ${ld_out}$(TEST_PROG) $(LDFLAGS) $(O_FILES) test_main$(O) $(C_LIBS)
+ $(LINK) ${ld_out}$(TEST_PROG) $(LINKFLAGS) $(O_FILES) test_main$(O) $(C_LIBS)
lib_deps_object : $(O_DIRS) $(O_FILES)
$(PERL) tools/dev/lib_deps.pl object $(O_FILES)
@@ -197,7 +199,7 @@
$(LD) $(LD_SHARED) $(LD_SHARED_FLAGS) $(LDFLAGS)
$(LD_OUT)blib/lib/libparrot$(SO) $(O_FILES) $(C_LIBS)
$(TEST_PROG_SO) : test_main$(O) blib/lib/libparrot$(SO) lib/Parrot/OpLib/core.pm
lib/Parrot/PMC.pm
- $(LD) $(LDFLAGS) $(LD_OUT)$(TEST_PROG) test_main$(O) blib/lib/libparrot$(A)
$(C_LIBS)
+ $(LINK) $(LINKFLAGS) $(LD_OUT)$(TEST_PROG) test_main$(O)
+blib/lib/libparrot$(A) $(C_LIBS)
# XXX The dependancies on SO.MAJOR.MINOR and SO.VERSION are removed
# because those should be done at "make install" and not "make shared"
@@ -242,7 +244,7 @@
pdb$(O) : $(GENERAL_H_FILES)
$(PDB) : pdb$(O) $(O_DIRS) $(O_FILES)
- $(LD) ${ld_out}$(PDB) pdb$(O) $(O_FILES) $(C_LIBS) $(LDFLAGS)
+ $(LINK) ${ld_out}$(PDB) pdb$(O) $(LINKFLAGS) $(O_FILES) $(C_LIBS)
#
# Parrot Disassembler
@@ -252,14 +254,14 @@
disassemble$(O) : $(GENERAL_H_FILES)
$(DIS) : disassemble$(O) $(O_DIRS) $(O_FILES)
- $(LD) ${ld_out}$(DIS) disassemble$(O) $(O_FILES) $(C_LIBS) $(LDFLAGS)
+ $(LINK) ${ld_out}$(DIS) disassemble$(O) $(LINKFLAGS) $(O_FILES) $(C_LIBS)
#
# Parrot Dump
#
#$(PDUMP) : pdump$(O) packfile$(O)
-# $(LD) ${ld_out}$(PDUMP) pdump$(O) packfile$(O) string$(O) chartype$(O)
memory$(O) $(C_LIBS) $(LDFLAGS)
+# $(LINK) ${ld_out}$(PDUMP) $(LINKFLAGS) pdump$(O) packfile$(O) string$(O)
+chartype$(O) memory$(O) $(C_LIBS)
###
@@ -289,7 +291,7 @@
$(PERL) pbc2c.pl
Re: [netlabs #801] [PATCH] PerlArray in scalar context
On Wed, 4 Sep 2002, H.Merijn Brand wrote:
> On Wed 04 Sep 2002 20:31, "Sean O'Rourke" <[EMAIL PROTECTED]> wrote:
> > And fewer temporaries, by translating this:
> >
> > @a = @b ^+ @c ^+ @d;
> >
> > into this:
> >
> > for @a; @b; @c ; @d -> $a, $b, $c, $d is rw {
> > $d = $a + $b + $c;
>
> $a = $b + $c + $d;
>
> I might hope
Yes, that advanced "correctness" feature will be available in a future
release...
/s
Re: Argument aliasing for subs
[EMAIL PROTECTED] wrote:
>> sub hidden (str $name, int $force, int $override is aka($force))
>> { ... }
>
>
> Would the following be simpler...?
>
> sub hidden (str $name, int $force is aka($override))
>{ ... }
Yeah, that's what I meant.
Sorry. I've travelled 14,000 miles and given 93 hours of
presentations in the last 18 days. [Note to self: no more
posting whilst semi-conscious!!!]
%-)
> BTW, the aka thing is cool. It could be complementary to "is named":
>
> # can't use force_tainted as argument:
> sub hidden (int $force_tainted is named($force))
>
> # can use force_tainted as argument:
> sub hidden (int $force_tainted is aka($force))
Yes, that was the idea. :-)
Damian
Hypotheticals again
The thread on hypotheticals has caused me to reread that section of A5 a few times now and a couple of paragraphs bother me the more I read them. I'll just quote the parts that bother me: ... If a regex sets a hypothetical variable that was declared with either my or our beforehand, then the regex modifies that lexical or package variable, and let is purely a run-time operation. On the other hand, if the variable is not pre-declared, it's actually stored in the regex state object. In this case, the let also serves to declare the variable as lexically scoped to the rest of the regex, in addition to its run-time action. ... So, each time I use a hypothetical, I have to be concious of which variables are currently in scope? Perl can't help be with this task because how does it know if I meant to hypothetically clobber that lexical or store something in the match object. This is only really a problem if you expect "let" variables to always show up in the match object and sometimes they don't. So why not make it so that "let" also always causes these variables to appear in the match object? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Hypothetical variables and scope
Jonathan Scott Duff wrote:
> It seems odd to require two syntactic elements to achieve one semantic.
> And actually, after looking at A5, that's not what Larry wrote:
>
> my $x;
> / (\S*) { let $x = .pos } \s* foo /
A typo, I believe. He has been very consistent in discussions that
hypothetical bind, rather than assigning.
Perhaps he's changed his mind since, but I haven't heard anything to that
effect.
Damian
Re: Defaulting params (reprise)
On Wed, Sep 04, 2002 at 05:06:32PM -0400, [EMAIL PROTECTED] wrote: > Is there a general rule that a property must make sense in all contexts? Nah, I was just being distracted by work and not thinking clearly about your default() proposal. :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Hypotheticals again
In a message dated Wed, 4 Sep 2002, Jonathan Scott Duff writes: > The thread on hypotheticals has caused me to reread that section of A5 a > few times now and a couple of paragraphs bother me the more I read > them. I'll just quote the parts that bother me: > > ... If a regex sets a hypothetical variable that was declared > with either my or our beforehand, then the regex modifies that > lexical or package variable, and let is purely a run-time > operation. > > On the other hand, if the variable is not pre-declared, it's > actually stored in the regex state object. In this case, the let > also serves to declare the variable as lexically scoped to the > rest of the regex, in addition to its run-time action. ... > > So, each time I use a hypothetical, I have to be concious of which > variables are currently in scope? Perl can't help be with this task > because how does it know if I meant to hypothetically clobber that > lexical or store something in the match object. This is only really a > problem if you expect "let" variables to always show up in the match > object and sometimes they don't. So why not make it so that "let" > also always causes these variables to appear in the match object? It should. I think everyone has been proceeding under the assumption that they are. If you use a variable name already defined, then you set both the match object's attribute of the same name (minus the sigil if sigil is '$') *and* the external variable. Trey
Re: Multimethod Dispatch
Dan Sugalski wrote: >> Dan, can you explain what "multimethod dispatch" is? > > Damian can explain it better than I can, I thought you did a great job! However, anyone who wants to know more about multiple dispatch might also like to read: http://www.samag.com/documents/s=1274/sam05010010/ Damian
Re: Hypotheticals again
Trey Harris wrote:
>>So, each time I use a hypothetical, I have to be concious of which
>>variables are currently in scope? Perl can't help be with this task
>>because how does it know if I meant to hypothetically clobber that
>>lexical or store something in the match object. This is only really a
>>problem if you expect "let" variables to always show up in the match
>>object and sometimes they don't. So why not make it so that "let"
>>also always causes these variables to appear in the match object?
>
>
> It should. I think everyone has been proceeding under the assumption that
> they are. If you use a variable name already defined, then you set both
> the match object's attribute of the same name (minus the sigil if sigil is
> '$') *and* the external variable.
That's what I'd like to see too. Indeed, I'd like to see the scalars
turn up in C<$o{'$name_with_dollar"}> as well. TMTOPTSI [*]
Damian
[*] There's More Than One Place To Store It. ;-)
Re: Defaulting params (reprise)
On Wed, Sep 04, 2002 at 03:48:41PM -0500, Jonathan Scott Duff wrote: > On Wed, Sep 04, 2002 at 04:43:25PM -0400, [EMAIL PROTECTED] wrote: > > Only augment //= in subroutine declarations, //= would also work. > > I love the //= operator, but in the context of sub declarations it's > > confusing as the *only* way to default an argument. > > Oh. You want default() to be synonymous with //= but only in > subroutine declarations. That seems a tad odd. Why not make it > synonymous everywhere? > > my $foo is default(23); # same as ... > my $foo //= 23; I dont see what's that meant to be achieving. Surely It's always 23. andrew -- Cancer: (June 22 - July 22) You will soon be exposed to the most rocking music ever, but due to your unrockable nature, you will remain profoundly unrocked.
Re: Defaulting params (reprise)
In a message dated Wed, 4 Sep 2002, Andrew Wilson writes: > On Wed, Sep 04, 2002 at 03:48:41PM -0500, Jonathan Scott Duff wrote: > > On Wed, Sep 04, 2002 at 04:43:25PM -0400, [EMAIL PROTECTED] wrote: > > > Only augment //= in subroutine declarations, //= would also work. > > > I love the //= operator, but in the context of sub declarations it's > > > confusing as the *only* way to default an argument. > > > > Oh. You want default() to be synonymous with //= but only in > > subroutine declarations. That seems a tad odd. Why not make it > > synonymous everywhere? > > > > my $foo is default(23); # same as ... > > my $foo //= 23; > > I dont see what's that meant to be achieving. Surely It's always 23. A more practical application would be: my $foo; # Code which might or might not set $foo... $foo //= 23; # or $foo is default(23); In such a case, the C just looks plain odd to me. Properties are meant to be out-of-band information; miko's suggestion would have this property setting the *value* of the variable. Weird. C seems perfectly reasonable to me. Trey
Re: Hypotheticals again
On Wed, Sep 04, 2002 at 10:34:23PM +, Damian Conway wrote:
> Trey Harris wrote:
> > It should. I think everyone has been proceeding under the assumption that
> > they are. If you use a variable name already defined, then you set both
> > the match object's attribute of the same name (minus the sigil if sigil is
> > '$') *and* the external variable.
>
> That's what I'd like to see too. Indeed, I'd like to see the scalars
> turn up in C<$o{'$name_with_dollar"}> as well. TMTOPTSI [*]
Oh good. Me too. I hadn't been proceeding under any assumptions if I
could help it, but that's only because everytime I think I understand
the new perl6isms someone throws a kink in my understanding. :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
[perl #17008] [PATCH] automatic PMC integration
# New Ticket Created by Steve Fink # Please include the string: [perl #17008] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=17008 > I tend to create new PMC classes frequently, and they're a pain to maintain without committing, because you have to touch lots of files to add a PMC, and in ways that are sure to cause conflicts. With this patch applied, creating a PMC becomes a matter of dropping the .pmc file into the classes/ directory and re-running Configure.pl. Everything else (and there are a lot of different things) will be autogenerated from there. This is not a major change, since Configure.pl already scans the directory, but only for the purpose of adding things to the makefile. If you have a classes/*.pmc that for some reason you do NOT want part of the build, you can tag it with the 'extension' keyword after the pmclass declaration (yes, this patch contains documentation, too.) Also, you can still use the --ask flag with Configure.pl to choose the exact subset of PMCs you want compiled in. (And I think I may have repaired a problem with that, too.) I will be applying my Anti-Warnock Bludgeon +3 to this patch: if nobody objects fairly soonish, I'm going to apply it myself. (I have a more important patch waiting behind this one.)
Re: [perl #17008] [PATCH] automatic PMC integration
Oh, right. The patch. Here it is.
Index: .cvsignore
===
RCS file: /cvs/public/parrot/.cvsignore,v
retrieving revision 1.19
diff -p -u -a -r1.19 .cvsignore
--- .cvsignore 14 Jul 2002 10:25:55 - 1.19
+++ .cvsignore 4 Sep 2002 22:18:25 -
@@ -16,3 +16,4 @@ vtable.ops
vtable_ops.c
platform.c
jit_cpu.c
+core_pmcs.c
Index: MANIFEST
===
RCS file: /cvs/public/parrot/MANIFEST,v
retrieving revision 1.207
diff -p -u -a -r1.207 MANIFEST
--- MANIFEST4 Sep 2002 03:48:26 - 1.207
+++ MANIFEST4 Sep 2002 22:18:27 -
@@ -546,7 +549,6 @@ pbc2c.pl
pdb.c
pdump.c
pmc.c
-pmc_pm.pl
pxs.c
register.c
resources.c
Index: pmc_pm.pl
===
RCS file: pmc_pm.pl
diff -N pmc_pm.pl
--- pmc_pm.pl 22 Aug 2002 00:33:58 - 1.3
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,27 +0,0 @@
-#!/usr/bin/perl
-
-open (IN, "include/parrot/pmc.h") or die $!;
-open (OUT, ">lib/Parrot/PMC.pm") or die $!;
-
-print OUT <<'EOF';
-package Parrot::PMC;
-use vars qw(@ISA %pmc_types @EXPORT_OK);
-
-@ISA = qw( Exporter );
-@EXPORT_OK = qw( %pmc_types);
-
-%pmc_types = (
-EOF
-
-$num = 0;
-while () {
-if (/enum_class_(\S+)/) {
-my $name = $1;
-$name =~ s/,$//;
-last if $name eq "max";
-print OUT "\t$name => $num,\n";
-$num++;
-}
-}
-print OUT ");\n\n1;\n";
-
Index: classes/default.pmc
===
RCS file: /cvs/public/parrot/classes/default.pmc,v
retrieving revision 1.31
diff -p -u -a -r1.31 default.pmc
--- classes/default.pmc 19 Aug 2002 23:15:20 - 1.31
+++ classes/default.pmc 4 Sep 2002 22:18:39 -
@@ -13,7 +13,7 @@
#define INT2KEY(i,k) ((k) ? key_new_integer((i), *(k)) : NULL)
-pmclass default noinit {
+pmclass default abstract noinit {
void init () {
}
Index: classes/pmc2c.pl
===
RCS file: /cvs/public/parrot/classes/pmc2c.pl,v
retrieving revision 1.16
diff -p -u -a -r1.16 pmc2c.pl
--- classes/pmc2c.pl8 Aug 2002 20:57:48 - 1.16
+++ classes/pmc2c.pl4 Sep 2002 22:18:42 -
@@ -364,7 +364,7 @@ A preamble, consisting of code to be cop
=item 2.
-pmclass PMCNAME [extends PMCNAME] {
+pmclass PMCNAME [extends PMCNAME] [abstract] [extension] [noinit] {
=item 3.
Index: config/inter/pmc.pl
===
RCS file: /cvs/public/parrot/config/inter/pmc.pl,v
retrieving revision 1.3
diff -p -u -a -r1.3 pmc.pl
--- config/inter/pmc.pl 22 Jul 2002 06:44:22 - 1.3
+++ config/inter/pmc.pl 4 Sep 2002 22:18:42 -
@@ -43,9 +43,33 @@ END
}eg;
# build list of libraries for link line in Makfile
(my $pmc_classes_o = $pmc_o) =~ s/^| / classes\//g;
-
+
+ # Gather the actual names (with MixedCase) of all of the
+ # non-abstract built-in PMCs (which currently means everything but
+ # 'default'.)
+ my @names;
+ PMC: foreach my $pmc_file (split(/ /, $pmc)) {
+ my $name;
+ open(PMC, "classes/$pmc_file") or die "open classes/$pmc_file: $!";
+ while () {
+ if (/^pmclass (\w+)(.*)/) {
+ $name = $1;
+ my $decl = $2;
+ $decl .= until ($decl =~ s/\{.*//);
+ next PMC if $decl =~ /\babstract\b/;
+ next PMC if $decl =~ /\bextension\b/;
+ last;
+ }
+ }
+ close PMC;
+ die "No pmclass declaration found in $pmc_file"
+if ! defined $name;
+ push @names, $name;
+ }
+
Configure::Data->set(
pmc => $pmc,
+pmc_names => join(" ", @names),
pmc_o => $pmc_o,
pmc_build => $pmc_build,
pmc_classes_o => $pmc_classes_o
Index: docs/vtables.pod
===
RCS file: /cvs/public/parrot/docs/vtables.pod,v
retrieving revision 1.12
diff -p -u -a -r1.12 vtables.pod
--- docs/vtables.pod29 Aug 2002 20:02:46 - 1.12
+++ docs/vtables.pod4 Sep 2002 22:18:43 -
@@ -26,7 +26,7 @@ runtime error.
=item *
-To be perfect honest, this is a slightly flawed example, since it's
+To be perfectly honest, this is a slightly flawed example, since it's
unlikely that there will be a distinct "Python scalar" PMC class.
The Python compiler could well type-inference variables such that
C would be a C and C would be a C.
@@ -91,9 +91,11 @@ containing all the methods.
Now you'll have to do something a little different depending on whether
you're writing a built-in class or an extension class. If you're writing
a built-in class, then you'll see a reference to
-C in the C function. This is something
-that you need to add to the C of built-in classes located in
-F. If you're not writing a built-in class, you need to change the
+C in the C fu
[perl #17009] [PATCH] fix make shared
# New Ticket Created by Kevin Falcone
# Please include the string: [perl #17009]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17009 >
If you start with a clean parrot tree and try to run 'make shared' it
will die because include/parrot/vtable.h hasn't been generated yet.
This fixes that.
-kevin
RCS file: /cvs/public/parrot/config/gen/makefiles/root.in,v
retrieving revision 1.34
diff -u -p -r1.34 root.in
--- config/gen/makefiles/root.in4 Sep 2002 04:17:50 - 1.34
+++ config/gen/makefiles/root.in4 Sep 2002 22:42:50 -
@@ -186,7 +186,7 @@ blib :
blib/lib : blib
-mkdir blib${slash}lib
-shared : blib/lib blib/lib/libparrot$(SO) ${blib_lib_libparrot_a} $(TEST_PROG_SO)
+shared : $(GEN_HEADERS) blib/lib blib/lib/libparrot$(SO) ${blib_lib_libparrot_a}
+$(TEST_PROG_SO)
# XXX Unix-only for now
blib/lib/libparrot$(A) : blib/lib $(O_DIRS) $(O_FILES)
--
"The Windows Perl motto: It's just as well there's more than one
way to do it because most of them don't work." -- Simon Cozens
RE: [netlabs #801] [PATCH] PerlArray in scalar context
Sean O'Rourke:
# On Wed, 4 Sep 2002, Peter Haworth wrote:
# > Having the iteration done in the bytecode could make this simpler,
# > although at the expense of needing more bytecode.
#
# And fewer temporaries, by translating this:
#
# @a = @b ^+ @c ^+ @d;
#
# into this:
#
# for @a; @b; @c ; @d -> $a, $b, $c, $d is rw {
# $d = $a + $b + $c;
# }
What if (say) @b is a two-dimensional array?
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
"In other words, it's the 'Blow up this Entire Planet and Possibly One
or Two Others We Noticed on our Way Out Here' operator."
--Damian Conway
Re: Hypothetical variables and scope
On Wed, Sep 04, 2002 at 10:25:39PM +, Damian Conway wrote:
> Jonathan Scott Duff wrote:
>
> > It seems odd to require two syntactic elements to achieve one semantic.
> > And actually, after looking at A5, that's not what Larry wrote:
> >
> > my $x;
> > / (\S*) { let $x = .pos } \s* foo /
>
> A typo, I believe. He has been very consistent in discussions that
> hypothetical bind, rather than assigning.
This continues to make no sense to me. The "hypotheticality" of a
variable seems quite orthogonal to what you do with it (bind, assign,
whatever). Why should these two things be intimate? And if they are,
does that mean that these:
/ (\S*) { let $x = .pos } \s* foo /
/ (\S*) { let $x; ... $x = .pos } \s* foo /
throw some sort of exception or error? That could be surprising if
the ellipses are really some long bit of code. (Why is that scalar
different from any other scalar? Because it's hypothetical. Suddenly
we've a new "class" of variable that people have to be aware of)
Anyway, I like the semantics described by Ken Fox earlier. (And, in
fact, that's what I thought happened until just recently :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: User-defined character classes and repeat counts
> Again, it would be nice to be able to flag these to the compiler in a
> rule:
> rule thrice :count { <={.count < 4}> }
> / a? /
> Note that the C would cause the thrice count-rule to be matched
> non-greedily because the regex parser knows that it's a count, not a
> generic rule.
Going off on a tangent here, is there some deep and meaningful reason
why we're still using C as a non-greedy multiplier suffix? I only
ask because one of the biggest sticking points with C in my Perl
students is that it means two pretty completely different things,
depending on whether a multiplier comes before it or not.
A5 solved the dual-meaning of C<^> nicely, by dumping the syntax for
character classes.
If we're redefining the regex grammar so that different things don't
look too similar (one of Larry's philiophical points in A5), isn't the
dual meaning of C another one that ought to be dealt with? It's not
like the non-greedy suffix is something that is deeply ingrained in
(non-Perl) regex culture.
I'm not suggesting syntax for a revised non-greediness operator. It'd
probably include a colon and thus disqualify itself according to Larry's
Law of Language Design. But it'd have to reflect good Huffman coding.
(Besides, this'd nicely help solve one aspect of what Aaron's bringing up
in the quoted message above.)
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
"We just ride with the wind, and we'll drive through the rain. We don't know
where we'll get to, or if we'll get back again." - _Blown by the Wind_, Alan
Parsons
Re: [Info] African Grey update
On Wed, Sep 04, 2002 at 08:07:21PM +0200, Peter Gibbs wrote: > For anybody who may be interested, the latest news from the > pirate cave follows. > > Recent changes: > * New aligned memory page allocator > * Above allocator used for PMC/buffer header arenas and memory > pool pages; this has allowed removal of the pointer from buffer > headers to their pool header > * Calculation of reclaimable space in memory pools removed, as > it is currently unreliable (COW and early-exit from compact_pool) > * string_compare uses memcmp for compatible strings > * new string vtable function for extracting substrings (only > implemented for singlebyte in current patch) > > Latest results of life.pasm: > African Grey > 5000 generations in 59.180210 seconds. 84.487703 generations/sec > A total of 131072 bytes were allocated > A total of 61024 DOD runs were made > A total of 1105 collection runs were made > Copying a total of 614136 bytes > There are 71 active Buffer structs > There are 914 total Buffer structs Twice as fast seems like a good thing. Is this with the stackwalk disabled? What prevents this from being applied to Parrot now? Is there an easy way to see how many of those collection runs were complete, or the total number of pages collected and the total number that could have been collected, or some sort of statistic that indicates how often the paged collections kick in? I'm sure I'm using the wrong terminology. Java has minor and major collections for a vaguely similar distinction. They also have timing statistics, which could be interesting -- would it be easy to wrap DOD and collect with gettimeofday() calls, and print out the total amount of time doing each?
RE: [netlabs #801] [PATCH] PerlArray in scalar context
On Wed, 4 Sep 2002, Brent Dax wrote: > What if (say) @b is a two-dimensional array? Then you get "interesting values of undef" :). Seriously, I suspect one of the following: 1 - runtime error 2 - each row (or column) of @b numified to its length 3 - the first element of each row/col of @b 4 - the other arrays boosted to the highest dimension I like #2, because it is easy and keeps hyper-operation simple. If those aren't just numeric operators, but some other weird user-defined thing, then an array as one operand makes sense. The simpler hyping is, the better, IMHO. Some people doubtless like #4 because it's a natural extension of the way scalars get auto-boosted to one-dimensional arrays. As a middle ground, we could have 5 - use /\^<$n>/ to do a nested $n-dimensional hype Oh, yeah. /s who regrets opening his mouth...
Re: Multimethod Dispatch
Dan Sugalski wrote: > At 9:10 AM -0400 9/4/02, [EMAIL PROTECTED] wrote: >> So, just to clarify, does that mean that multi-dispatch is (by >> definition) >> a run-time thing, and overloading is (by def) a compile time thing? > > No. They can be both compile time things or runtime things, depending on > the characteristics of the language. I don't think so. Those terms are well understood by the OO community. Bertrand Meyer wrote on the subject: http://www.inf.ethz.ch/personal/meyer/publications/joop/overloading.pdf Prior to C++ there might have been some ambiguity (for example, some people have talked about run-time vs compile-time overloading), but C++ has completely stolen the term. Here's a slide from one of Damian's presentations that states multi-methods are "Like C++ overloading, but polymorphic." http://www.csse.monash.edu.au/~damian/TPC/1999/MultipleDispatch/Presentation/sld010.htm - Ken
Re: regex args and interpolation
David Whipp wrote:
> But can I use a non-constant date?
You didn't show us the iso_date rule.
> Obviously we could put the onus on the module writer to write super-flexible
> rules/grammars. But will there be an easy way to force interpolative context
> onto this type of regex-valued subroutine arg?
With this rule you need literal numbers:
rule iso_date { $year:=(\d{4}) -
$month:=(\d{2}) -
$day:=(\d{2}) }
This rule is more flexible:
rule iso_date { () - { let $year := eval $1 }
() - { let $month := eval $2 }
() { let $day := eval $3 }
<($year =~ /^\d{4}$/ &&
$month =~ /^\d{2}$/ &&
$day =~ /^\d{2}$/)> }
The eval is very restrictive though -- it forces the terms to
have values at compile time and breaks lexical scoping. (Unless
eval can play games with %MY and somehow evaluate in the
caller's scope. Maybe caller.{MY}.eval?)
We can tidy that up a little with another rule:
rule value {
{ let $0 := caller(2).{MY}.eval($term) } }
rule iso_date { $year:= -
$month:= -
$day:=
<($year =~ /^\d{4}$/ &&
$month =~ /^\d{2}$/ &&
$day =~ /^\d{2}$/)> }
There's still the compile-time value problem though.
What is really needed is something that converts the date syntax
to normal Perl code:
rule iso_date { () -
() -
()
{ use grammar Perl::AbstractSyntax;
$0 := (expr (invoke 'new (class 'Date) $1 $2 $3))) }
This rule just generates code -- the $0 return result is spliced
into the syntax tree at compile time. All the valid value checking
is done at run-time in the Date object constructor. (Or maybe at
compile time if the compiler can figure out there aren't any
side-effects and the object is serializable. But that's a whole
different thread.) It's very efficient because it only parses the
source code once. All the compiler optimizations (like constant
folding) get applied to your special syntax. But you're writing
Parrot macros (IMCC on steroids maybe?) and not Perl!
Another approach is to delay the final parse until run-time. In
this case, the compiler runs the rule over the input source
code and records the matched text, but without running any of the
code blocks. When the sub is called at run-time, the matched text
is parsed by the rule again, but this time with the code blocks
enabled. The second rule above (using eval) would work fine this
way (as long as the %MY games are possible). The down-side to
this approach is that you have lots of string evals happening
at run-time.
Maybe all of these techniques will be possible?
rule x is macro { ... }
rule y is delayed { ... }
rule z is syntax { ... }
- Ken
Re: Parrot: maximizing the audience
At 12:41 PM 9/4/2002 -0400, Andrew Kuchling wrote:
>[Please CC: me on any responses.]
>First reason I don't work on it very much:
>
>1. Frankly, it's not much fun. I can spend my free time writing
>Python code, an environment I like, or I can work in the unfamiliar
>and uncomfortable Parrot build environment and source code, grepping
>through it looking for examples to help me figure out what's going on.
>Guess which option wins most often?
This is no surprise. Parrot documentation will be lacking until
things settle down.
>Some larger reasons:
>
>2. No clear benefit to using Parrot.
>
>What new possibilities does Parrot provide for Python? Stacklessness?
>Better GC? A new I/O layer? Language interop? None of these is more
>than mildly interesting to me, and none is a killer application.
Faster execution times would be on the top of my list.
I'm speaking for Perl, not Python, but last time I checked, neither
language was spectacular in this category.
>Personally, I'm skeptical of the claims of cross-language interop
>because I don't think a library written in Perl will provide an Python
>interface that looks at all idiomatic, and vice versa. You could
I agree with you.
>A big benefit for Python might be if someone writes a Parrot to
>{machine code,.NET} compiler, but there are existing alternatives such
>as Pyrex and no one has written such a Parrot compiler yet, so that's
>not too convincing.
It may not happen either if the JIT is fast enough.
>If every other language was using Parrot, there would be some pressure
>to join them, but given the lukewarm response by other language
>communities, that's not a factor at the moment.
Its too early to have any response, Parrot is still alpha software.
>3. Lack of any real languages on Parrot
>
>I'm slightly worried that Parrot is already succumbing to the lure of
>premature optimization -- counting the number of opcodes executed per
>second, trying to save a C pointer dereference here or there -- before
>the Parrot VM has been shown to be useful as a language target. No
This is just responsible programming. We benchmark to track
progress and we need no excuse to over-optimize..; we ARE
building a virtual CPU you know. :)
>one is running real programs in Perl or Python or Scheme or anything
>on the VM (right?), so any optimizations at this point are just
>guesses, and may not actually be relevant to real programs. This
All opcodes that are used by real programs are relevant. We aren't
dealing with unknown technology here; most of the components
of a VM are proven and supported by academic research and most of
us are pretty smart people so I don't think this is a wasted exercise.
>makes me wonder if the Parrot implementation will just retrace the
>same path as the Perl5 implementation.
I don't call Perl5 a failure. Maybe the implementation is hairy, but it
works well and is THE scripting language of choice for system-admins,
DBAs and countless other professionals.
>I'd rather see a full implementation of a single real language that
>people actually use (Scheme, Python, whatever) on top of an
Eek, Scheme would do little for Parrot's acceptance in the
commercial world, and we all know its the commercial world
that provides most of the fuel to the fire. Seeing a "real" Perl, Python,
Java or C# running on Parrot would be my preference.
>unoptimized Parrot VM, instead of the existing situation of a bunch of
>half-implemented or toy languages on top of an optimized VM. That
>would be a more convincing proof that Parrot can actually handle a
>real language, and gives other languages something to test
>interoperability with.
Its really unfair to size Parrot up in this way. I hope the state of things
hasn't scared you off, we need good people, but it won't stop me
from giving my trickle of support in hopes of creating exactly what
you just mentioned. You, being a Python hacker and open-source
contributor, of all people, should know how slow this game moves.
Thanks for the honest comments,
-Melvin
Re: Parrot: maximizing the audience
On Wed, 2002-09-04 at 15:48, Steve Fink wrote: > I'm actually somewhat surprised at how little Parrot is tied to Perl. I've no clue whether I agree or not. OT1H, given its origins from the bosom of Perl, Parrot is surprisingly independent. OTOH, compare where Parrot is to where it *might* have been had it started as a completely independent project. When I went back to resolve once-and-for-all the Perl or Parrot Design Document debate earlier, I felt that to truly make Parrot independent, not only would I have to change the name throughout PDD 0, but I would have to revisit and revalidate - from a language-neutral position - all of the original decisions. Some points would need to be removed. Others added. Should POD remain the documentation standard? It made sense at the time, because this was just Perl. Would a language-neutral group reach the same conclusion? Or would we be supplying our documentation in *ML/text/*roff? Would Perl be the configuration/utility language of choice, vice Bourne, C, autoconf, ...? Even something as trivial as version numbers may or may not apply. Parrot was just one small part of Perl that we were reinventing. Now it's one big part of itself. It will be hard to "untaint" the early Parrot work without seeming to continue to be Perl-specific. In fact, *because* of how Parrot (the project) was developed, we'd probably need to *overcompensate* the shift away, just to make the field seem level to other languages. Of all the areas of Perl overlap, however, the one that is *most* critical to Parrot's independence is both the one most people have labeled as unimportant, and will be the one that will be most difficult to maintain and deal with on a daily basis, and that's the mailing list. It's great that we've got a bunch of toy languages that we provide, but we're not providing Perl 6 as a toy. Its development *must* move out of the parrot tree, and that means that we've got to draw a rigid line between the two. Trying to have Perl 6 internals (in terms of Parrot) and Parrot internals discussed on the same list will lead to a blurring of that line, with all the standard ramifications of making assumptions in code, etc, etc. (Not to mention driving the developers crazy who have to weed out mail on the project they're not interested in.) So since Parrot's history is on perl6-internals, Perl 6 internals work should spin off onto parrot-externals. Problem solved. They're separated. :-) Two other human X factors to consider: First, with Perl 6 being developed onto a moving target, there are undoubtedly going to be Perl 6 bugs/features/patches/additions that are going to cross the line into the Parrot cage. It happens in concurrent development. It's going to take effort to keep the two apart. Second, while Parrot remains mainly supported by Perl 6 developers, it's going to be a burden on the bulk of that community to force themselves into those two different mindsets. I'm simply amazed that Nicholas Clark is able to play in both the Perl 5 and Parrot arenas, but they have very little overlap in the areas being addressed. It makes little sense to spawn a new list if 90% of the messages are cc:d to the other one. So that's what I feel is the difficult decision to make: the situation as it currently stands is *easiest* on the known developer base, but creates a barrier of entry for non-Perl implementers. However, we can make things easier for others to get more of a community buy-in, at the expense of effort by the Perl folks, but there's no guarantee that those people will come. -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
Re: Parrot: maximizing the audience
[EMAIL PROTECTED] (Jerome Quelin) writes: In the works is a new mail setup where we easily can have lists at other domains and still have them available via nntp etc. At that point I can create a dev at parrotcode.org list or something like that. (or when the perl6 people want to work on the internals of perl6 :-) ) - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: Parrot: maximizing the audience
Thanks, Steve. I agree 100% with everything you said! Except: > ... the best way to that > goal is to use Perl6 as the driver, at least until something else > shows up, because that's the only way to derive realistic requirements > for what needs to be accomplished. The incorrectness of that is directly proportional to the immaturity of the language specification. And it goes without saying (heh) that there are plenty of languages with more solid specs than Perl6. -- John Douglas Porter
Re: Parrot: maximizing the audience
Dan Sugalski wrote: > John Porter wrote: > > Some folks seem to think that sufficient reason exists now. > > That's fine. You don't have to convince some folks. You have to convince me. Actually, uh, I was kinda hoping that some folks would convince you. :-) Anyway, whenever someone (and it seems like I'm the only one who does) tries to invoke the Perl Gods around here, you're always quick to brandish your +5 Mace of Iconoclasty. You're quick to assert that this ain't your father's Olds, but you're not quite ready to allow that it might not be an Olds at all. jm2c. ty,tyvm. -- John Douglas Porter
Re: Parrot: maximizing the audience
Dan Sugalski wrote: > John Porter wrote: > > But what does Larry think? > > Hadn't particularly asked him. Does it really matter? Not if you say it doesn't. -- John Douglas Porter
Re: Parrot: maximizing the audience
Bryan C. Warnock wrote: > make things easier for others to get more of a community buy-in, at the > expense of effort by the Perl folks, but there's no guarantee that those > people will come. [EMAIL PROTECTED] ? -- John Douglas Porter
Re: Parrot: maximizing the audience
> [EMAIL PROTECTED] ? s/dev/code/, of course. -- John Douglas Porter
Re: [web-PATCH] parrot logo
[EMAIL PROTECTED] (Dan Sugalski) writes: [...] > The logo as currently used suffers from scaling issues, as it looks > like the full-size one's used with a size specified. I fixed that. And made it png. -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: [perl #17008] [PATCH] automatic PMC integration
On Wed, 4 Sep 2002, Steve Fink wrote: > I tend to create new PMC classes frequently, and they're a pain to > maintain without committing, because you have to touch lots of files > to add a PMC, and in ways that are sure to cause conflicts. Is one of these an intstack PMC, perchance? /s
Re: Argument aliasing for subs
Somewhere, in another thread . . .
Dr. Claw wrote . . .
>> sub hidden (str $name, int $force is aka($override))
>>{ ... }
>
>Yeah, that's what I meant.
Is it just me or is the 'is' property syntax a little
too intuitive? Seems like everywhere I turn, the
proposed syntax to solve a problem is to apply a
property. And is the is/but distinction still around?
Since but's proposal I've not seen any use of it, and
the distinction between a compile time and run time
property was somewhat hazy to me anyway, so I can't be
sure that it's dead or just of rare use.
-Erik
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
First crack at Builtins.p6m
Ok, so without knowing what the XS-replacement will look like and
without knowing what we're doing with filehandle-functions (is tell()
staying or does it get removed in favor of $fh.tell()) and a whole lot
of other stuff it's impossible to translate all of the Perl 5 functions
to Perl 6. However, what I've done is take a quick stab at creating at
least function signatures for everything that was in perlfunc and
implemented some of the functions that do not require any external junk
(e.g. reverse).
Some questions came up while I was doing this. Questions that came up a
lot, I put in comments at the front of the file. Other comments are
in-line and are marked with "XXX" for easy searching.
Anything that I think will be handled by internals or by the pre-coded
functions that are currently in parrot/languages/perl6/P6C/Builtins.pm,
I marked with "INTERNAL" for easy searching.
Please don't expect this to compile. It probably has typos and certainly
has masses of undefined class names (e.g. IO::Socket). It's really just
here to help me understand what I don't understand and to get some
questions on the table.
I'll keep updating this as more information about XS, filehandles, etc
become clear. There are also some functions (like split) that will
require my going over A5 with a fine-toothed comb before I proceed.
# Builtin functions
# XXX - This marker is used all over to indicate potential problems and
# quesitons about how Perl 6 works.
#
# High-level questions:
#
# When declaring:
# sub foo($a, $b) {...}
# and
# sub foo($a, *@rest) { ... }
# What is the correct order, and/or is this even valid? I need to know,
# given the way I did sort and reverse in order to handle exploded
# argument lists and arrays efficiently.
#
# What is happening to the IO functions? Do they just go away to be
# subsumed by the appropriate IO:: classes?
#
# Generally need to know how the interface ot libc will work, so
# that all of this junk can be implemented.
#
# Do I need to "@array is rw"? I would think not
# An EMACS helper macro
# (defalias 'perl6-mockup (read-kbd-macro
# "C-a sub SPC M-d C-y ( C-e ) SPC { SPC UNIMP(\" C-y \") SPC }"))
sub UNIMP($func) { die "$0: Unimplemented: $func" }
sub NEVER($func) { die "$0: $func makes no sense in Perl 6" }
# Math
sub abs($num is int){ return $num>=0 ?? $num :: -$num }
sub accept($new is IO::Socket, $gen is IO::Socket){ UNIMP("accept") }
sub alarm($seconds is int){ UNIMP("alarm") }
sub atan2($y is number, $x is number) { UNIMP("atan2") }
sub bind($socket is IO::Socket, $name) { UNIMP("bind") }
sub binmode($fh is IO::Handle, $disc //= ':raw'){ UNIMP("binmode") }
sub bless($ref, $name //= undef){ NEVER("bless") }
sub caller($expr //= undef){ UNIMP("caller") }
sub chdir($path //= $ENV{HOME}){ UNIMP("chdir") }
sub chmod($mode is int, *@paths){
for @paths -> $_ {
UNIMP("chmod $mode, $_")
}
# XXX - Return value?
}
sub chomp($string is rw){
my $irs = $ {"/"};
if defined $irs {
if $irs.isa(Object) {
return undef;
} elsif $irs.length == 0 {
$string =~ s/ \n+ $ //;
return $0;
} else {
$string =~ s/<{"<[$irs]>"}>+$//;
return $0;
}
}
}
sub chomp() { UNIMP("chomp(LIST)") }
sub chomp(*@strings is rw) { UNIMP("chomp(LIST)") }
sub chop($string is rw) { UNIMP("chop") }
sub chop() { UNIMP("chop") }
sub chop(*@strings) { UNIMP("chop") }
sub chown($uid is int, $gid is int, *@files) {
for @files -> $_ {
UNIMP("chown $uid, $gid, $_");
}
# XXX Return value?
}
sub chr($num is int //= $_){ return pack 'C', $num } # XXX Not UNICODE
sub chroot($path //= $_){ UNIMP("chroot") }
sub close($fh is IO::Handle //= "XXX_defaulthandle") { UNIMP("close") }
sub closedir($dh is IO::DirHandle) { UNIMP("closedir") }
sub connect($socket is IO:Socket, $name) { UNIMP("connect") }
sub cos($num is number //= $_) { UNIMP("cos") }
sub acos($num is number //= $_) { atan2( sqrt(1 - ($num ** 2)), $num ) }
sub tan($num is number //= $_) { return sin($num) / cos($num) }
sub cos($num is number //= $_) { UNIMP("cos") }
sub crypt($plaintext, $salt) { UNIMP("crypt") }
sub dbmclose(%hash) { NEVER("dbmclose") }
sub dbmopen(%hash, $dbname, $mask) { NEVER("dbmopen") }
# INTERNAL defined
# INTERNAL delete
# INTERNAL die
# INTERNAL do
sub dump($label //= $_) { NEVER("dump") }
# INTERNAL each
sub eof($fh is IO::Handle //= "XXX_defaulthandle") { UNIMP("eof") }
sub eval(&code) {
warn "Perl 6 uses try for blocks";
return try(&code);
}
# INTERNAL eval(string)
sub exec($program, *@args) { UNIMP("exec") } # XXX exec $prog $argv0, $argv1...
# INTERNAL exists
# INTERNAL exit
sub exp($num is number //= $_) { UNIMP("exp") }
sub fcntl($fh is IO::Handle, $func, $scalar) { UNIMP("fcntl") }
sub fileno($fh is IO::Handle //= "XXX_defaulthandl
Re: First crack at Builtins.p6m
Oh, BTW: Lest anyone think I'm spamming p6l for no reason, I sent the Builtins.p6m to p6l instead of p6i because I consider this a document, not code. When some of the questions get ironed out about the language, then I will talk to p6i about next steps.
Re: Argument aliasing for subs
> sub hidden (str $name, int $force is aka($override))
>{ ... }
I know that the property syntax is pseudo established,
but I'm beggining to become a bit jaded about all the
built in properties were building. What about good ol'
aliases?
sub hidden (str $name, int $force := $override)
{ . . .}
While less verbose, it's actually more legible to me,
in that the prototype (we still calling it that?)
get's less visual clutter.
In a related note, even if the 'is aka($am, $are,
$also_known_as) = 'Electric Mayhem')' syntax get's
establsihed will the alising trick still work? Or are
we stepping on the Perl 6 rule against leaking lexical
scopes?
-Erik
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
RE: First crack at Builtins.p6m
Aaron Sherman:
# Ok, so without knowing what the XS-replacement will look like
# and without knowing what we're doing with
# filehandle-functions (is tell() staying or does it get
# removed in favor of $fh.tell()) and a whole lot of other
I think that sort of thing is going. IIRC, the only built-in I/O thingy
that's staying is open().
# stuff it's impossible to translate all of the Perl 5
# functions to Perl 6. However, what I've done is take a quick
# stab at creating at least function signatures for everything
# that was in perlfunc and implemented some of the functions
# that do not require any external junk (e.g. reverse).
The one thing I notice all over the place is:
sub abs($num is int){ return $num>=0 ?? $num :: -$num }
^
I believe that should be (int $num).
push @newlist, $_ if &code(); # XXX - How does code get
$_?
It should be C. A closure that receives one argument and
doesn't have a signature gets that argument put into $_.
Overall, things look roughly correct. Well done.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
"In other words, it's the 'Blow up this Entire Planet and Possibly One
or Two Others We Noticed on our Way Out Here' operator."
--Damian Conway
