ly
fork a separate "docs/AES/S29draft.pod" as "docs/AES/S29working.pod" so
that others can actively collaborate rather than just waiting for a
final product, and replace the draft once it's actually in a consistent
state. Otherwise, I'd have to muck around with branch
On Wed, 2005-10-19 at 16:07, Aaron Sherman wrote:
> I thus propose 2005-03-16 (last Rod Adams update) - 2005-10-17
> (yesterday, yes that's arbitrary) on the mailing list and pugs/ext from
> svn as of revision 7682 as the inputs for the next revision of S29
s{pugs/ext}{pugs/t/bui
ctors, but I don't think those get to get called
until everything goes away (since there's a reference chain between
them).
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
On Tue, 2005-11-15 at 12:30, Luke Palmer wrote:
> On 11/15/05, Aaron Sherman <[EMAIL PROTECTED]> wrote:
> > This question came out of a joking comment on IRC, but it's a serious
> > concern. Can chained buts be optimized, or must the compiler strictly
> > create i
Larry (bless his wire-photographing heart) took the time to re-vamp S29.
Of course, this threw off all of my collating of S29, but that's fine
since he's actually answered more of my questions than I could have
hoped.
The fourth of July weekend was fairly slow for me, so I started with
Larry's S29
On Wed, 2006-07-05 at 16:09 -0400, Aaron Sherman wrote:
> The fourth of July weekend was fairly slow for me, so I started with
> Larry's S29 and went forward.
>
> My first pass at a revised S29 is attached.
I already see one problem. "as" slipped in, which is
The special directive, C<%n> does not work in Perl 6 because of the
difference in parameter passing conventions, but the example above
simulates its effect using C<%C>.
=cut
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"We had some good machines, but they don't work no more." -Shriekback
want to talk to a less officially
blessed language:
use Lang::Bash::Loader;
use Lang::Elisp::Loader;
bashuse "~/.bashrc";
elispuse "hanoi";
say %*ENV{PATH}
hanoi(13);
Inventing syntactic sugar for the back-end case probably doesn't buy
ltidimensional, C operates only on the first
dimension, and works with Array References.
=item unshift
our Int multi Array::unshift ( @array is rw, [EMAIL PROTECTED] )
our Int multi method Array::unshift ( @array: [EMAIL PROTECTED] )
C adds the values onto the start of the C<@array>.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"We had some good machines, but they don't work no more." -Shriekback
I've gathered my ducks in a row, used the feedback that I've gotten so
far, and I think I'm ready to officially update S29. For that I need two
things:
1) I'd really like Larry to glance over the changes and $s29.bless but
all comments are welcome
2) I'll need commit rights to whatever reposit
Darren Duncan wrote:
At 8:32 PM -0400 7/8/06, Joe Gottman wrote:
I have one minor comment about join. You should specify its behavior
when
it is passed an empty list. Does it return undef or the empty string?
I think it makes the most sense for it to return an empty string,
which is a reas
ition for each of these
functions into the section for each type of container (too many
eaches...). I don't even have a section for things like Seq and Buf yet,
and I'd rather not if I don't have to.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsm
On Tue, 2006-07-11 at 10:06 -0400, Aaron Sherman wrote:
> For example:
>
> our List multi Container::each(Container [EMAIL PROTECTED])
In thinking about each, I've come across an interesting need. I wrote
this example:
for each(=<>; 1..*) -> ($line, $lineno) {
behavior. Something like, "class Buf is Scalar, does
Container". Which really blows some assumptions that I'm willing to bet
many people will make.
--
Aaron Sherman <[EMAIL PROTECTED]>
On Tue, 2006-07-11 at 09:53 -0700, Trey Harris wrote:
> In a message dated Tue, 11 Jul 2006, Aaron Sherman writes:
> > But would it be reasonable to also provide a named-only parameter to
> > each for that purpose?
> It sounds reasonable to me, but :stop reads badly. Maybe C<
m still not clear on how :fewest and :most modify a container, but I'm
convinced that once I make sense of it, there will be other ways in
which I want to use that modifier.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"We had some good machines, but they don't work no more." -Shriekback
On Tue, 2006-07-11 at 16:22 -0400, Aaron Sherman wrote:
> zip(:fewest, @a;@b;@c); # Until one runs out
Once again, I missed some Larry magic. He already selected ":shortest"
for this, so I guess on roundrobin, it's ":longest"... ignore my
choices.
I think just
o feel out where the line between S29 and that document
are There's some overlap, but I want to keep it minimal.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"We had some good machines, but they don't work no more." -Shriekback
Smylers wrote:
[EMAIL PROTECTED] commits:
New Revision: 10077
Modified: doc/trunk/design/syn/S02.pod
==
-foo.bar # foo().bar -- postfix prevents args
+foo.bar# foo().bar -- illegal postfix
y for all the lame questions! I'm just trying to make
sure that the docs I write aren't utterly, worthlessly wrong. :-/
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"We had some good machines, but they don't work no more." -Shriekback
.
In fact, I would expect that this bit of behind-the-curtain magic is how
the MCP arranges for polymorphism when you:
sub foo(Object $x) {...}
my A $y;
foo($y);
Is all of that fair?
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"We had some good ma
:= $b.buf;
return $bufa >>===<< $bufb;
}
our Bool multi infix:<==> ( Int $a, Int $b ) {
return $a === $b;
}
our Bool multi infix:<==> ( Num $a, Num $b) {
return $a === $b;
}
our Bool multi infix:<==> ( Bool $a, Bool $b ) {
return $a === $b;
}
# ... complex, bit, etc.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"We had some good machines, but they don't work no more." -Shriekback
On Wed, 2006-07-12 at 15:32 -0500, Jonathan Scott Duff wrote:
> On Wed, Jul 12, 2006 at 04:16:13PM -0400, Aaron Sherman wrote:
> > On Wed, 2006-07-12 at 19:25 +0300, Yuval Kogman wrote:
> > > 4. will we have a deep (possibly optimized[1]) equality operator, that
> > >
Yuval Kogman wrote:
On Wed, Jul 12, 2006 at 17:58:03 -0400, Aaron Sherman wrote:
Then ~~ is wrong in that respect, and I think we should be talking about
that, not about making === into "~~, but without invoking code when it
shouldn't."
But it should! It's the sma
On Wed, 2006-07-12 at 17:52 -0700, Larry Wall wrote:
> On Wed, Jul 12, 2006 at 12:51:57PM -0400, Aaron Sherman wrote:
> : I would assume that all classes automatically define:
> :
> : multi submethod *infix: ($self: $?CLASS) { $self }
>
> Hmm, "as" is really onl
9 may not contain every function available to
Perl 6 programmers as a builtin, it will at least give Perl 5
programmers a sense of what happened to what they knew. The API
documents should probably be the more authoritative reference for
implementing P6 core libraries.
--
Aaron Sherman <
nship to each other that was obvious to the
programmer who wrote the statement.
Keep in mind that if you have an Any and you want to match against it
smartly, you can always request your poison:
$a ~~ ($b as Regex)
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"We had some good machines, but they don't work no more." -Shriekback
are scalarized here. Both C<~~>
and C/C provide scalar contexts to their arguments.
(You can always hyperize C<~~> explicitly, though.)
Both C<$_> (the value) and C<$x> (the match specification) here are
potentially references to container objects.
And since lists pro
I was looking over an example of named parameter passing:
foo(:a<1>, :b<2>)
And had the thought that we might be able to get away with treating
named parameters as lvalues, making the above:
foo(:a=1, :b=2)
Would this be unreasonable? Does it break anything else? I'm not sure
Jonathan Scott Duff wrote:
On Wed, Sep 13, 2006 at 10:20:31AM +1200, Sam Vilain wrote:
Larry Wall wrote:
.META is more correct at the moment.
Does making it all upper caps really help? It's still a pollution of the
method space, any way that you look at it...
Yeah but perl has already h
David Brunton wrote:
Aaron Sherman wrote:
IMHO, the golden rule of programming languages should be: if you
need a namespace, create one.
Is there any reason these "meta" methods could not be part of some
default function package like Math::Basic and Math::Trig? The
packag
I didn't see this going back, sorry if I missed someone sending the mail.
There was a discussion on IRC on Sept 9th about the -X filetest
operators between at least audreyt, Juerd, myself and markstos. The
problem with these operators was that they conflicted in some cases with
the parsing of
What happens to a program that creates a thread with a shared variable
between it and the parent, and then the parent modifies the class from
which the variable derives? Does the shared variable pick up the type
change? Does the thread see this change?
Smylers wrote:
Randal L. Schwartz writes:
"Smylers" == Smylers <[EMAIL PROTECTED]> writes:
Smylers> No: no aliases. Perl does not have a tradition of these,
except "for"/"foreach". :)
I don't reckon one instance is enough to be labelled a tradition!
(Um ... actually I forgot about that o
Mark J. Reed wrote:
(by the way, newbies don't use grep because list transforms confuse and
intimidate, not because of the name).
I dispute that. List transforms and grep are wholly separate beast,
This was a minor side-comment. Let's stay focused and not rat-hole on
our respective definiti
Jonathan Lang wrote:
Larry Wall wrote:
Mark J. Reed wrote:
: I have no horse in this race. My personal preference would be to
: leave grep as "grep". My second choice is "select", which to me is
: more descriptive than "filter"; it also readily suggests an antonym of
: "reject" to do a "grep -
Damian Conway wrote:
In other words, classify() takes a list of values, examines each in
turn, and ascribes a "label" value to it. The call returns a list of
pairs, where each pair key is one of the label values and each pair
value is an array of all the list values that were ascribed that labe
[EMAIL PROTECTED] wrote:
I still don't think we have a consensus that grep needs to be renamed,
much less what it should be renamed to. To me, "keep" implies throwing
the rest away,I.e., modifying the list. "Select" has the advantage of
lacking that connotation. To avoid dissonance with the two
Trey Harris wrote:
Might I propose the following normalization:
1. .call, method definition call(), and .wrap call all take captures.
2. .call() and both types of call() all pass on the arguments of the
current subroutine.
> 3. To call with no arguments, use .call(\()) and call(\()).
I
Larry Wall wrote:
On Wed, Sep 20, 2006 at 11:18:09AM -0400, Aaron Sherman wrote:
: Trey Harris wrote:
: >Might I propose the following normalization:
: >
: >1. .call, method definition call(), and .wrap call all take captures.
:
: >2. .call() and both types of call() all pass on t
Larry Wall wrote:
Okay, I think this is worth bringing up to the top level.
Fact: Captures seem to be turning into a first-class data structure
that can represent:
argument lists
match results
XML nodes
anything that requires all of $, @, and % bits.
This is quite true, and wo
Larry Wall wrote:
On Wed, Sep 20, 2006 at 05:18:12PM -0400, Aaron Sherman wrote:
: For this reason, I'd suggest putting away the Latin-1 glyphset and
: instead focusing on developing operators to act on containers with
: multiple access methods and their expanded forms.
There'
[EMAIL PROTECTED] wrote:
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 10 Aug 2004
- Last Modified: 18 Sept 2006
+ Last Modified: 20 Sept 2006
Number: 2
- Version: 69
+ Version: 70
+| capture/arguments/match
+|$args; # all of the above
I'll read that as
Mark J. Reed wrote:
Ok, I dkimmed through the synopses again and didn't see this offhand.
If I have two arrays @a and @b and I wish to create a two-element list
out of them - a la Perl5 ([EMAIL PROTECTED], [EMAIL PROTECTED]) - what's the
correct way to do
that in Perl6? If it's still ([EMAIL
All sounds good up to:
Larry Wall wrote:
The cultural ambiguity is also being reduced insofar as we're trying
to discourage use of bare constants in favor of sigilled constants.
If you see a bare function name you should generally assume it
has arguments in Perl 6.
Well, in that case, should
Jonathan Lang wrote:
Larry Wall wrote:
You don't need to use | to store a capture any more than you need @ to
store an array. Just as
$x = @b;
@$x;
gives you the original array,
Huh. I'm not used to this happening. So what would the following
code do, and why?
my @b = ('foo',
Carried over form IRC to placeholder the conversation as I saw it:
We define the following in S06 as immutable types:
ListLazy Perl list (composed of Seq and Range parts)
Seq Completely evaluated (hence immutable) sequence
Range Incrementally generated (hence la
Larry Wall wrote:
On Mon, Sep 25, 2006 at 09:02:56PM -0500, Mark Stosberg wrote:
:
: eval($yaml, :lang);
:
: Still, these options may not substitute for the kind of role-based
: solution you have mind.
I'm not sure it's wise to overload eval this way. Seems like a
great way to defeat MMD. P
Executive summary:
I suggest a signature prototype that all multis defined in or exported
to the current namespace must match (they match if the proto would allow
the same argument list as the multi, though the multi may be more
specific). Prototypes are exportable. Documentation tie-ins are a
Trey Harris wrote:
In a message dated Wed, 27 Sep 2006, Aaron Sherman writes:
Any thoughts?
I'm still thinking about the practical implications of this... but
what immediately occurs to me:
The point of multiple, as opposed to single, dispatch (well, one of
the points, and the only
TSa wrote:
HaloO,
Miroslav Silovic wrote:
What bugs me is a possible duplication of functionality. I believe
that declarative requirements should go on roles. And then packages
could do them, like this:
package Foo does FooMultiPrototypes {
...
}
I like this idea because it makes roles the
Jonathan Lang wrote:
Aaron Sherman wrote:
TSa wrote:
> Miroslav Silovic wrote:
>> package Foo does FooMultiPrototypes {
>> ...
>> }
>
> I like this idea because it makes roles the central bearer of type
> information.
Type information is secondary to the propos
Jonathan Lang wrote:
Aaron Sherman wrote:
Jonathan Lang wrote:
> Actually, it's a promise made by a package (not a class) to meet the
> specification given by a role (which can, and in this case probably
> does, reside in a separate file - quite likely one heavily laced with
>
Jonathan Lang wrote:
I hope not. My understanding is that '{ ... }' is supposed to
represent the notion of abstract routines: if you compose a role that
has such routines into a class or package, I'd expect the package to
complain bitterly if any such routines are left with yada-yadas as
their c
Trey Harris wrote:
In a message dated Fri, 29 Sep 2006, Aaron Sherman writes:
That said, this is a different point, above and I think it's an easy
one to take on.
role A { method x() {...} }
class B { does A; }
does generate an error per "If a role merely declares methods without
Jonathan Lang wrote:
I'm not used to programming styles where a programmer intentionally
and explicitly forbids the use of otherwise perfectly legal code. Is
there really a market for this sort of thing?
use strict;
chromatic wrote:
On Monday 02 October 2006 12:32, Jonathan Lang wrote:
Before we start talking about how such a thing might be implemented,
I'd like to see a solid argument in favor of implementing it at all.
What benefit can be derived by letting a module specify additional
strictures for its
Trey Harris wrote:
In a message dated Fri, 1 Sep 2006, jerry gay writes:
On 9/1/06, Trey Harris <[EMAIL PROTECTED]> wrote:
In a message dated Fri, 1 Sep 2006, Paul Seamons writes:
> I'm not sure if I have seen this requested or discussed.
This was definitively rejected by Larry in 2002:
p
Paul Seamons wrote:
Of course, that wasn't exactly what you were asking, but it does present
a practical solution when you want to:
{say $_ for =<>}.() if $do_read_input;
Which I just verified works fine under current pugs.
Thank you.
Hadn't thought of that. I think that is workable
Paul Seamons wrote:
It relates to some old problems in the early part of the RFC/Apocalypse
process, and the fact that:
say $_ for 1..10 for 1..10
Was ambiguous. The bottom line was that you needed to define your
parameter name for that to work, and defining a parameter name on a
modifi
Damian Conway wrote:
@bar».foo if $baz;
That brought to mind the question that I've had for some time: how are
exceptions going to work on hyper-operators?
Will they kill the hyperoperation in-progress? e.g. what will $i be:
my $i = 0;
class A { method inci() { die if $i
Aaron Sherman wrote:
Damian Conway wrote:
@bar».foo if $baz;
That brought to mind the question that I've had for some time: how are
exceptions going to work on hyper-operators?
Will they kill the hyperoperation in-progress? e.g. what will $i be:
Corrected example follows (there
I'm noodling around with the idea of creating an archive and index of
all of the messages to the mailing list over the years for purposes of
quickly finding all of the messages that have definitive information on
a given topic. Simply searching on Google or through my mail spool just
doesn't cu
Trey Harris wrote:
I read it as "yes, you *can* put strictures on the using code into a
library, though I wouldn't do it and would say that any module that does
so shouldn't be released on CPAN for general use. ..."
Hey, I have an idea. Let's write a module that enforces that!
Seriously, I t
S04 now reads:
==
However, a hash composer may never occur at the end of a line. If the
parser sees anything that looks like a hash composer at the end of
the line, it fails with "closing hash curly may not terminate line"
or some such.
my $hash = {
1 => { 2 => 3, 4 => 5 },
Jonathan Lang wrote:
What if I import two modules, both of which export a 'foo' method?
That's always fine unless they have exactly the same signature. In
general, that's not going to happen because the first parameter is
created from the invocant. Thus:
use HTML4;
use Math:
Aaron Sherman wrote:
Proposal: A sigil followed by [...] is always a composer for that type.
%[...]- Hash. Unicode: ⦃...⦄
@[...]- Array. Unicode: [...]
...
I left out ::, which is probably a mistake. Part of the elegance of
this, IMHO, is that it behaves the same for all
Mark J. Reed wrote:
On 10/5/06, Aaron Sherman <[EMAIL PROTECTED]> wrote:
Proposal: A sigil followed by [...] is always a composer for that type.
%[...] - Hash. Unicode: ⦃...⦄
@[...] - Array. Unicode: [...]
? - Seq. Unicode: ⎣...⎤
&[...] - Cod
Aaron Sherman wrote:
(updated based on followup conversations)
Proposal: A sigil followed by [...] is always a composer for that type.
%[...]- Hash.
@[...]- Array.
&[...]- Code.
|[...]- Capture. Identical to \(...).
$[...]- Scalar. Like item(...),
The example in S05 under "Subpattern numbering" isn't quite complex
enough to give the reader a full understanding of the ramifications of
the re-numbering that occurs with alternations, especially with respect
to the combination of capturing and non-capturing subpatterns. I've
written a small
@larry[0] wrote:
Log:
P5's s[pat][repl] syntax is dead, now use s[pat] = "repl"
Wow, I really missed this one! That's a pretty big thing to get my head
around. Are embedded closures in the string handled correctly so that:
s:g[\W] = qq{\\{$/}};
Will do what I seem to be expecting i
Ovid wrote:
The "intermediate class" solves the problem but it instantly suggests
that we have a new "design pattern" we have to remember. Basically, if
I can't lexically scope the additional behavior a role offers, I
potentially need to remove the role or use the "intermediate class"
pattern.
On Fri, Jul 10, 2009 at 3:32 PM, Mark J. Reed wrote:
> The clash between 'log' for 'logarithm' and 'log' for 'write to log
> file' is unfortunate, but since you have to define logging parameters
> somewhere anyway, I'm OK with having to call that sort of log as a
> method on a logger object inst
On Thu, Jul 9, 2009 at 6:22 PM, Moritz Lenz wrote:
>
> $str.File.e # same, different names
Brainstorming a bit here
Str is a class that describes collections of characters (among some other
typographical constructs, yadda, yadda, Unicode, yadda).
There is a commonly used speci
Sorry, I sent this just to Mark. Wasn't my intention.
-- Forwarded message --
From: Aaron Sherman
Date: Fri, Jul 10, 2009 at 6:58 PM
Subject: Re: Re-thinking file test operations
To: "Mark J. Reed"
On Fri, Jul 10, 2009 at 5:31 PM, Mark J. Reed wrote:
>
On Sun, Aug 2, 2009 at 1:10 PM, Moritz Lenz wrote:
> Let's pick up this old mail before it gets completely warnocked ;-)
>
> For the record, this discussion only applies to scalar implementation
> types. For example for Arrays I expect things to work by overriding the
> method postcircumfix:<[ ]>
I'm jumping in on an old conversation because I only just had time to catch
up last night. I have a few questions that I think are probably still
pertinent.
On Sun, Aug 16, 2009 at 4:26 PM, Damian Conway wrote:
>
> Executive summary:
>
> * Pod is now just a set of specialized forms of Perl 6
I'd really like to be able to assign a class to POD documentation. Here's an
example of why:
class Widget is Bauble
#= A widget is a kind of bauble that can do stuff
{
has $.things; #= a collection of other stuff
#==XXX{
This variable needs to be replaced for political reasons
}
Redirecting thread to language because I do agree that this is no longer a
matter of a bug.
On Fri, Sep 18, 2009 at 9:28 AM, Moritz Lenz via RT <
perl6-bugs-follo...@perl.org> wrote:
> On Thu Sep 17 08:53:59 2009, ajs wrote:
> > This code behaves as expected, matching 2 or 3 in only one out of th
On Sat, Sep 19, 2009 at 9:45 PM, David Green wrote:
> On 2009-Sep-19, at 5:53 am, Solomon Foster wrote:
>
> The one thing that worries me about this is how :by fits into it all.
>>rakudo: given 1.5 { when 1..2 { say 'between one and two' }; say
>> 'not'; };
>>rakudo: given 1.5 {
One of the first things that's becoming obvious to me in playing with
Rakudo's rules is that parsing strings isn't always what I'm going to
want to do. The most common example of wanting to parse data that's
not in string form is the YACC scenario where you want to have a
function produce a stream
Sorry, I accidentally took the thread off-list. Re-posting some of my
comments below:
On Wed, Oct 7, 2009 at 6:50 PM, Moritz Lenz wrote:
> Aaron Sherman wrote:
>> One of the first things that's becoming obvious to me in playing with
>> Rakudo's rules is that parsing stri
On Thu, Oct 8, 2009 at 12:57 AM, David Green wrote:
> I agree that being able to parse data structure would be *extremely* useful.
> (I think I posted a suggestion like that at one time, though I didn't
> propose any syntax.) There is already a way to parse data -- Signatures,
> but not with th
s not, but certainly they should
at least yield warnings by default.
PS: While I never finished the implementation of Sand, its simplistic guide
to Unicode identifiers might be useful in illuminating what I'm describing
above:
http://www.ajs.com/ajswiki/Sand:_Syntax_and_Structure#Identifiers
--
Aaron Sherman
Email or GTalk: a...@ajs.com
http://www.ajs.com/~ajs
uences are much-prized, and any
language that starts off with some poor assumptions will ultimately pay for
it.
Some good reading for recent work:
http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/
http://eprint.iacr.org/2006/086
http://lcamtuf.coredump.cx/oldtcp/tcpseq.html
http://www.avatar.se/p
.. \xDFFFD] + [\xE1000 .. \xEFFFD]>
(from the IRI specification)
--
Aaron Sherman
Email or GTalk: a...@ajs.com
http://www.ajs.com/~ajs
Ooops, took this off-list by accident.
-- Forwarded message --
From: ajs
Date: Mon, May 17, 2010 at 2:59 PM
Subject: Re: URI replacement pseudocode
To: Moritz Lenz
Thank you for your responses!
On Mon, May 17, 2010 at 1:37 PM, Moritz Lenz wrote:
> Aaron Sherman wr
he standard. The exegeses have no such status.
Personally, I'd rather see them updated than thrown out, but I tried writing
examples just for a few elements of S29 back in the day, and found the
moving target to be too painful. Maybe Perl 6 has slowed down enough that
it's more practical now?
--
Aaron Sherman
Email or GTalk: a...@ajs.com
http://www.ajs.com/~ajs
On Mon, May 17, 2010 at 3:34 PM, Moritz Lenz wrote:
>
>
> Aaron Sherman wrote:
>
> > I had a hard time even getting basic code working like:
> >
> > token foo { blah }
> > if "blah" ~~ m// { say "blah!" }
> >
> > (Se
On Mon, May 17, 2010 at 3:34 PM, Moritz Lenz wrote:
>
>
> Aaron Sherman wrote:
>
> > I had a hard time even getting basic code working like:
> >
> > token foo { blah }
> > if "blah" ~~ m// { say "blah!" }
> >
> > (Se
27;s entirely (un)wise. Then again, it does simplify the world
tremendously.
I just wanted to get that all out there for thought.
--
Aaron Sherman
Email or GTalk: a...@ajs.com
http://www.ajs.com/~ajs
ction you like in the map
portion (which just returns key/value pairs) and sortpairs' job is just
to compare the keys and return the resulting sorted values.
No Perl 6 here, move along ;-)
Perl 6 could contribute here by making it cheaper to construct/pass the
keys, but that's about it.
On Thu, 2004-02-12 at 08:43, Aaron Sherman wrote:
> sub sortpairs(&@) {
> my $comp = shift;
> my %pairs = @_;
> return map {$pairs{$_}} sort {$comp->($a)} keys %pairs;
> }
Doh... it's early for me. That's C()}> with no parameter.
The fact that $a and
a trait and a
Java interface other than the fact that traits appear to be more of a
run-time construct.
Java interfaces are actually a very nice compromise between multiple and
single inheritance.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the s
@new1 = sortpairs {$_[0] <=> $_[1]} map {[$_,$_]} @old1;
@new2 = sortpairs {$_[0] <=> $_[1] || $_[4] cmp $_[3]} map {[getkeys($_),$_]}
@old2;
The second example really illustrates the point that you can swap the
direction of ke
subref, not a string (thus having
closure status, and therefore access to context).
I think you and I are in violent agreement. I just look at this as a
problem that doesn't need solving because Schwartzian Transforms do all
the work for me. You look at it as something needing encapsulation.
That's cool, but sematically, we're doing the same work.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
On Thu, 2004-02-12 at 14:03, chromatic wrote:
> On Thu, 2004-02-12 at 05:52, Aaron Sherman wrote:
>
> > Perhaps I'm slow, but I don't see the difference between a trait and a
> > Java interface other than the fact that traits appear to be more of a
> > run-time
meterized argument passing with basic type constraints
* much improved and more reliable thread-safety
* A far lighter weight exception system
If Perl 6 contained only the above and nothing else, I would be a happy
camper, and my production code would be far less prone to errors and
structura
osed a mental hurdle. I'd love to see POD become
more compact vertically (e.g. not as much reliance on blank lines), and
also a better implementation of X and L, but other than that I think POD
is a wonderful format and one of the strenghts of the Perl distribution.
--
Aaron Sherman <[EMAIL
pattern for Perl 6, I find myself needing
the next step to be taken for work reasons and wanting it for personal
reasons.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
1 - 100 of 589 matches
Mail list logo
