Damian Conway wrote:
sub debug is immediate is exported (@message) {
return $debugging ?? { print $*STDERR: @message; } :: {;}
}
Won't @message need lazy evaluation? How will Perl know to
delay interpolation until the result of the "macro" is called
at run time?
- Ken
Damian Conway wrote:
For that reason, even if we can solve this puzzle, it might be far kinder
just to enforce parens.
I might be weird, but when I use parens to clarify code in Perl, I
like to use the Lisp convention:
(method $object args)
Hopefully that will still work even if Perl 6 requi
Smylers wrote:
Ken Fox wrote:
How about formalizing global namespace pollution with something like
the Usenet news group formation process? Ship Perl 6 with a very
small number of global symbols and let it grow naturally.
If the initial release of Perl 6 doesn't have commonly-req
Damian Conway wrote:
Ken Fox asked:
Is it correct
to think of flattening context as a lexical flattening? i.e.
only terms written with @ are flattened and the types of
the terms can be ignored?
I'm not sure I understand this question.
Sometimes array references behave as arrays, e.g.
Damian Conway wrote:
sub part ($classifier, *@list) {
return @parts;
}
Given the original example
(@foo,@bar,@zap) := part [ /foo/, /bar/, /zap/ ] @source;
this binds the contents of @parts to (@foo,@bar,@zap)? The
array refs in @parts are not flattened though. Is it c
Michael Lazzaro wrote:
(@foo,@bar,@zap) := classify { /foo/ ;; /bar/ ;; /zap/ } @source;
A shorthand for:
for @source {
given {
when /foo/ { push @foo, $_ }
when /bar/ { push @bar, $_ }
when /zap/ { push @zap, $_ }
}
}
How about just
(@foo,@bar,@
Damian Conway wrote:
It's [<<...>>>] the ASCII synonym for the «...» operator, which
is a synonym for the qw/.../ operator.
Nope. Heredocs still start with <<.
Hey! Where'd *that* card come from? ;)
Seriously, that's a good trick. How does it work? What do these
examples do?
print <<"a" "
Damian Conway wrote:
Ken Fox wrote:
The < must begin the circumfix <> operator.
Or the circumfix <<...>> operator. Which is the problem here.
This is like playing poker with God. Assuming you can get over
the little hurdles of Free Will and Omniscience, there'
Damian Conway wrote:
my $iter = fibses();
for < <$iter> > {...}
(Careful with those single angles, Eugene!)
Operator << isn't legal when the grammar is expecting an
expression, right? The < must begin the circumfix <> operator.
Is the grammar being weakened so that yacc can handle it?
Michael G Schwern wrote:
Before this starts up again, I hereby sentence all potential repliers to
first read:
"string concatenation operator - please stop"
http://archive.develooper.com/perl6-language@;perl.org/msg06710.html
The bike shed thing is like Godwin's Law. Only I don't know
which side
Andy Wardley wrote:
Can we overload + in Perl 6 to work as both numeric addition
and string concatenation ...
Isn't there some nifty Unicode operator perl6 could enlist? ;)
How about concatenating adjacent operands? ANSI C does this
with string constants and it works very well. It would become
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
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
Austin Hastings wrote:
The << and >> ... are just as pictographic (or
not) as [ and ].
I'm not particularly fond of << or >> either. ;) Damian just
wrote that he prefers non-alphabetic operators to help
differentiate nouns and verbs. I find it helpful when people
explain their biases like that.
Austin Hastings wrote:
At this point, Meestaire ISO-phobic Amairecain Programmaire, you have
achieved keyboard parity with the average Swiss six-year-old child.
The question is not about being ISO-phobic or pro-English. **
The question is whether we want a pictographic language. I like
the siz
Damian Conway wrote:
Larry Wall wrote:
That suggests to me that the circumlocution could be >>*<<.
A five character multiple symbol??? I guess that's the penalty for not
upgrading to something that can handle unicode.
Unless this is subtle humor, the Huffman encoding idea is getting
seriously
Luke Palmer wrote:
> On Thu, 12 Sep 2002, Ken Fox wrote:
> > Perl already needs infinite lookahead.
>
> Really? Where?
Indirect objects need infinite lookahead and they are
in the core language. Hyper operators may need lookahead.
Place holders may need lookahead. User def
Luke Palmer wrote:
> This requires infinite lookahead to parse. Nobody likes infinite
> lookahead grammars.
Perl already needs infinite lookahead. Anyways, most people
don't care whether a grammar is ambiguous or not -- if we did,
natural human languages would look very different.
People want
Damian Conway wrote:
> Though leaving optimization in the hands of the programmer
> is generally a Bad Idea.
That doesn't sound like a Perl slogan.
> It's also a matter of syntactic consistency. It has to be := for
> "inlined" bindings (i.e. rx/ $name:= /) because otherwise
> we make = meta (whi
Mr. Nobody wrote:
> /^([+-]?)(?=\d|\.\d)\d*(\.\d*)?([Ee]([+-]?\d+))?$/
>
> would actually become longer:
>
> /^(<[+-]>?)\d*(\.\d*)?(<[Ee]>(<[+-]>?\d+))?$/
Your first expression uses capturing parens, but the captures
don't bind anything useful, so you should probably compare
non-capturing versi
Damian Conway wrote:
> Because what you do with a hypothetical has to be reversible.
> And binding is far more cheaply reversible than assignment.
Why not leave it in the language spec then? If it's too
hard to implement, then the first release of Perl 6 can
leave it out. Someday somebody might c
Damian Conway wrote:
> I would imagine that modifiers would be passed some
> kind of hierarchical representation of the rule
> they're modifying (i.e. a parse tree of it), and
> would be expected to manipulate that structure
> representation.
Excellent. Will there be an abstract syntax for tree
r
David Whipp wrote:
> But can I use a non-constant date?
You didn't show us the iso_date rule.
> Obviously we could put the onus on the module writer to write super-flexible
> rules/grammars. But will there be an easy way to force interpolative context
> onto this type of regex-valued subroutine
Dan Sugalski wrote:
> At 9:10 AM -0400 9/4/02, [EMAIL PROTECTED] wrote:
>> So, just to clarify, does that mean that multi-dispatch is (by
>> definition)
>> a run-time thing, and overloading is (by def) a compile time thing?
>
> No. They can be both compile time things or runtime things, dependin
David Wheeler wrote:
> Ah, yes, the same thing exists in Java. I remember, now.
I thought Java only has over loading?
Over loading is what C++ has. It is not the same as
multi-dispatch. The trouble with over loading is that the
compiler uses static (compile-time) type information to
select the o
Peter Haworth wrote:
> Also the different operators used (:= inside the rule, = inside the code)
> seems a bit confusing to me; I can't see that they're really doing anything
> different:
>
> / $x := (gr\w+) /vs/ (gr\w+) { let $x = $1 } /
>
> Shouldn't they both use C< := > ?
Depen
Damian Conway wrote:
> One possibility is that a modifier is
> implemented via a special class:
>
> my class Decomment is RULE::Modifier
>is invoked(:decomment) {
> method SETUP ($data, $rule) {
> ...
> }
> # etc.
>
The thing I'd like to do right now is turn on :w
for all rules. A Fortran grammar might want to turn
on :i for all rules.
Maybe add modifiers to the grammar declaration?
grammar Fortran :i { ... }
It would also be convenient to allow the :w
modifier to have lexically scoped behavior so a
gra
Damian Conway wrote:
> No. It will be equivalent to:
>
> <[\x0a\x0d...]>
I don't think \n can be a character class because it
is a two character sequence on some systems. Apoc 5
said \n will be the same everywhere, so won't it be
something like
rule \n { \x0d \x0a | \x0d | \x0a }
Hmm.
Simon Cozens wrote:
> [EMAIL PROTECTED] (Damian Conway) writes:
>
>>> %hash4 = ("Something", "mixing", pairs => and, "scalars");
>>
>>That's perfectly okay (except you forgot the quotes around the
>>and you have an odd number of elements initializing the hash).
>
> Urgh, no. Either a pair is a
Piers Cawley wrote:
> Unless I'm very much mistaken, the order of execution will
> look like:
>
> $2:=$1; $1:=$2;
You're not binding $2:=$1. You're binding $2 to the first
capture. By default $1 is also bound to the first capture.
Assuming that numbered variables aren't special, the orde
Larry Wall wrote:
> There's a famous book called "Golf is Not a Game of Perfect".
Well now I'm *totally* confused. I looked that up on Amazon
and it has something to do with clubs and grass and stuff. That's
completely different than what I thought golfing was. ;)
Seriously, though. I have a pos
Larry Wall wrote:
> On Fri, 30 Aug 2002, Ken Fox wrote:
> : Ok, thanks. (The "followed by a colon" is just to explain the behavior,
> : right? It's illegal to follow a code block with a colon, isn't it?)
>
> I don't see why it should be illegal--it cou
Damian Conway wrote:
> rule expr1 {
> { m:cont/@operators/ or fail }
> }
>
> Backtracking would just step back over the rule as if it were atomic
> (or followed by a colon).
Ok, thanks. (The "followed by a colon" is just to explain the behavior,
right? It's illegal to follow a
Aaron Sherman wrote:
> rule { { /@operators/.commit(1) or fail } }
>
> The hypothetical commit() method being one that would take a number and
That would only be useful if the outer rule can backtrack into the
inner /@operators/ rule. Can it?
I agree with you that a commit method woul
A question: Do rules matched in a { code } block set backtrack points for
the outer rule? For example, are these rules equivalent?
rule expr1 {
{ /@operators/ or fail }
}
rule expr2 {
@operators
}
And a comment: It would be nice to have procedural control over back-
tracking
Uri Guttman wrote:
> but remember that whitespace is ignored as the /x mode is on
> all the time.
Whoops, yeah. For some reason I kept literal mode on when
reading the spaces between two literals.
The rules {foo bar} and {foobar} are the same, but some
very low level part of my brain is resisti
Dave Storrs wrote:
> why didn't you have to write:
>
> rule ugly_c_comment {
>
/
>
\/ \* [ .*? ? ]*? \* \/
>
{ let $0 := " " }
>
/
> }
Think of the curly braces as the regex quotes. If "{" is the quote
then there's nothing spe
Garrett Goebel wrote:
> Just does compile-time typing for $foo? Not inlining the constant?
You can't assume that the value associated with the symbol is
the same each time through the code, so how can it be inlined?
> I was thinking lowercase typed variables couldn't be rebound, because
> they w
Garrett Goebel wrote:
> worried about the loss of data-hiding with Perl6's lexicals.
> Was that ever resolved?
Here in the 10-step Perl 6 program we don't talk about
resolution. We just learn to cope with change. ;)
There were two issues I had. As a Perl 6 user I felt
uncomfortable that Perl 6 i
"Bryan C. Warnock" wrote:
> Generically speaking, modules aren't going to be running amok and making a
> mess of your current lexical scope - they'll be introducing, possibily
> repointing, and then possibly deleting specific symbols
How much do you want to pay for this feature? 10% slower code?
Damian Conway wrote:
> Bzzzt! The line:
>
> %MY::{'$x'} = \$z;
>
> assigns a reference to $z to the *symbol table entry* for $x, not to $x itself.
So I should have said:
%MY::{'$x'} = $z;
That's pretty magical stuff isn't it? Sorry I used the wrong syntax.
I'm just taking it from yo
Dan Sugalski wrote:
> On the other hand, if we put the address of the lexical's PMC into a
> register, it doesn't matter if someone messes with it, since they'll be
> messing with the same PMC, and thus every time we fetch its value we'll Do
> The Right Thing.
Hmm. Shouldn't re-binding affect onl
Dan Sugalski wrote:
> At 02:05 PM 9/6/2001 -0400, Ken Fox wrote:
> >You wrote on perl6-internals:
> >
> >get_lex P1, $x # Find $x
> >get_type I0, P1 # Get $x's type
> >
> >[ loop using P1 and I0 ]
> >
> >That cod
Dave Mitchell wrote:
> Can anyone think of anything else?
You omitted the most important property of lexical variables:
[From perlsub.pod]
Unlike dynamic variables created by the C operator, lexical
variables declared with C are totally hidden from the outside
world, including any calle
Dan Sugalski wrote:
> I think you're also overestimating the freakout factor.
Probably. I'm not really worried about surprising programmers
when they debug their code. Most of the time they've requested
the surprise and will at least have a tiny clue about what
happened.
I'm worried a little abo
Dan Sugalski wrote:
> ... you have to take into account the possibility that a
> variable outside your immediate scope (because it's been defined in an
> outer level of scope) might get replaced by a variable in some intermediate
> level, things get tricky.
Other things get "tricky" too. How abou
[EMAIL PROTECTED] wrote:
> Clearly caller() isn't what we want here, but I'm not
> quite sure what would be the correct incantation.
I've always assumed that a BEGIN block's caller() will
be the compiler. This makes it easy for the compiler to
lie about %MY:: and use the lexical scope being compi
Damian wrote:
> In other words, everything that Exporter does, only with lexical
> referents not package referents. This in turn gives us the ability to
> easily write proper lexically-scoped modules.
Great! Then we don't need run-time lexical symbol table
frobbing. A BEGIN block can muck with it
Damian wrote:
> Dan wept:
>> I knew there was something bugging me about this.
>>
>> Allowing lexically scoped subs to spring into existence (and
>> variables, for that matter) will probably slow down sub and
>> variable access, since we can't safely resolve at compile time wh
Damian Conway wrote:
> It would seem *very* odd to allow every symbol table *except*
> %MY:: to be accessed at run-time.
Well, yeah, that's true. How about we make it really
simple and don't allow any modifications at run-time to
any symbol table?
Somehow I get the feeling that "*very* odd" can'
I haven't seen details in an Apocalypse, but Damian's
Perl 6 overview has a bit about it. The Apocalypse
specifically mentions *compile-time* scope management,
but Damian is, uh, Damian. (DWIMery obviously. ;)
Is stuff like:
%MY::{'$lexical_var'} = \$other_var;
supposed to be a compile-time o
"Bryan C. Warnock" wrote:
> {
> my $a = sub ($$) { code };
> gork($a);
> }
>
> sub gork {
> my ($a) = shift;
> $a->(@some_list); # <- Here
> }
>
> The reason prototypes aren't checked at "Here" is because there really
> isn't a way to know what the prototype was.
Um, that's not
"Bryan C. Warnock" wrote:
> I'm waiting for someone to say that in tri-state logic, '!<' != '>='
That's what I thought it was. "$a !< $b" might be "!defined($a) || $a >= $b".
In SQL this is "$a IS NULL or $a >= $b".
- Ken
Damian Conway wrote:
> Ken wrote:
>> The one thing I'm curious about is whether different syntactic
>> conventions affect the dispatcher or whether this is all just
>> sugar for a single dispatch.
>
> Multiple dispatch is certainly not (practically) implementable via single
> dispatch
Uri Guttman wrote:
[Re: use strict 'typing'; my $rex = new Dog; $rex.bark]
> then it should be a compile time error at the assignment to $rex
> and not later. you can't trace $rex at compile time to see what
> kind of object (if any) was assigned to it. so the illegal method
> call can't (easily)
[EMAIL PROTECTED] wrote:
> Dan, I don't immediately see how per object/class dispatch
> control helps to make multimethods pluggable.
The way to approach this problem is to profile
Class::MultiMethods and figure out (a) where the hot spots
are and (b) what core support would help eliminate those
Garrett Goebel wrote:
> From: Dave Mitchell [mailto:[EMAIL PROTECTED]]
> > Okay, to humour me for a mo', what should the following 2 examples
> > output if Perl were doing the "right" thing?
> >
> > sub pr { print $_[0] || 'undef', "\n" }
> >
> > { my $x = 'X'; sub f { $F = sub {pr $x} }}
> > f();
Michael G Schwern wrote:
> If you *really* wanted to write an optimized redirector, you'd
> have the redirector eliminate itself.
That's not always appropriate. In my frame system, an instance
can over-ride its class method. An instance can also remove the
over-ride and return to using the class
Dave Mitchell wrote:
> The whole point is that closed variables *aren't* 'just local variables'.
> The inner $x's in the following 2 lines are vastly different:
>
> sub foo { my $x= ... { $x } }
> sub foo { my $x= ... sub { $x } }
You really need to learn what a closure is. There's a
Michael G Schwern wrote:
> Any time you want to implicitly pass @_, you can just as easily
> *explicitly* pass it or use goto.
I never thought of using goto actually. "goto &$method;" actually
looks clearer than the code I'm using. (Although with re-directors
we want to minimize cost so the 10% p
Michael G Schwern wrote:
> I can't think of any reason why this feature is useful anymore, and it
> can be a really confusing behavior, so what say we kill it in Perl 6?
I've always thought is was pretty useful for implementing generic
redirectors. I wrote a frame system that allows instances to
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 04:38 PM 8/8/2001 +, Brian J. Kifiak wrote:
> > > Unfortunately all the references I have for alternatives really
> > > require what the Dragon Book teaches as a foundation.
> >
> > What are the references?
>
> ... Advanced Compiler Design & Implem
Dave Mitchell <[EMAIL PROTECTED]> wrote:
> John Porter <[EMAIL PROTECTED]> wrote:
> > Dave Mitchell wrote:
> > > I think closures are a lot harder (or at least subtler) than
> > > people think ...
> >
> > ... The scenario you gave seems rather far-fetched to me, in terms
> > of real-world program
[Please be careful with attributions -- I didn't write any
of the quoted material...]
Russ Allbery wrote:
> >> sub test {
> >> my($foo, $bar, %baz);
> >> ...
> >> return \%baz;
> >> }
> That's a pretty fundamental aspect of the Perl language; I use that sort
Bart Lateur wrote:
> On Fri, 09 Feb 2001 12:06:12 -0500, Ken Fox wrote:
> > 1. Cheap allocations. Most fast collectors have a one or two
> >instruction malloc. In C it looks like this:
> >
> > void *malloc(size) { void *obj = heap; heap += size; return obj; }
"David L. Nicol" wrote:
> # with POST
> sub find_first_line_matching_array($\@){
> open F, shift or die "could not open: $!";
> POST{close F};
> while(){
> foreach $w (@{$_[0]}){
>
Dan Sugalski wrote:
> At 04:09 PM 2/9/2001 -0200, Branden wrote:
> > If I change the way some objects are used so
> > that I tend to create other objects instead of reusing the old ones, I'm
> > actually not degrading GC performance, since its work is proportional to
> > live data. Right?
>
> Cor
Branden wrote:
> Ken Fox wrote:
> > Some researchers have estimated that 90% or
> > more of all allocated data dies (becomes unreachable) before the
> > next collection. A ref count system has to work on every object,
> > but smarter collectors only work on 10% of the
Branden wrote:
> I actually don't understand how traversing a graph can be faster than
> incrementing/decrementing/testing for zero on a refcount.
There are two main reasons advanced garbage collectors are fast:
1. Cheap allocations. Most fast collectors have a one or two
instruction malloc
Dan Sugalski wrote:
> At 12:33 PM 2/1/2001 -0500, Michael G Schwern wrote:
> > Have a look at AnyLoader in CPAN.
>
> Looks pretty close to what's needed. Care to flesh it out (and streamline
> it where needed) to a PDD?
Isn't the trick to detect the necessary modules at compile time? Run-time
ca
Dan Sugalski wrote:
> At 02:04 PM 2/1/2001 -0500, Ken Fox wrote:
> >Isn't the trick to detect the necessary modules at compile time?
>
> Nope, no trick at all. The parser will have a list of functions--if it sees
> function X, it loads in module Y. (Possibly version Z) N
Dan Sugalski wrote:
> At 11:57 PM 1/31/2001 +0100, [EMAIL PROTECTED] wrote:
> > On Wed, Jan 31, 2001 at 05:35:03PM -0500, Michael G Schwern wrote:
> > > grossly UNIX specific things like getpwnam's [can be pulled]
> >
> > But why? What is it going to buy you?
>
> Not that much. More than anything
Bart Lateur wrote:
> What if we take the ordinary sleep() for the largest part of the
> sleeping time (no busy wait), and the 4 argument select for the
> remainder, i.e. subsecond?
You're trying to solve a problem that doesn't exist.
Sleep doesn't have the signal delivery problems that alarm has
Branden wrote:
> Actually, with event loops and threading issues, probably things like
> the perl built-ins sleep and alarm won't ever be passed to the syscalls
> sleep(3) and alarm(3).
Sleep isn't usually a syscall -- it's often a library routine that sets
an alarm and blocks or uses some other
Bart Lateur wrote:
> But isn't there going to be a large overhead, in populating such a
> "hash"?
If you need an ordered data structure the overhead would be lower
than using a hash.
> Doesn't the tree have to be reorganized every time you add a
> single new entry?
No. Sometimes you may have to
Nathan Wiger wrote:
> Your point is assuming that STDERR retains its weirdness, and does not
> become a simple scalar object ...
sub STDERR () { $STDERR }
or am I missing something?
> Making STDERR into $STDERR is all hinged on fast vtable stuff in core ...
Absolutely false. $STDERR does not d
Dan Sugalski wrote:
> I expect we'd want to have some sort of heavy-duty regex optimizer, then,
> to detect common prefixes and subexpressions and suchlike things, otherwise
> we end up with a rather monstrous alternation sequence...
We need a regex merge function too -- then we could write macro
"David L. Nicol" wrote:
> Ken Fox wrote:
> > IMHO, curries have nothing to do with this. All "with" really does is
> > create a dynamic scope from the contents of the hash and evaluate its
> > block in that scope.
...
> But that doesn't give us th
Damian Conway wrote:
> sub sort (^&comparator, @list) {
> for (1..@list**3) {
> my ($i, $j) = (rand(@list), rand(@list));
> @list[$i,$j] = @list[$j,$i]
> unless $comparator->(a: $list[$i], b: $list[$j]);
>
Dave Storrs wrote:
> On Thu, 17 Aug 2000, Jonathan Scott Duff wrote:
> > BTW, if we define C to map keys of a hash to named place holders
> > in a curried expression, this might be a good thing:
> >
> > with %person {
> > print "Howdy, ", ^firstname, " ", ^lastname;
> > }
> >
Piers Cawley wrote:
>$ints_from = ^1 => sub {$ints_from->(^1+1)};
>$ints = $ints_from->(1);
I think pairs should use array range syntax ".." and be folded
into the array generator RFC (or at least referenced in that RFC).
In particular, using a pair in an array context should interpret
t
Bart Lateur wrote:
> On Tue, 08 Aug 2000 23:43:26 -0400, Ken Fox wrote:
> >(assuming min() is polymorphic):
> >
> > min($a, $b) eq $a
> >
> >Ugly, but minimal changes to the language.
>
> We could adopt a syntax similar to sort():
>
> $lo
Dan Sugalski wrote:
> The number of different vtables needed to deal with this (along with
> the functions in those tables) is rather formidable, and it will tend
> to impact performance.
Hey! That sounds like an implementation topic... ;) (The internals
should be able to handle this if the langu
> Higher order functions
This is a very nice proposal and I'd like to see it adopted. Since
many other RFCs are bound to assume this functionality, can we put
this one on the "fast track" approval process? ;)
- Ken
Michael Fowler wrote:
> I would argue that you should be manipulating your data, or checking values,
> so that numbers and strings are sorted how you wish. The proposed isnum(),
> or way-to-determine-if-a-scalar-is-a-number would help. This should be an
> explicit check, though, because you have
John Porter wrote:
> Jeremy Howard wrote:
> > Yes, they're not identical. What I mean of course is:
> > (..-1) == reverse(map -__ (1..));
>
> WHAT? So the semantics of .. are magically different in the context
> of (..$n) so as to produce numbers in descending order?
Both of those expressions
Peter Scott wrote:
> Have often wanted a way to tell whether a scalar was a number
> way to get at the SvIOK and SvNOK results would be great.
SvIOK, SvNOK and "is a number" are not the same thing at all.
Often numbers are strings that just look like numbers. Perl doesn't
eagerly convert stuff i
Jeremy Howard wrote:
> Anyhoo, there's no reason why you can't have ^1, ^2, and so forth, _and_
> allow named placeholders too. Although I don't see what this buys you.
Argument ordering. We might be constrained by the caller as to what order
the placeholders are passed in. Also, we want to make
Mike Pastore wrote:
> Ken Fox wrote:
> > > Although, I suppose '&' would not work.
> >
> > Why not? I think it would work great.
>
> Well, what's the different between the placeholder &foo and the sub
> &foo? That's the main rea
[Sorry, spent too much time thinking in the editor and did not
see this before my reply.]
Mike Pastore wrote:
> - ^foo is the placeholder 'foo'
That already has perfectly good meaning: XOR with the function foo().
> Although, I suppose '&' would not work.
Why not? I think it would work great.
Dan Sugalski wrote:
> But, if we toss refcounts, and split GC cleanup and
> end of scope actions anyway, we need to have a mechanism to hoist things
> out of the current scope.
Why say hoist when we can say return? I can think of several ways of
returning values that don't require the caller to a
Jeremy Howard wrote:
> It is proposed that Perl introduce a new prefix '_', which indicates a
> placeholder. This can be used either as '_identifier', which creates a named
> placeholder, or '__', which creates an anonymous placeholder.
This is a good idea, but it has a good chance of tripping up
Damian Conway wrote:
> That should of course have been:
>
> __ < 2 + __ * atan2($pi, __) or die __
Oh, yes, of course. Um, wait. Nope, I still don't follow. The
expression above curries to:
sub { $_[0] < 2 + $_[1] * atan2($pi, $_[2]) or die $_[3] }
But the expression
__ < 2 + __ * sin(__
Perl6 RFC Librarian wrote:
> BiDirectional Support in PERL
I know nothing about bi-directional output. It doesn't seem
like Perl has any assumption of left-to-right at all. What's
the difference between right-to-left support in Perl and just
editing/using Perl in an xterm that does right-to-left?
Nathan Wiger wrote:
>$pw = getpwnam('nwiger');
>print "$pw"; # calls $pw->SCALAR, which prints 'nwiger'
>die "Bad group" unless $pw->gid == 100;
I'm ashamed that this feature would mess with my (bad?) habit of
re-writing "$pw" to just $pw on the assumption that whoever wrote
Dan Sugalski wrote:
> At 02:09 AM 8/6/00 -0400, Chaim Frenkel wrote:
> > uplevel 0, $Perl:Warnings=1;# Hit everyone
> > uplevel -1, $Perl:Warnings=0; # Hit my wrapper
> Yeah, I can see that. We're going to need a mechanism to hoist things to
> outer scope levels internally (f
Jeremy Howard wrote:
> (..-1) == map -__ (1..);
That really confuses me. If the sequence (-4..-1) is (-4, -3,
-2, -1) then I don't see how your semantics are consistent. I'll
admit (reverse map -__ (1..)) is the same as (..-1) but reverse
on a stream is undefined. (It should be a run-time error
Glenn Linderman wrote:
> [currying] appears to be powerful, and a kind of like generic programming on
> the fly. I'd like to learn more: if someone would give a tutorial
> reference that would be helpful.
I'll try to find something. There's a bit of computer science snobbery
related to functiona
Glenn Linderman wrote:
> For instance,
>
> if ( $v == @foo )
>
> is clearly testing the size of foo against the value of $v. But
>
> switch ( $v ) {
> case 1: { ... }
> case 2: { ... }
> case @foo { ... }
> }
>
> does not!
Then write the switch as:
switch ( __ ) {
ca
1 - 100 of 113 matches
Mail list logo
