On Thu, 24 Oct 2002, Damian Conway wrote:
: Adam D. Lopresto wrote:
:
: > Really what I've been wishing for was an operator (or whatever) to let me do an
: > s// without changing the variable.
:
: I would hope/expect that that's what the subroutine form of C would do.
The problem with defining t
Steve Fink wrote:
... If not, then just
renaming it to Undef seems best.
I had a closer look at it. Just renaming doesn't: PerlUndef is derived
from PerlInt, which provides major funtionality for it.
If this syllable "Perl" is really a problem, I will reorganize them
again i a more hierar
On Thu, Oct 24, 2002 at 12:26:41PM -0300, Adriano Nagelschmidt Rodrigues wrote:
> Luke Palmer writes:
> > Lisp is implemented in C, and C's macros are certainly not essential
> > to its functionality. But think of what macros in general provide:
> >
> > * Multi-platform compatability
> >
On Fri, 25 Oct 2002, Martin D Kealey wrote:
: Going back to Perl5 for a moment, we have
:
: substr($str,$start,$len) = $newstr
:
: why not simply extend pattern-matching in a similar way to substr, making it
: an L-value, so that one gets
:
: $str ~ /[aeiou]+/ = "vowels($&)"
:
: or
:
: $
On Thu, 24 Oct 2002, Leopold Toetsch wrote:
> Andy Dougherty wrote:
>
> > Types:
> > iv=long long, intvalsize=8, intsize=4, opcode_t=long long, opcode_t_size=8,
> > ptrsize=4, ptr_alignment=4 byteorder=87654321,
> The INTVAL2PTR and PTR2INTVAL macros should take care of such a
> con
On Wed, 23 Oct 2002, Erik Lechak wrote:
Anyways, I am on Win XP using VC++. I look in Config.pm and I see this
'#define PARROT_STACK_DIR'. It's not defined to anything, but the code
tries to do math with it. What is this?
This could well be my fault. I recently changed that test. But looki
Jürgen Bömmels (via RT) wrote:
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #18072]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18072 >
A PackFile created with a diffrent version of core.op
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #18078]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18078 >
Ken,
The already downloaded the new list so just tell Patty to start sending. They
On Wed, Oct 23, 2002 at 11:23:26PM -0400, Josh Wilmes wrote:
> I've got a patch which switches this detection to happen at run-time
> instead of at build-time. This is going to be necessary for miniparrot
> (which has no "Configure" step) anyway.
Have you checked how much this affects the per
Dan Sugalski <[EMAIL PROTECTED]> writes:
> >The ability to embed arbitrary data in a pbc file under a
> >named section. This data needs to be readable by the program
> >when it runs, but is otherwise ignored by the rest of Parrot.
>
> Right, good call. This'll make perl's named embedded filehand
At 11:57 on 10/24/2002 EDT, Jason Gloudon <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 23, 2002 at 11:23:26PM -0400, Josh Wilmes wrote:
>
> > I've got a patch which switches this detection to happen at run-time
> > instead of at build-time. This is going to be necessary for miniparrot
> > (which
On Thu, Oct 24, 2002 at 04:47:05PM -0400, Josh Wilmes wrote:
> > > I've got a patch which switches this detection to happen at run-time
> > > instead of at build-time. This is going to be necessary for miniparrot
> > > (which has no "Configure" step) anyway.
> >
> > Have you checked how much
Obviously spam, sorry folks.
It snuck in under the spam filters.
X-Spam-Status: No, hits=5.3 required=7.0
tests=CARRIAGE_RETURNS,FORGED_HOTMAIL_RCVD,MISSING_HEADERS,NORMAL_HTTP_TO_IP,NO_REAL_NAME,SPAM_PHRASE_00_01,TO_EMPTY
version=2.41
-R (pondering his next move in the unending war against spa
At 18:16 on 10/24/2002 EDT, Jason Gloudon <[EMAIL PROTECTED]> wrote:
> STACK_DIR is a compile time constant, so the multiplies in the following code
> are eliminated by the compiler if it does any optimization. By making
> STACK_DIR a variable, the compiler is no longer able to do this and has t
On Oct-23, Leopold Toetsch wrote:
> Steve Fink wrote:
>
> >I suppose I ought to try to wrap up a release one of these days.
>
>
> > - Artificial goal: I want the list of pending patches to be smaller
> >than one screenfull before I release. Fortunately, I have a large
> >screen.
>
> I
Dan Sugalski wrote:
At 4:57 PM +0200 10/19/02, Leopold Toetsch wrote:
[ Vtable union ]
Well... the problem is with references. Larry's declared that a
reference must act identically to its referent if used in the right
context. We could force an explicit deref, but I'd rather not. Treatin
Andy Dougherty wrote:
Types:
iv=long long, intvalsize=8, intsize=4, opcode_t=long long, opcode_t_size=8,
ptrsize=4, ptr_alignment=4 byteorder=87654321,
The INTVAL2PTR and PTR2INTVAL macros should take care of such a
configuration. Though I'm not to sure, if we can get rid of all th
Steve Fink wrote:
Prerequisites for 0.0.9 release
---
* Reclaim the tinderbox!
On one machine I suddenly have additionally:
Failed Test Status Wstat Total Fail Failed List of failed
---
Steve Fink wrote:
- the various unions should probably be coalesced into one
I did check in my datatypes patch.
- all? native and other data types are summarized in datatypes.h
- hash and list use the same enums now
- datatype.c has currently 2 functions to retrieve types per name/enum
(con
Steve Fink wrote:
On Oct-23, Dan Sugalski wrote:
It'd probably be a good idea for us to have a generic undef.pmc for
undefined usage.
Yes, that's what I was saying. Sorry the comment was vague -- all I
meant was that general Parrot PMCs should not be creating
Perl-specific PMCs. I agree co
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #18072]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18072 >
A PackFile created with a diffrent version of core.ops leads to
strange not easy to fi
Really what I've been wishing for was an operator (or whatever) to let me do an
s// without changing the variable.
print 'He said "'_($statement ~ s/\.$//)_'," but we didn't believe him.';
I'm not sure exactly what the semantics would be, but somehow =~ without the =
seems appealing...it's always
Damian Conway wrote:
>I certainly wouldn't mind seeing it return to that role, now that
>it's not needed elsewhere. And, of course, that would actually be:
>
> $x ~ $y string concatentation
> $x ~= $ystring append
> ~$x stringification
> ...
> $st
Larry,
As long as you're trying to figure out how to shoehorn in the last few
available punctuation symbols, and thinking about if there are any
bracketers left, I wondered if there was a chance of a chunking operator
for literate programming? So you can do something like this, if <<<>>>
were the
On Thursday, October 24, 2002, at 11:22 AM, Larry Wall wrote:
But we also have to balance it against the desirability of using ~ for
concatenation. Requiring whitespace around _ is a bit of a
rationalization
after the fact, and ~ escapes that problem in most cases.
So (w/out whitespaces):
On Thu, 24 Oct 2002, Chris Dutton wrote:
: Also, this brings to mind the one thing I actually remember about
: Sather, and as long as we're discussing operators...
:
: Will we have similar to Sather's "::="? That was essentially the
: "statically type this variable at run-time based on the type
Larry Wall wrote:
> On 20 Oct 2002, Smylers wrote:
>
> : Seems like not too long ago we were short of punctuation symbols,
> : and now you've got a spare one lying around.
>
> Pity there's no extra brackets lying around without going to
> Unicode...
Well if C<~> were made the hyper prefix (squi
On Thursday, October 24, 2002, at 10:34 AM, Larry Wall wrote:
On the other hand, the current rule for recognizing the *end* of a
name in the style of operator:=+ is to go till the next whitespace,
on the assumption that we'll never have (shudder) whitespace operators.
Oooh, I nominate whitespa
> From: Angel Faus <[EMAIL PROTECTED]>
> Date: Fri, 25 Oct 2002 00:54:09 +0200
>
> All this ones fit more with the concept of "mystical analogy" hinted
> by =~ than with the plain similarity that one would expect from
> "like"
True. Can't say I like, um, like.
> Oh, and =~ looks much more inti
Or we could go with Valspeak:
$a is like $b and stuff
At the moment I like "like" the best, actually...
Hmmm... I could actually see "like" in a more active role. Along the
lines of:
my str $string;
my $other_string is like $string;
Analogous to saying:
my str $other_string
Except th
>
> At the moment I like "like" the best, actually...
>
"like" is beautiful for old-style regex matching, but I find it
confusing for the new smart abilities:
$varlike Class:Foo # $var is instance of Class:Foo
$item like %hash # %hash{$item} is true
$digit like (0..10)
Brent Dax wrote:
Can the new nefarious use be concat? Pretty please?
On Wednesday, October 23, 2002, at 07:46 PM, Damian Conway wrote:
I guess the only concern is the potential for nasty surprises between:
$str =~ s/a/b/; substitute a for b in $str
and:
$str ~= s/a/b/; substitute a
Luke Palmer writes:
> > Do you think that Lisp macros make the language more powerful than
> > others (eg Perl)? I mean, do they really give a competitive
> > advantage, or are they being overrated (see below)?
>
> If you define "powerful" as "can do more things," then of course not.
No, of cours
On Thu, 24 Oct 2002, Michael Lazzaro wrote:
:$str1 ~ $str2# $str1 =~ m/$str2/
That would be a smart match, not m/$str2/.
:$str ~ /foo/ # $str1 =~ m/foo/
That would work.
:$str2 = ($str ~ /foo/bar/); # perform subst, assign result to $str2
:
:$st
On Thu, 24 Oct 2002, fearcadi wrote:
: Maybe , my question really is , how perl will behave if I will do
:
: sub operator:=+ (str $x, str $y) { system( "$x | $y" ) } ;
:
: so this is more question of qrammar ?
The general rule in most lexers has always been that it grabs the
longest token it can
On Thu, 24 Oct 2002, Deborah Ariel Pickett wrote:
: Which looks better?
: if ($a == 1|2|3 || $b eq "x"|"y"|"z")
: or
: if ($a == 1||2||3 | $b eq "x"||"y"||"z")
: ?
I think disjunctions of data values should be | and disjunctions of expressions
should be ||, so that the "bigger" concept has the
On Thu, Oct 24, 2002 at 09:59:00AM -0700, Michael Lazzaro wrote:
> Noone ever guesses that =~ means "matching"
That's because it doesn't. =~ means something more akin to "apply"
but it's only valid for the three m//, s///, tr/// ops. That'll
change in perl 6 though :-)
> If anything, I'd almos
In 'C', we have:
a = b+c;
In Perl, we can have:
$a = $b$c;
(Parseable as $a = $b operator:spacespace operator:tab
operator:spacespace $c;)
Oh frabjous day!
=Austin
--- David Wheeler <[EMAIL PROTECTED]> wrote:
> On Thursday, October 24, 2002, at 10:34 AM, Larry Wall wrote:
>
>
On Thursday, October 24, 2002, at 02:52 PM, Austin Hastings wrote:
In 'C', we have:
a = b+c;
In Perl, we can have:
$a = $b$c;
(Parseable as $a = $b operator:spacespace operator:tab
operator:spacespace $c;)
Oh frabjous day!
Good Lord, you're sicker than I am!
:-D
David
--
D
Um, I don't know about your mail program, but mine
converts
operator:tab
to
operator:spacespace operator:spacespace
Anyone for makefiles?
> -Original Message-
> From: David Wheeler [mailto:david@;wheeler.net]
> Sent: Thursday, October 24, 2002 5:59 PM
> To: [EMAIL PRO
40 matches
Mail list logo
