On Tuesday 16 January 2007 16:56, Isaac Freeman wrote:
\
> So, for my purposes I need an embedding interface that allows for more
> control of the interpretter, e.g. the ability to inspect/modify
> namespace(s) and eventually control which opcodes are allowed, or
> register callbacks for opcodes (i
i never officially closed the repo to commits, but for those of you
awaiting parrot's release, it's now complete. you may commit freely.
thanks for your patience.
~jerry
On behalf of the Parrot team, I'm proud to announce Parrot 0.4.8,
"Eponymous." Parrot (http://parrotcode.org) is a virtual machine aimed
at running all dynamic languages.
You may now grab Parrot 0.4.8 from the CPAN.
Parrot 0.4.8 News:
- Compilers:
+ HLLCompiler: added tracing options, modified
So, for my purposes I need an embedding interface that allows for more
control of the interpretter, e.g. the ability to inspect/modify
namespace(s) and eventually control which opcodes are allowed, or
register callbacks for opcodes (i.e. file access, etc) for security
purposes.
Tackling the first
# New Ticket Created by Allison Randal
# Please include the string: [perl #41280]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41280 >
larry's most recent change to S05 (more)
looks like I'll need the ability to attach
Attached patch adds new syntax documentation to docs/imcc/syntax.pod and
fixes some typos there. It now also indicates where various flags are
explained.
Is the shorthand syntax for function calls ("($P0, a :slurpy) = foo(3, b
:flat)") clear, or can we better use examples there?
-- bgeron
Index:
Luke Palmer wrote:
Seems reasonable. My generality alarm goes off when I realize that
you can't specify commutativity for two of the three args, but that's
fine because it's definitely a cpanable feature.
IIRC, it's possible to embed one signature within another one; if the
embedded signature
Author: larry
Date: Tue Jan 16 13:42:34 2007
New Revision: 13525
Modified:
doc/trunk/design/syn/S05.pod
Log:
Clarification of relationship of hash keys to constant prefix processing.
Modified: doc/trunk/design/syn/S05.pod
==
On 1/16/07, Dave Whipp <[EMAIL PROTECTED]> wrote:
Synopsys 13 mentions an "is commutative" trait in its discussion of
operator overloading syntax:
> Binary operators may be declared as commutative:
>
>multi sub infix:<+> (Us $us, Them $them) is commutative {
>myadd($us,$them) }
Author: larry
Date: Tue Jan 16 13:27:58 2007
New Revision: 13524
Modified:
doc/trunk/design/syn/S05.pod
Log:
As suggested by pmichaud++, also split C<&> into C<&> and C<&&>,
with only the latter guaranteeing order.
Modified: doc/trunk/design/syn/S05.pod
==
On Tue, Jan 16, 2007 at 02:05:44PM -0600, Patrick R. Michaud wrote:
: On Tue, Jan 16, 2007 at 10:41:03AM -0800, Larry Wall wrote:
: > Note, in case you don't read synopsis checkins: the previous checkin
: > majorly changes the semantics of | within regex to support required
: > longest-token matchi
On Tue, Jan 16, 2007 at 10:41:03AM -0800, Larry Wall wrote:
> Note, in case you don't read synopsis checkins: the previous checkin
> majorly changes the semantics of | within regex to support required
> longest-token matching semantics rather than left-to-right matching.
> This is nearly on the sam
Synopsys 13 mentions an "is commutative" trait in its discussion of
operator overloading syntax:
> Binary operators may be declared as commutative:
>
>multi sub infix:<+> (Us $us, Them $them) is commutative {
>myadd($us,$them) }
A few questions:
Is this restricted to only binary op
Note, in case you don't read synopsis checkins: the previous checkin
majorly changes the semantics of | within regex to support required
longest-token matching semantics rather than left-to-right matching.
This is nearly on the same philosophical level as requiring the
tail-recursion optimization.
Author: larry
Date: Tue Jan 16 11:09:42 2007
New Revision: 13523
Modified:
doc/trunk/design/syn/S05.pod
Log:
Tweak | to provide longest-token instead of short-circuit semantics.
Now use || for old short-circuit semantics!
Modified: doc/trunk/design/syn/S05.pod
===
HaloO,
Jonathan Lang wrote:
Agreed. My only doubt at this point is which definition should be the
default. Do we go with "mathematically elegant" (E) or "industry
standard" (F, I think)?
I think industry (language) standard is undefined behavior ;)
I'm kind of waiting for an answer what fea
TSa wrote:
My list was sorted in decreasing order of importance with the
F-definition beating the E-definition in popularity. So all I want is
use Math::DivMod:euclid;
to get the E-definition and a
use Math::DivMod;
to get them all. The F-definition being the default when no import is
HaloO,
Smylers wrote:
That depends on exactly what you mean by "we" and "need".
Well, with "we" I meant the Perl 6 language list and "need"
is driven by the observation that we can't agree on a single
definition, so picking your personal favorite should be
possible.
By all means have them a
18 matches
Mail list logo
