On Thu, 24 Oct 2002, Larry Wall wrote:
> It's possible the syntax for substitution should be wrapped around the syntax
> for matching, whatever that turns out to be.
That strikes me as promising...
Going back to Perl5 for a moment, we have
substr($str,$start,$len) = $newstr
why not simply ext
On Wednesday 23 October 2002 17:58, Luke Palmer wrote:
> > From: Adriano Nagelschmidt Rodrigues <[EMAIL PROTECTED]>
>> [...]
> > 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 overra
Steve Fink wrote:
On Oct-24, Leopold Toetsch wrote:
Thanks! It's a little scary how fast you are.
This depends on the RL work I've waiting to be done. The more is in the
queue (especially putting invoices together for the revenue office), the
more I'll code parrot stuff ;-)
leo
Steve Fink wrote:
On Oct-23, Leopold Toetsch wrote:
we could look at usage patterns and finally decide, what to do.
(Who could extend the assembler?)
Sounds good to me. But it does suggest a question -- are there any
compelling reasons to preserve the separate assembler?
Macros, currentl
Steve Fink wrote:
On Oct-24, Leopold Toetsch wrote:
... is there anything perl-specific about PerlInt?
PerlNum?
This depends. The PerlScalars change there types on demand.
add PerlInt, PerlInt, PerlNum
changes the type of the LHS to a PerlNum. Other languages might prefer
to round the
Attached is a test program showing some features, how a PMC could look
like in the future.
1)
PMCs/Buffer are both based on the same bufferlike structure - I called
it Pobj (Parrot Object)
- There is no need, that all PMCs are of same size, the bufferlike code
in smallobjects.c / headers.c take
Leopold Toetsch <[EMAIL PROTECTED]> writes:
[imcc...]
> >>>* Bytecode format
>
>
> > ... We could use existing ELF tools to, at the very least,
> > provide test result verification.
>
>
> This is an argument. If we get e.g. bsr fixup at load time done by the
> elf loader, it would be nice.
>
I was just having a look at the packfile format code, and I
have a suggestion on load-time performance of the code segment.
Currently, you read the file, parse out the various sections,
copy them elsewhere in memory, and byte-swap as necessary.
The overhead of doing this could be quite significant
On Thu, 2002-10-24 at 19:15, Robert Spier wrote:
>
> 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
> versio
On Thu, Oct 24, 2002 at 06:16:55PM -0400, Jason Gloudon wrote:
> On Thu, Oct 24, 2002 at 04:47:05PM -0400, Josh Wilmes wrote:
> > It shouldn't at all. It does the check once, when parrot starts up.
>
> It will. If you read the following paragraph I explained why it will be slower,
> and it has n
On Fri, Oct 25, 2002 at 07:55:45AM -0400, Bryan C. Warnock wrote:
> On Thu, 2002-10-24 at 19:15, Robert Spier wrote:
> > -R (pondering his next move in the unending war against spam)
>
> Nukes.
my thoughts entirely
> --
> Bryan C. Warnock
> bwarnock@(gtemail.net|raba.com)
When the spammers fig
On Fri, Oct 25, 2002 at 09:15:07PM +1000, Rhys Weatherley wrote:
> A "trick" that I've found very useful in the past is to design
> the bytecode format so that it can be mmap'ed into a block of
> memory, and then executed almost immediately with the minimum
> number of fixups. Rather than copying
I did ci 2 changes:
- headers.c was a little bit to drastic in stressing the system.
e.g. t/op/stacks_4 ran just out of mem after allocating 800K new_blocks.
- spf_vtable did use string_make (with BUFFER_external_FLAG) after my
patch, both are wrong. string_copy i.e. make a COW string - is the
At 12:30 PM -0700 10/25/02, Brent Dax wrote:
Dan Sugalski:
# I'm thinking something else, actually. Names made perfect sense
# except for encoding info and duplication. We can put limits on the
# name encoding if we want, but... really, who cares? It's only useful
# for introspection purposes and
At 9:15 PM +1000 10/25/02, Rhys Weatherley wrote:
I was just having a look at the packfile format code, and I
have a suggestion on load-time performance of the code segment.
Currently, you read the file, parse out the various sections,
copy them elsewhere in memory, and byte-swap as necessary.
Th
Brent Dax wrote:
Larry Wall:
# We're obviously missing the "force to string context, negate"
# operator. :-)
Which would create a superposition of all strings besides the given one,
right? (Oh crap, I think I gave Damian an idea... :^) )
The C<~none> operator covers that quite nicely:
$not_
On Fri, 25 Oct 2002, Michael Lazzaro wrote:
: What's the Official Perl difference between a named unary op and a
: one-arg universal method?
The Perl 5 definition of named unary op is an operator with the
precedence of UNIOP in perly.c.
: E.g. why are "temp" and "let" both ops but
: "my, our, h
On Fri, 25 Oct 2002, Michael Lazzaro wrote:
: What's the Official Perl difference between a named unary op and a
: one-arg universal method?
I didn't give the other half of the answer. A method is a term,
not an operator. It's the . in front of it that's the operator...
It's just that, in indi
So many operators...
It's now clear what we need. Unicode operators. That should buy us at
least another week to hash out the rest of the necessary operators. ;-)
It'd also silence the legions of critics who complain about Perl being
too easy to read if we, for instance, used the Kanji charac
On Fri, 25 Oct 2002, Chris Dutton wrote:
: So many operators...
:
: It's now clear what we need. Unicode operators. That should buy us at
: least another week to hash out the rest of the necessary operators. ;-)
:
: It'd also silence the legions of critics who complain about Perl being
: too
At 9:13 AM +1000 10/26/02, Rhys Weatherley wrote:
Dan Sugalski wrote:
># Instead, lets just give an entry number. We can have arbitrary data
># chunk #1, #2, #3, and so on. I'm not sure it'll buy us much having
># names attached.
>
>What happens if two tools (say, a custom debugger and the
Dan Sugalski:
# Huh? No, you misunderstand. Each chunk of the bytecode has a separate
# TOC for stuff like this. The full identifier would be
# file/chunk/entry, which should be reasonably guaranteed to be unique.
# When the compiler's emitting code to reference a piece of binary data
# (which
At 12:23 PM +0200 10/25/02, Juergen Boemmels wrote:
Leopold Toetsch <[EMAIL PROTECTED]> writes:
[imcc...]
>>>* Bytecode format
> ... We could use existing ELF tools to, at the very least,
> provide test result verification.
This is an argument. If we get e.g. bsr fixup at load time done
Leopold Toetsch wrote:
> Attached is a test program showing some features, how a PMC could look
> like in the future.
and where's the attachment?
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
Leopold Toetsch wrote:
Attached is a test program showing some features, how a PMC could look
like in the future.
Arg mozilla did show it.
On Oct-24, Leopold Toetsch wrote:
> 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
On Oct-24, Leopold Toetsch wrote:
> 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 p
At 5:28 PM +0200 10/24/02, Juergen Boemmels wrote:
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 ca
Dan Sugalski:
# I'm thinking something else, actually. Names made perfect sense
# except for encoding info and duplication. We can put limits on the
# name encoding if we want, but... really, who cares? It's only useful
# for introspection purposes and while that's certainly important, I'm
# no
On Fri, Oct 25, 2002 at 01:01:16PM +0100, Nicholas Clark wrote:
> What is wrong with any of
>
> 1: Duplicating the above loop (which isn't large), one for upwards stack,
>the other for downwards stack, and switching (outside) between the two
>based on an if statement on a global stack dir
Dan Sugalski wrote:
> ># Instead, lets just give an entry number. We can have arbitrary data
> ># chunk #1, #2, #3, and so on. I'm not sure it'll buy us much having
> ># names attached.
> >
> >What happens if two tools (say, a custom debugger and the Perl compiler)
> >both use the same segment num
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
> 'kay. As an aside, I've always itched for a qlike op that was
> matrix-like, e.g.
>
> my Pet @list = qm{
> fido dog collie
> fluffy cat siamese
> };
That should be qo, and possibly @qo or qoo -- it quotes an
On Friday, October 25, 2002, at 02:38 PM, Austin Hastings wrote:
In the manner of Accent, I'd like @ reserved as the RPC operator.
The Role Playing Character operator? Hmm, that has possibilities.
What would this statement do?
+--+
|..@...|
|d.|
|..|
+--+
MikeL
On Fri, Oct 25, 2002 at 01:00:59PM -0700, Larry Wall wrote:
> On Fri, 25 Oct 2002, Michael Lazzaro wrote:
> : binary operators:
> : + -*/%** x~<< >>
> : += -= *= /= %= **= x= ~= <<= >>=
>
> We could distinguish an xx operator (along with xx=)
From: "Larry Wall" <[EMAIL PROTECTED]>
> : ? - force to bool context
> : ! - force to bool context, negate
> : + - force to numeric context
> : - - force to numeric context, negate
> : ~ - force to string context
>
> We're obviously missing the "force to string co
Here's try #2. Things that are not true operators or have other
caveats are marked, where known. LMKA.
unary (prefix) operators:
\ - reference to
* - list flattening
? - force to bool context
! - force to bool context, negate
not - force to bool context, negate
On 25 Oct 2002, Marco Baringer wrote:
: Luke Palmer <[EMAIL PROTECTED]> writes:
: >But think of what macros in general provide:
: >
: > * Multi-platform compatability
: > * Easier maintenance
: * Creating/Embedding custom languages. aka - adapting the
Since it's been a full month since the start of the monster "operator
precedence" thread, here's what I've been able to gather as the
revised, new-and-improved list of Perl6 operators, IF we did all the
xor/cat/regex-related changes as discussed as of this moment. ;-) I
think this list is ac
Luke Palmer <[EMAIL PROTECTED]> writes:
> If you define "powerful" as "can do more things," then of course not.
> Lisp is implemented in C, and C's macros are certainly not essential
[aside: most "major" common lisp implementations (cmucl, sbcl,
openmcl, mcl, allegro and lispworks) are all native
Speaking about macros, I renember reading somewhere something about
Scheme hygenic macros, but i didn't really understood it.
Do they solve the maintenance problems of Lisp macros? Would they be
applicable to perl?
Thanks for any tips,
-angel
Angel Faus <[EMAIL PROTECTED]> writes:
> Speaking about macros, I renember reading somewhere something about
> Scheme hygenic macros, but i didn't really understood it.
>
> Do they solve the maintenance problems of Lisp macros? Would they be
> applicable to perl?
Scheme hygenic macros do a lot
On Fri, 25 Oct 2002, Michael Lazzaro wrote:
: Since it's been a full month since the start of the monster "operator
: precedence" thread, here's what I've been able to gather as the
: revised, new-and-improved list of Perl6 operators, IF we did all the
: xor/cat/regex-related changes as discusse
On Fri, Oct 25, 2002 at 11:27:54AM -0700, Michael Lazzaro wrote:
> &&||!!//- boolean operations
> &&= ||= !!= //=
> and orxor
Hmmm, given Larry's comments just now about about similar things not
looking similar, I really think | vs ! is a mistake. Fr
In the interest of email sanity, please make sure that neither Larry's
preferred : nor the more-common > are valid at statement start...
I'd hate to stumble across
: -> - like 'sub' ;
And run the risk of it compiling both as a quote and not.
=Austin
--- Larry Wall <[EMAIL PROTECTED]> wrote:
On Friday, October 25, 2002, at 01:00 PM, Larry Wall wrote:
Not clear how many of these are just universal or near-universal
methods.
Which would make some of them list-op variants, if we follow Perl 5
rules...
What's the Official Perl difference between a named unary op and a
one-arg univer
Excellent (and valuble) work Michael. Thank-you.
My turn for a few comments:
& | ! - superpositional
all any one (none?)
Although there certainly are good uses for a C superpositional:
push @list, $newval
if $newval eq none(@list);
print "In range\n"
On Fri, Oct 25, 2002 at 06:28:28PM -0400, Miko O'Sullivan wrote:
> From: "Larry Wall" <[EMAIL PROTECTED]>
> > : ? - force to bool context
> > : ! - force to bool context, negate
> > : + - force to numeric context
> > : - - force to numeric context, negate
> > : ~
Larry Wall:
# We're obviously missing the "force to string context, negate"
# operator. :-)
Which would create a superposition of all strings besides the given one,
right? (Oh crap, I think I gave Damian an idea... :^) )
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding reg
48 matches
Mail list logo
