Dan Brian writes:
> If there's a willingness to rename shift/unshift, why not consider
> going a bit further (and offend shell heritage) to note that pull/put
> aren't really linguistically opposed either (unlike push/pull). Why not
> rename pop to pull, and use something like put/take for shift
Bernhard Schmalhofer (via RT) wrote:
Hi,
this patch adds support for dynamic evaluation of 'Parrot abstract syntax
tree As Simple Text'. This was done be implementing the C-function
'ast_compile_past'.
Great, thanks.
Simple examples for dynamic executable PAST are in t/pmc/eval.t. The
toplevel node
Given a multi sub declaration a la S13:
multi sub *infix:<-> (MyInt $left, int $right) {mysub($left, $right)}
multi sub *infix:<-> (int $left, MyInt $right) {myrsub($right, $left)}
The first one would create a MMD function variant of
sub_p_p_ior Pleft."sub"(Iright, Pdest)
o
On Thursday, December 2, 2004, 10:08:31 AM, you
(mailto:[EMAIL PROTECTED]) wrote:
> On Tue, 30 Nov 2004, Austin Hastings wrote:
>> How about just having C< system() > return a clever object with .output and
>> .err methods?
> interesting...
> Michele
Prior art of this on Windows...
http:/
General thoughts on the proposal to replace VTABLES with methods:
1) Anything that is unary (i.e., contains exactly or one argument) is
not affected by MMD. There is no need to replace any such methods.
2) While I don't see Python translators using a "sin" opcode, I can see
the implementation o
This term came up in a recent discussion[1]. But I'd like to give this
term a second meaning.
During design considerations we (including me of course too) tend to
discard or pessimize ideas early, because they look inefficient. Recent
examples are e.g.
- spilling
- lexical (re-)fetching
- metho
A cache, well caches things and speeds something up, and can be
considered as an optimization. OTOH, knowing that things can be
reasoable fast, can open the mind for possible solutions that would
otherwise be silently discarded as known to be slow.
I'm not proposing the usage of inline caching
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #32868]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32868 >
Hi,
this patch adds a target 'help' to 'parrot/docs/Makefile'. A list of
ava
Sam Ruby <[EMAIL PROTECTED]> wrote:
> General thoughts on the proposal to replace VTABLES with methods:
> 1) Anything that is unary (i.e., contains exactly or one argument) is
> not affected by MMD.
That's not quite true. We currently have just infix MMD dispatching on
left and right. That's just
Thanks, applied.
Bernhard Schmalhofer (via RT) wrote:
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #32868]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32868 >
Hi,
this patch adds a ta
Larry Wall wrote:
<>On Sat, Dec 04, 2004 at 08:55:00PM -0600, Rod Adams wrote:
: $x ==<$foo>; # $x == <$foo>; $x = =<$foo>;
: @x <==<$foo>; # @x <= =<$foo>; @x <== <$foo>;
: $x//=<$foo>; # $x // =<$foo>; $x //= <$foo>;
: [EMAIL PROTECTED]; # $x ** [EMAIL PROTECTED]; $x **= @y;
In each of those c
Can we get a ruling on this? I tend to agree with the statement "Random build
files do not
belong in the root directory".
The patch has been un-ACK'd for nine months at the moment.
> [EMAIL PROTECTED] - Tue Mar 02 03:49:32 2004]:
>
> Steps:
> (1) move ./libnci.def to ./src/libnci.def
> (2)
> "RA" == Rod Adams <[EMAIL PROTECTED]> writes:
RA> Brent 'Dax' Royal-Gordon wrote:
>> Smylers <[EMAIL PROTECTED]> wrote:
>>
>>> Yes. C is a terrible name; when teaching Perl I feel
>>> embarrassed on introducing it.
>>>
>>
>> C's only virtue, IMHO, is that it's clearly th
On Sun, Dec 05, 2004 at 10:02:16AM -0600, Rod Adams wrote:
> Although I by no means dispute that longest token rule is a long term
> standard in language design, I will claim that many programmers,
> including myself before this, are unaware of it.
Programmers tend to follow the rule even when t
If there's a willingness to rename shift/unshift, why not consider
going a bit further (and offend shell heritage) to note that pull/put
aren't really linguistically opposed either (unlike push/pull). Why
not
rename pop to pull, and use something like put/take for shift/unshift?
That goes way beyo
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Matt Fowles <[EMAIL PROTECTED]> wrote:
>
>> Thanks for the clear explanation. I did not realize that S registers
>> could switch pointers, that does make things a little harder. I have
>> a recommendation for a possible hybrid solution. Incur the co
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #32877]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32877 >
I am pretty certain that parrot was building fine in Tru64 back in
2004/11/07 15
Dan Brian writes:
> Having push and pull operate on opposite ends of an array strikes me
> as more confusing than even shift.
It makes good sense to me -- if we're trying to move a piano from you to
me then either you can push or your end or I can pull on my end: we're
operating on different ends
Larry Wall writes:
> But pretty much every time I've introduced synonyms into Perl I've
> come to regret it. But hey, if I introduce *different* synonyms this
> time, does that count as making a new mistake?
No! Avoid synonyms. They're initially tempting, because then everybody
gets to pick th
The repositories for Test-Simple and ExtUtils-MakeMaker [1] have moved to
svn.schwern.org. [2]
Web & DAV http://svn.schwern.org/svn/CPAN/
Anon SVNsvn://svn.schwern.org/CPAN/
WebSVN http://svn.schwern.org/websvn/
The web address might change to cut out the svn bit, I dunno. And it migh
Luke Palmer <[EMAIL PROTECTED]> writes:
> Piers Cawley writes:
>> I'd submit that, in the vast majority of cases you're not going to be
>> dealing with full continuations, and on the occasions when you are the
>> programmer using them will be aware of the cost and will be willing to
>> pay it.
>
>
On Dec-01, Dan Sugalski wrote:
>
> C, for example, is weakly typed. That is, while you tell the system
> that a variable is one thing or another (an int, or a float), you're
> perfectly welcome to treat it as another type. This is *especially*
> true of values you get to via pointers. For examp
Leopold Toetsch writes:
> This term came up in a recent discussion[1]. But I'd like to give this
> term a second meaning.
Except what you're talking about here is premature *optimzation*.
You're expecting certain forms of the opcodes to be slow (that's the
pessimization part), but then you're acut
On Sun, 5 Dec 2004 11:46:24 -0700, Luke Palmer <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch writes:
> > This term came up in a recent discussion[1]. But I'd like to give this
> > term a second meaning.
>
> Except what you're talking about here is premature *optimzation*.
Yes, indeed.
Cheers,
Mich
Piers Cawley writes:
> I'd submit that, in the vast majority of cases you're not going to be
> dealing with full continuations, and on the occasions when you are the
> programmer using them will be aware of the cost and will be willing to
> pay it.
Yeah probably. Except the problem isn't the cost
On Sun, 5 Dec 2004 11:46:24 -0700, Luke Palmer <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch writes:
> > This term came up in a recent discussion[1]. But I'd like to give this
> > term a second meaning.
>
> Except what you're talking about here is premature *optimzation*.
> You're expecting certain
can you unsubscribe me asap
rgds
venkat
-Original Message-
From: Ashley Winters [mailto:[EMAIL PROTECTED]
Sent: Monday, December 06, 2004 7:19 AM
To: Luke Palmer
Cc: Leopold Toetsch; Perl 6 Internals
Subject: Re: Premature pessimization
On Sun, 5 Dec 2004 11:46:24 -0700, Luke Palmer <[E
On 2004-12-02, Andy Lester <[EMAIL PROTECTED]> wrote:
> I've reorganized all the trees in http://svn.perl.org/phalanx. A
> description of how things should be is at
> http://svn.perl.org/phalanx/structure.pod.
I think I missed something. This clearly has something to do with SVN
hosting and the P
On Mon, Dec 06, 2004 at 02:27:47AM +, Mark Stosberg ([EMAIL PROTECTED])
wrote:
> On 2004-12-02, Andy Lester <[EMAIL PROTECTED]> wrote:
> > I've reorganized all the trees in http://svn.perl.org/phalanx. A
> > description of how things should be is at
> > http://svn.perl.org/phalanx/structure.p
It makes good sense to me -- if we're trying to move a piano from you
to
me then either you can push or your end or I can pull on my end: we're
operating on different ends of it, but the effect in both cases is
moving in one direction.
As a mnemonic for remembering which side push/pull operate on,
30 matches
Mail list logo
