Juerd <[EMAIL PROTECTED]> writes:
> Sick would be if <- were introduced to make the variable write-only ;)
Sicker still would be if - were introduced to make the variable
neither readable nor writeable. HTH.HAND.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,"[EMAIL PROTECT
Luke Palmer wrote:
On the other hand, Larry had a good point. Why couldn't we do:
=begin table
...
=end table
For some sufficiently simple ...? Obviously this gives the formatter
control over how the table is formatted, which is arguably a bad thing
since it won't be implemented (POD tools are mo
Maybe this train has already left the station, but I find myself
preferring Kwiki syntax to POD these days... any chance we could
use Kwiki with WAFL for the Perl 6 POD? That of course has
already got tables.
(Still bracketing with the =for ... =cut directives, though.)
Just a thought...
--
Pet
David Green writes:
> On 8/20/04, [EMAIL PROTECTED] (Luke Palmer) wrote:
> >So all the laziness goes into the array implementation. But you don't
> >even need to write your iterator fancily. If you just write your scalar
> >version of postcircumfix:<>, Perl will do the rest.
>
> So if you use an
Aaron Sherman writes:
> Also, you pointed out that my example was hard to read, but you only
> pointed out the particularly complex example (where I WANTED to
> demonstrate all of the complex cases), not the simple one. The general
> case would probably look like:
>
>H< Function | Returns >
> "AS" == Aaron Sherman <[EMAIL PROTECTED]> writes:
AS> Matthew Walton wrote:
>> Larry Wall wrote:
>>
>>> I suspect there's an argument that [0,0) ought to be considered undef
>>> (which would conveniently numerify to 0 with an optional warning).
>>
>> In the absence of a parad
Matthew Walton wrote:
Larry Wall wrote:
I suspect there's an argument that [0,0) ought to be considered undef
(which would conveniently numerify to 0 with an optional warning).
In the absence of a paradox value, undef would be fine there I think :-)
Too bad we don't have NaRN (Not a Random Number).
Luke Palmer wrote:
Aaron Sherman writes:
<> H< C<$_> | C<$x> | Type of Match Implied | Matching Code >
T< Any | CodeC<< <$> >> | scalar sub truth | match if C<$x($_)> >
Oh, and BTW: My mailer seems to have snuck some extra noise in there. I
think it got confused and tho
Larry Wall wrote:
On Fri, Aug 20, 2004 at 09:21:02AM +0100, Matthew Walton wrote:
: It would be nice if rand behaved a bit more sanely in Perl 6. I can
: understand the reasoning for making rand 0 produce between 0 and 1, but
: that doesn't mean I have to like it.
What makes you think there was
Larry Wall skribis 2004-08-20 13:31 (-0700):
> Unfortunately I'm not sure it passes the "Are there already too many
> ways to declare a sub?" test...
I'm not seeing it as another way. Technically, of course it is
different, but by the user, <-> and -> will probably be seen as one
thing, with one o
> > $_ $xType of Match ImpliedMatching Code
> > == = ==
> > Any Code<$> scalar sub truth match if $x($_)
How about making paragraphs that have a line like the divider one above
special? By simply parsing the
On 8/20/04, [EMAIL PROTECTED] (Luke Palmer) wrote:
>So all the laziness goes into the array implementation. But you don't
>even need to write your iterator fancily. If you just write your scalar
>version of postcircumfix:<>, Perl will do the rest.
So if you use an iterator in list context, Perl
On Fri, 20 Aug 2004, Larry Wall wrote:
> On Fri, Aug 20, 2004 at 10:07:02PM +0200, Juerd wrote:
> : I'm proposing
> :
> : for zip(@foos, @bars, @xyzzies) <-> $foo, $bar, $xyzzy { ... }
> : for %quux.kv <-> $key, $value { ... }
>
> That'd probably work on the keys only if the hash was decla
On Fri, 20 Aug 2004, Dan Hursh wrote:
> Peter Behroozi wrote:
>
> > I'm not particular to any of the verbs used yet, but maybe that's
> > because I don't think of the <> as a general iterator, but more of a
> > gobbler-type creature (and formerly a globber, too). Could we try:
> >
> > for $foo.fe
L:uke, just a note before I reply to you specifically: I understand your
concerns, and I have no interest in blurring the line between
presentation and markup, which I think ultimately is where your concern
comes from. In fact, if you re-read what I wrote (and what I write
below), you'll see th
15 matches
Mail list logo
