On Sat, Aug 02, 2003 at 08:16:19PM -0700, Larry Wall wrote:
> On Sat, Aug 02, 2003 at 04:33:19PM -0700, Michael G Schwern wrote:
> : I'm not making an argument against %_, just noting that *_ is used
> : opportunisticly and you will break a few programs.
>
> Not necessarily. If Perl 6 were to us
> Larry Wall wrote:
> [snip]
> > Nope. $x and $p are syntax trees.
>
>
>
> Macros are passed syntax trees as arguments, but return coderefs?
>
> That's... odd.
>
> I would expect that a macro would be expected to *return* a syntax
> tree... which could then undergo (more) macro-expansion.
Ke
Thanks to schwern, a couple of glitches in my interpreter have (I think)
been fixed. updated version now replacing old version at
http://www.thetasigma.com/parrot/hq9p.pasm
dha
--
David H. Adler - <[EMAIL PROTECTED]> - http://www.panix.com/~dha/
"Perl Porters, Inc. today announced the release o
On Sat, Aug 02, 2003 at 10:29:05PM -0500, Abhijit A. Mahabal wrote:
: This is a rather silly question:
:
: The code:
: macro foo() { return {my $x = 7} }
: foo;
: print $x;
:
: is equivalent to which of the following?
:
: {my $x = 7}
: print $x;
:
: or
:
: m
On Sat, Aug 02, 2003 at 09:53:07PM -0600, John Williams wrote:
: Perl5 map and grep allow the first argument to be an expression which is
: passed to the function instead of being evaluated. (Sort of a bare block.)
: What does the signature for this look like? Is it done with "is parsed"
: tricks,
Perl5 map and grep allow the first argument to be an expression which is
passed to the function instead of being evaluated. (Sort of a bare block.)
What does the signature for this look like? Is it done with "is parsed"
tricks, or will perl6 require the "map BLOCK LIST" syntax?
I was recently bit
Larry Wall wrote:
[snip]
> Nope. $x and $p are syntax trees.
Macros are passed syntax trees as arguments, but return coderefs?
That's... odd.
I would expect that a macro would be expected to *return* a syntax
tree... which could then undergo (more) macro-expansion.
Sortof like how in lisp, a
On Sat, Aug 02, 2003 at 07:10:46PM -0600, Luke Palmer wrote:
: Yeah, I think so. It might be that the first C<@array[0] =
: "something"> is actually valid, and the only things that would be
: invalid would be calling mutating methods on the array itself (like
: C).
Maybe not even that restrictiv
This is a rather silly question:
The code:
macro foo() { return {my $x = 7} }
foo;
print $x;
is equivalent to which of the following?
{my $x = 7}
print $x;
or
my $x = 7;
print $x;
Thanx,
abhi.
Since I don't see anything to save/restore the instack on subroutine
calls, I am wondering what happens if a regex has a (?{ CODE }), and
that CODE calls a regex. Are we garunteed that after a regex completes
(either succeeds or fails) that the intstack is in the same state it
started? If not (a
On Sat, Aug 02, 2003 at 04:33:19PM -0700, Michael G Schwern wrote:
: I'm not making an argument against %_, just noting that *_ is used
: opportunisticly and you will break a few programs.
Not necessarily. If Perl 6 were to use %_ as parameter name, it
would be lexically scoped, and hide any pac
Benjamin Golberg writes:
> Actually, these are mostly questions about the string_str_index
> function.
Uh oh...
> I've some questions about bufstart, strstart, bufused, strlen and
> encoding->characters?
>
> In string_str_index_multibyte, the lastmatch variable is calculated as:
>
> const v
On Sun, Aug 03, 2003 at 01:37:16AM +0200, Abigail wrote:
> I am fond of doing
>
> local %_ = @_;
>
> as one of the first statements of a subroutine. That, or
>
> my %args = @_;
>
> I like the latter because it uses a lexical variable, but I like the
> former because %_ fits with @_ and
Actually, these are mostly questions about the string_str_index
function.
I've some questions about bufstart, strstart, bufused, strlen and
encoding->characters?
I *think* that ->characters is a fuction which gets passed a pointer to
the start of a buffer, and the number of bytes in the buffer,
> As I understand it, the comments in the following two subs are correct.
>
> sub foo (@array) {
> my $x = @array[0]; # ok, allowed to read
> @array[0] = "something"; # compile fails because '@array is ro'
> }
>
> sub bar (@array_2d) {
> my $x = @array[0]
> Damian Conway <[EMAIL PROTECTED]> writes:
> >Hence, making C<%_> mean something different in core Perl 5 might possibly be
> >"forwards incompatible".
Representing the Backwards Compatiblity Police, I've had co-workers use
%_ as the globalist of all global hashes. %_ transends all packages and
Damian Conway <[EMAIL PROTECTED]> writes:
>
> From a Perl 6 perspective, it seems likely that C<%_> will be the name
>commonly used for the "slurpy hash" of a subroutine. Just as C<@_> will often
>be the name used for the "slurpy array". See Exegesis 6 for more details.
>
>Indeed, when it comes t
"Jürgen" "Bömmels" (via RT) <[EMAIL PROTECTED]> writes:
> # New Ticket Created by Jürgen Bömmels
> # Please include the string: [perl #23203]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=23203 >
>
>
> Hello,
>
> this p
As I understand it, the comments in the following two subs are correct.
sub foo (@array) {
my $x = @array[0]; # ok, allowed to read
@array[0] = "something"; # compile fails because '@array is ro'
}
sub bar (@array_2d) {
my $x = @array[0]; # ok, allo
On Sat, Aug 02, 2003 at 01:18:01PM -0600, Luke Palmer wrote:
: While we seem to be on the subject of hashing out macro semantics,
: here's a question I've had awhile.
:
: What do macros do about being passed variables?
:
: Let's say I make a C macro:
:
: macro square ($x) {
: { $x *
While we seem to be on the subject of hashing out macro semantics,
here's a question I've had awhile.
What do macros do about being passed variables?
Let's say I make a C macro:
macro square ($x) {
{ $x * $x }
}
And then I have code.
my $var = 10;
print square $var;
Do
--- chromatic <[EMAIL PROTECTED]> wrote:
> On Friday, August 1, 2003, at 05:03 PM, Michael G Schwern wrote:
>
> > Ooooh! I just had a great idea. Use "TEST { ... }" instead of "TEST:
> > { ... }"
> > in Test::AtRuntime.
>
> Could these instead be subroutine attributes? I can see a lot of
> ad
I cited this out of subs.pod:
"Parrot comes with different subroutine and alike classes which implement
CPS (Continuation Passing Style) and PCC (Parrot Calling Conventions)
F."
I don't get this. Could anybody rephrase it for me?
Later:
=head2 Items in the Subs Context
Subtype Controlstack
On Friday, August 1, 2003, at 05:03 PM, Michael G Schwern wrote:
Ooooh! I just had a great idea. Use "TEST { ... }" instead of "TEST:
{ ... }"
in Test::AtRuntime. If the user has Filter::Simple, use that to strip
out
the TEST blocks. Otherwise, its a function call to TEST() passing in
a cod
On Sat, Aug 02, 2003 at 08:40:26AM -0700, Austin Hastings wrote:
: You're both right.
Well, actually, I think Damian misspoke slightly. I only aim for
95% accuracy in the Apocalypses (or I'd never get them done). So I
think it's pretty spectacular if Damian gets to 99.44% accuracy in
the Exegese
i'm beginning to explore the concept of embedding parrot so i can
eventually add Perl 6 support to extproc_perl (embeds perl in oracle).
i was talking with dan at OSCON a few weeks ago about accessing data from
an embedded parrot interpreter, and i know he is probably moving it up in
his priority l
On Saturday, August 2, 2003, at 01:03 am, Michael G Schwern wrote:
Class::Contract has always bothered me as way too much Kool-Aid to
drink in one sitting.
I completely agree. Having the ability to apply pre/post/invariant
functionality to normal Perl classes has been on my to do list for
years
--- "Abhijit A. Mahabal" <[EMAIL PROTECTED]> wrote:
> In E6 Damien writes about macros:
>
> "As soon as it has parsed that subroutine call (including its
> argument
> list) it will detect that the subroutine &request is actually a
> macro, so
> it will immidiately call &request with the specified
In E6 Damien writes about macros:
"As soon as it has parsed that subroutine call (including its argument
list) it will detect that the subroutine &request is actually a macro, so
it will immidiately call &request with the specified arguments".
If macroness is found *after* parsing the arguments,
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #23203]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=23203 >
Hello,
this patch lies in my tree for month now, finally I got around to
finish it up
On Sat, Aug 02, 2003 at 10:35:56AM +0100, Nicholas Clark wrote:
> On Sat, Aug 02, 2003 at 01:49:05AM -0400, David H. Adler wrote:
> > I'm sure it needs a few tweaks, but I've managed to write a hq9+
> > interpreter in pasm.
>
> > Any thoughts on this?
>
> + isn't a portable file name character is
On Sat, Aug 02, 2003 at 01:49:05AM -0400, David H. Adler wrote:
> I'm sure it needs a few tweaks, but I've managed to write a hq9+
> interpreter in pasm.
> Any thoughts on this?
+ isn't a portable file name character is it?
So although Unix (and CVS) will be quite happy, it would not be a great
i
Kenneth Graves wrote:
From: Leopold Toetsch <[EMAIL PROTECTED]>
[ optimized register allocation ]
Is there a stub of this functionality in the code somewhere?
(Or some notes about how it might be approached?)
No, not yet. Currently local variables (and parameters if a sub calls
another sub)
The following changes regarding the PIR assembler inside parrot/imcc
will be done in the next weeks:
1) All code outside of compilation units will be ignored
2) This also implies that nested subroutines are not supported anymore.
I did implement both features and I have to admit, that this was an
http://www.pobox.com/~schwern/src/Test-AtRuntime-0.02.tar.gz
or a CPAN near you.
Still a few small bugs and missing features, but the important things work.
See the TODO and CAVEATS for details. Now works with 5.6.0!
NAME
Test::AtRuntime - Put tests in your code and run them as
yo
On Fri, Aug 01, 2003 at 11:02:19PM -, Rafael Garcia-Suarez wrote:
> Michael G Schwern wrote in perl.qa :
> > The only part missing is the ability to shut the tests off once you've
> > released it to production.
>
> You could perhaps use the assertion feature of perl >= 5.9.0
> (assertion.pm an
On Sat, Aug 02, 2003 at 12:09:22AM +0100, Adrian Howard wrote:
> - Rather than running tests at live time, I'm more often doing the
> opposite. I have assertions that I only want to switch on at testing
> time since that is when I'm exercising things that might break.
>
> - This sort of
37 matches
Mail list logo
