Since you're interested in the management of the Perl 6 project, I'll
let you in on some of it. Let's start with a step back into a bit of
history:
We started off with an intense RFC process. This produced many good
ideas, not-so-good ideas, and ideas with potential but desperately
needing polish.
> Can currying include the given topic? Can
> I do something like:
>
> $foo = &bar.assuming( _ => 0)
>
> or whatever the latest syntax is?
Oops. More clearly:
sub bar is given($foo) {
...
}
$foo = &bar.assuming( foo => 0 )
--
ralph
> > My imagination suggests to me that in a
> > typical short perl 6 script
>
> That's some imagination you've got there! ;-)
:>
> My estimate (based on the -- not inconsiderable --
> code base of my own modules) is closer to 5%.
Your estimate of what others will do when
knocking out 10 line s
I have a rather fundamental proposal.
The A's and E's represent the framework and major decisions for Perl6,
but not every minor niggling issue and detail. As we keep seeing,
there is no shortage of things to pin down. We need to do that, and we
need to do it in the same rough order as the Ap
Luke Palmer wrote:
I just need a little clarification about yield().
The first point of clarification is that the subject is a little off.
C gives us *co-routines*, not *continuations*.
consider this sub:
sub iterate(@foo) {
yield for @foo;
undef;
}
(Where yield defaults to the t
Michael Lazzaro proposed:
It's up to Larry, and he knows where we're all coming from. Unless
anyone has any _new_ observations, I propose we pause the debate until a
decision is reached?
I second the motion!
Damian
Scott Duff wrote:
I'm all for one or two unicode operators if they're chosen properly
(and I trust Larry to do that since he's done a stellar job so far),
but what's the mechanism to generate unicode operators if you don't
have access to a unicode-aware editor/terminal/font/etc.? IS the only
rec
Buddha Buck wrote:
Examples:
# process @array, one element at a time
for @array -> $x { ... };
Yes.
# process @array, in pairs
for @array -> $x, $y { ... };
Yes.
# process all of @a, then all of @b, one element at a time
for @a, @b -> $x { ... };
Yes.
# process @a, then @b, in pai
Michael Lazzaro asked:
So how could we say "take 2 elements from @a, stepping 10 indices at a
time, plus one from @b"?
I think it's overreaching to try and fold this into C.
I'd suggest that hyperslicing @a within a C will probably
take care of that (presumably uncommon) case.
Damian
As one of the instigators of this thread, I submit that we've probably
argued about the Unicode stuff enough. The basic issues are now known,
and it's known that there's no general agreement on any of this stuff,
nor will there ever be. To wit:
-- Extended glyphs might be extremely useful in
one more data point from a person who lived, travelled and used computers
in a few countries (Romania, France, Germany, Belgium, UK, Canada, US,
Holland, Italy). paraphrasing:
rule 1: if it's not on my keyboard, it doesn't exist;
rune 2: if it's not on everybody's keyboard, it doesn't exist.
lon
On Tuesday, November 5, 2002, at 01:40 PM, Damian Conway wrote:
As Buddha Buck suggested elsewhere, and as I have coded above,
I would imagine that this functionality would be mediated by pairs
and merged into a single C function. So that last example is just:
for zip(@a=>2,@b=>1) -> $x,$y,$z
On Tue 05 Nov, Smylers wrote:
> Richard Proctor wrote:
>
> > I am sitting at a computer that is operating in native Latin-1 and is
> > quite happy - there is no likelyhood that UTF* is ever likely to reach
> > it.
> >
> > ... Therefore the only addition characters that could be used, that
> > wil
Michael Lazzaro wrote:
~ - force to string context
~ ~= - string concat
ARG. When did this get chosen?
~ has to be absolutly the most difficult letter to type on the intire
keyboard along with ^ and ", because they are also used as a prefix to
make û, ü, õ,
Scott Duff wrote:
Very nice. The n-ary "zip" operator.
Um ... could we have a zip functor as well?
Yes, I expect so. Much as C<|>, C<&>, and C<^> will be operator versions
of C, C, and C.
And I'd suggest that it be implemented something like:
sub zip(ARRAY *@sources; $by = 1) {
if exi
Richard Proctor wrote:
> I am sitting at a computer that is operating in native Latin-1 and is
> quite happy - there is no likelyhood that UTF* is ever likely to reach
> it.
>
> ... Therefore the only addition characters that could be used, that
> will work under UTF8 and Latin-1 and Windows ...
Peter Haworth wrote:
On Wed, 30 Oct 2002 15:31:24 -0800, Michael Lazzaro wrote:
Meaning that the list:
+^- force to numeric context, complement
~^- force to string context, complement
simply becomes:
^ - complement (type-specific)
Does this include booleans? I really like
Dan Kogai wrote:
> We already have source filters in perl5 and I'm pretty much sure
> someone will just invent yet another 'use operators => "ascii";' kind
> of stuff in perl6.
I think that's backwards to have operators being funny characters by
default but requiring explicit declaration to use w
On Tue, Nov 05, 2002 at 05:13:45AM -0600, Me wrote:
> > relatively few subroutines need access
> > to the upscope topic.
>
> Well, this is a central issue. What are
> the real percentages going to be here?
> Just how often will one type the likes
> of
>
> -> is given($foo is topic) { ... }
>
Ken Fox wrote:
I've been assuming that a keyword will only have
meaning in contexts where the keyword is valid.
Given the shiny new top-down grammar system, there's
no requirement for keywords to be global. (Context
sensitive keywords fall out of Perl 6 grammars
naturally -- just the opposite of
ralph hypothesized:
My imagination suggests to me that in a
typical short perl 6 script, between 20%
and 50% of all sub defs would use the
upscope topic... ;>
That's some imagination you've got there! ;-)
My estimate (based on the -- not inconsiderable -- code base of
my own modules) is closer
I'm all for one or two unicode operators if they're chosen properly
(and I trust Larry to do that since he's done a stellar job so far),
but what's the mechanism to generate unicode operators if you don't
have access to a unicode-aware editor/terminal/font/etc.? IS the only
recourse to use the "n
Thanks, I've been hoping for someone to post that list. Taking it one
step further, we can assume that the only chars that can be used are
those which:
-- don't have an obvious meaning that needs to be reserved
-- appear decently on all platforms
-- are distinct and recognizable in the tiny fon
On Tuesday, November 5, 2002, at 06:51 AM, Peter Haworth wrote:
On Wed, 30 Oct 2002 15:31:24 -0800, Michael Lazzaro wrote:
Meaning that the list:
+^- force to numeric context, complement
~^- force to string context, complement
simply becomes:
^ - complement (type-specific)
this is not a description or definition of something. It is just set
of questions and confusions that I have when I encounter words like
"variable" , "name" , "alias", "assign" in perl . In the form of
explanation. But actually these are questions .
so , what follows is not the "how it actuall
I just need a little clarification about yield().
consider this sub:
sub iterate(@foo) {
yield for @foo;
undef;
}
(Where yield defaults to the topic) Presumably.
@a = (1, 2, 3, 4, 5);
while($_ = iterate @a) {
print
}
Will print "12345". Or is that
Jonathan Scott Duff wrote:
Um ... could we have a zip functor as well? I think the common case
will be to pull N elements from each list rather than N from one, M
from another, etc. So, in the spirit of timtowtdi:
for zip(@a,@b,@c) -> $x,$y,$z { ... }
sub zip (\@:ref repeat{1,}) {
my $ma
Here's my current understanding of what's under discussion for for-loops:
Larry wants to eliminate the ; from the RHS of the ->, so the only thing
for needs to know about the RHS is the number and types of the
arguments. This puts the specification about how to generate those
arguments on the
On Mon, Nov 04, 2002 at 12:26:56PM -0800, Austin Hastings wrote:
>
> > Of course, I also think I'm allowed to be a little inconsistent in
> > forcing things like ?op? on people. After all, there's gotta be
> > some advantage to being the Fearless Leader...
>
> Which kind of begs the question: Wh
On Tue, Nov 05, 2002 at 03:21:54PM +1100, Damian Conway wrote:
> Larry wrote:
> > But let's keep it
> > out of the signature, I think. In other words, if something like
> >
> > for @x ⥠@y ⥠@z -> $x, $y, $z { ... }
> >
> > is to work, then
> >
> > @result = @x ⥠@y ⥠@z;
> >
>
On Wed, 30 Oct 2002 15:31:24 -0800, Michael Lazzaro wrote:
> Meaning that the list:
>
>+^- force to numeric context, complement
>~^- force to string context, complement
>
> simply becomes:
>
>^ - complement (type-specific)
Does this include booleans? I really liked the i
Me wrote:
YAK for marking something.
I've been assuming that a keyword will only have
meaning in contexts where the keyword is valid.
Given the shiny new top-down grammar system, there's
no requirement for keywords to be global. (Context
sensitive keywords fall out of Perl 6 grammars
naturally
> relatively few subroutines need access
> to the upscope topic.
Well, this is a central issue. What are
the real percentages going to be here?
Just how often will one type the likes
of
-> is given($foo is topic) { ... }
rather than
-> $foo: { ... }
?
My imagination suggests to me tha
Smylers <[EMAIL PROTECTED]> writes:
> Phew! I'm slightly concerned at this list making Piers's job too easy,
> but have tried to minimize that effect by posting on a Monday (meaning
> that this mail is ineligible for inclusion in the next summary and is
> likely to be out of date by the time of th
This UTF discussion has got silly.
I am sitting at a computer that is operating in native Latin-1 and is
quite happy - there is no likelyhood that UTF* is ever likely to reach it.
The Gillemets are coming through fine, but most of the other heiroglyphs need
a lot to be desired.
Lets consider the
On Tuesday, Nov 5, 2002, at 04:58 Asia/Tokyo, Larry Wall wrote:
(B> It would be really funny to use cent $B!q(B, pound $B!r(B, or yen (J\(B as a sigil,
(B> though...
(B
(BWhich 'yen' ? I believe you already know \ (U+005c -> REVERSE SOLIDUS)
(Bis prited as a yen figure in most of Japa
36 matches
Mail list logo
