Jon Lang suggested:
> Start with the addition operator, '1 + 1'. Apply the reducing
> metaoperator to it so that it works syntactically like a function:
> '[+] 1, 1'. Instead of calling it, pass a code reference to it:
> '&[+]'.
No. &[+] isn't the Code object for [+]; it's the Code object for &
Mark J. Reed asked:
> So how is this:
>
>> Any infix operator (except for non-associating operators) can be surrounded
>> by square brackets in term position to create a list operator
>> that reduces using that operation:
>
> reconciled with this:
>
>> Any ordinary infix operator may be enclosed
Daniel Ruoso asked:
>> &prefix:<[+]>
>
> Is that really? I mean... [ ] is a meta-operator,
Sure. But once you "[]-meta" an infix operator, you get a prefix operator.
See http://perlcabal.org/syn/S03.html#Reduction_operators, which states:
"Any infix operator (except for non-associating opera
Larry mused:
> �...@a.mung
>
> the .mung could return
>
> A) a modified @a (treat @a as mutable)
> B) a new array (treat @a as immutable)
> C) a remapped array whose elements refer back to @a's elements
>
> Currently .rotate is defined as A, but I could easily switch it to B,
I, for on
Perl 6's approach to xor is consistent with the linguistic sense of
'xor' ("You may have a soup (x)or a salad (x)or a cocktail"), and also
with the IEEE 91 standard for logic gates. See:
http://ozark.hendrix.edu/~burch/logisim/docs/2.1.0/libs/gates/xor.html
for a concise explanation of both t
Mark J. Reed wrote:
> My understanding is that the P6 way to do that is to return a Capture
> containing the desired return values (which can lazily do things only
> when accessed) in the appropriate slots.
Return a Capture or a more heavily overloaded object, depending on how
fine a degree of co
Raiph Mellor wrote:
> Anyhoo, I'd love to see a session of brainstorming, with nitty gritty
> detail, about possible ways to get what you guys and Mark and I and
> perhaps others think we would like to see in the way of super tightly
> woven together comments and code, where said brainstorming in
Raiph Mellor hyperpunned:
> With this whiny man exchange ultimately having bourne supreme fruit,
> the apocalypse watch for the post damian weekend begins...
ARRRG!
Damian ;-)
Darren Duncan asked:
> But one thing I'm not sure whether or not it was addressed is regards to
> whether free-form documentation is still supported or can be effectively
> combined with embedding documentation into the places that it is
> documenting.
Yes and yes.
Normal Pod blocks weren't ment
Moritz wrote:
> However it seems we have to pay a price: each act of rendering a Pod
> file actually means executing the program that's being documented (at
> least the BEGIN blocks and other stuff that happens at compile time),
> with all the security risks implied. So we'll need a *very* good
>
Raiph commented:
> Couldn't the pod processing be encapsulated, perhaps in PGE/NQP, so
> that it could be reused in a different Parrot language, provided that
> said language supports declarators and comments, or even just comments
> (if one downgrades the impact of encountering an "attached" comm
Jonathan "Dataweaver" Lang enquired:
> Will ther be any ambiguity between Pod and wraparound operators that
> begin with =?
No. Lines that start with an '=' that is *immediately* followed by an
identifier are always Pod. If there's a space after the '=' it's always
an assignment. You could *creat
> Could we also get "=numbered" and "=term" directives that are
> equivalent to "=item :numbered" and "=item :term", respectively, for
> use with abbreviated blocks? E.g.:
>
> =numbered First Item
> =numbered Second Item
> =numbered Third Item
That's just:
=item # First Item
=i
Kyle suggested:
> Pod itself is a DSL.
Sure. But to allow arbitrary processing and rendering of Pod, a DSL
isn't enough.
> If we're committed to giving guns to books, can we default to having
> the safety on? Can it be so that 'perl6doc foo.pl' does not execute
> any code without an option to al
Jonathan "Dataweaver" Lang proposed:
> OK. Let me propose an alternative (which I expect will be immediately
> shot down):
BANG!
;-)
> Allow '=begin alias', '=end alias', and '=for alias' as special cases:
> the Perl parser makes an exception for them and doesn't treat them as
> the start or
Smylers pointed out:
>> * Hence it must always parsed using full Perl 6 grammar: perl6 -doc
>
> Having a multi-character option preceded by a single hyphen doesn't play
> well with bundling of single-character options...
You make many good points. Changed to: perl --doc
Thanks,
Damian
Raiph elucidated:
> Hmm. I was thinking Pod would be parsed by a P6/PGE grammar, one that
> could be relatively easily edited/extended to suit another context, because,
> I thought, it could then be made available as a stock --doc subsystem that
> all PCT based languages get more or less for free.
Jon Lang kept his promise:
> I promised some further thoughts; here they are:
Much appreciated.
> As written, declarator aliasing attaches the alias to a piece of code,
> and draws both the name and the alias from that. What about using a
> special case of the declarator block for this? That
Jon Lang elaborated:
> I don't think that there will be a problem. First, #=> is easy enough
> to distinguish from #=; I don't foresee any confusion.
I'm not so sure. #=> is a lot more like #= that =alias is. And the one
character of difference is on the non-significant (right-hand) side.
Need t
Jon Lang huh'd:
> Huh. Would you be able to do something like:
>
> =begin pod
> Welcome to $?FILE.
>
> ...and have it interpolate the file's name? Or would you need some
> special markup for this, such as:
>
> =begin pod
> Welcome to A<$?FILE>.
The latter. Variables are just too com
Darren Duncan wrote:
> pg 36 - About the "Perl Best Practices" book, you should be clear to
> mention that what is considered best practices has evolved significantly
> since that book came out, so teams can't simply agree on "We'll just follow
> PBP guidelines" and call it a day, but should stud
Darren Duncan wrote:
> So another proposal I have is to add to the slideshow mentions of the
> Enlightened and Modern Perl movements and where one can go to read more,
> this being supplemental to PBP.
With that suggestion I'd whole-heartedly concur.
> My own opinion is that the modern best way
Aaron Sherman asked:
> Should there be an explicit way to step this down to just parsing the bits
> that are called out as pod?
The original conception allowed for Pod to be independent of the
interleaved language. That has now been supplanted by a model that views
Pod as an integral part of Perl
yary asked:
> Can some concept/implementation of $=POD lazyness only incur the
> memory and performance hit on access?
IANAImplementor, but I suspect that virtually all of the performance hit
could be incurred at run-time, if it happened to be implemented that
way. The memory hit too, if necessar
Jon Lang asked:
> Not actually S26; but closely related: should $=POD and .WHY be
> read-only?
I had assumed so.
> Also, should there be other Pod variables besides $=POD?
> If so, which ones?
The original idea was that every Pod block with any kind of TYPENAME
would be available as $=TYPENAME
Carl observed:
> Partly that is because documentation isn't at the forefront of things
> that need to be implemented for Perl 6 to be useful, so it's kind of
> lagging behind the rest.
>
> Partly it's because Damian is the "owner" of that synopsis, and he
> practices a kind of "drive-by-updating"
>>> + rhyme((1,2),3,:mice) # rhyme has 2 arguments
>>
>> Should that say 3 arguments?
I believe so.
>> (If not, please can somebody clarify what
>> the 2 arguments are.)
>
> (1,2) and 3. Named arguments ("mice" in this case) are handled separately.
That interpretation is not consistent wi
Surely this is not a common-enough requirement to warrant a special
syntax.
At 80-columns, you can represent integers up to ninety-nine
quinvigintillion, nine hundred ninety-nine quattuorvigintillion, nine
hundred ninety-nine trevigintillion, nine hundred ninety-nine
duovigintillion, nine hundred
An issue came up in a class I was teaching today...
There doesn't seem to be an easy way to create a type that allows a set
of enumerated bit-flags *and* all the combinations of those flags...and
nothing else.
For example:
enum Permissions ( Read => 0b0001, Write => 0b0010, Exec => 0b0100 )
Larry concluded:
> I do freely admit that most Perlfolk are not used to thinking of
> permissions in terms of set theory. But as I said, we're looking at
> kind of a strange use case here, and perhaps not typical of the kinds
> of sets of small numbers that people will be using in the future.
Th
Larry mused:
> Alternatively, maybe there should be some way to express infinite sets.
> Not sure I like the idea of an infinite junction, but something resembling:
>
> subset PowersOf2 of Int where any(1,2,4...*)
> enum Perms of PowersOf2 ;
> say Exec; # 4
>
> Presumably the series in t
Daniel Ruoso pointed out:
> Using bitsets in Perl 6 is just as easy as using in Perl 5 -- which
> happens to be the same as using in C, but it's not C...
>
> constant PERM_WRITE = 0b0001;
> constant PERM_READ = 0b0010;
> constant PERM_EXEC = 0b0100;
> constant PERM_NAMES = { PERM_WRITE => 'Write
Jonathan Lang wrote:
> Wouldn't that be C< = 0...* >?
Indeed. Thanks for the correction.
> That said, don't we already have a means of assigning specific values
> to individual members of an enum? I forget the exact syntax,
The exact syntax is:
enum Perms [Read => 1, Write => 2, Exec =>
> We could make enum declarators even more like constant declarators
> by using a pseudo assignment. Then we could use = instead of parens:
>
> enum Perms = Z=> 1,2,4...*;
Hmm. That doesn't seem very like constant declarators. In a
constant declarator,
the constant appears on the lhs and
Personally, I'd prefer to see the English conventions carried over to
the use of general use of hyphen and underscore in identifiers in
the core (and everywhere else).
By that, I mean that, in English, the hyphen is notionally a
"higher precedence" word-separator than the space
(or than its intra-
John Siracusa commented:
> That's certainly an example of how hyphens might gain meaning in Perl
> 6 names, but I don't think I can endorse it as a convention. People
> can't even use hyphens correctly in written English. I have very
> little faith that programmers will do any better in code
Bu
Well, if we're not going to try to implement linguistically based
hyphenation/underscoriation rules (and I'd still argue that hyphenating
adjectives to nouns and underscoring everything else isn't exactly
rocket science), then I'd suggest we reconsider a radically different
proposal that was made o
Dan Brook wrote:
Will it be possible (or sane even) to bind a variable to an array slice
It *should* be, since it's possible (if ungainly) to do it in Perl 5:
use Data::Dumper 'Dumper';
@bar = (1,2,3);
*foo = (sub [EMAIL PROTECTED])->(@bar[1,0,3]);
print Dumper [EMAIL PROTECTED];
FWIW, we're aware of the problem.
I posed this very question to Larry a few months back, when I was writing E6.
We're still mulling over the correct answer. The last thought on the problem
that Larry's shared with me was that there may need to be a special case for
allowing a single &block param
Trey asked:
To take the E6 example of currying &part:
&List::Part::part.assuming(labels => <>)
One had to curry in C to be the same as it was defined in C<&part>
originally, i.e. C<< <> >>.
What if one wanted to curry in whatever the default is, i.e., assuming
"nothing" (different from "assum
Mark J. Reed wrote:
Is it possible with the new parameter declaration syntax to declare
a mandatory name-only parameter?
Probably. I think that the '?', '*', and '+ prefixes are abbreviations for
traits (C, C, C). So a named,
mandatory parameter would be:
sub foo($bar is named) {...}
Alternat
Nick Ing-Simmons wrote:
We have been discussing how to pass data to Tk callbacks.
In particular Entry widget validation routines.
There are a number of items that they _might_ be interested in
but a typical routine would only use a few.
Currently it passes them all as positional parameters.
One
Luke Palmer asked:
Presuming you can do:
(who => $name, why => $reason) := (why => $because, who => "me");
(from A6)
Does that imply that you can do:
sub routine (name => $nombre, date => $fecha) {...}
If we're consistent about lvalues of binds being the same as argument lists,
it prob
David Wheeler wrote:
Welcome back, Damian. Lo, how we've missed you and Larry these many long
months!
Thanks to everyone for the warm welcome. Just to give you an update, I've be
ill too (nothing nearly as serious as Larry...just a mild influenza and a
little light pneumonia ;-) and I've also b
Larry wrote:
: >(+$name, +$id) := getinfo();
:
: Err, no. Or at least: "Please, No!". ;-)
:
: That would certainly be a way cool abbreviation, but I suspect it would be
: a Very Bad Idea for unary plus to have two unrelated meanings out in the
: actual code. I suspect that the "named-only"
Larry wrote:
In theory I suppose you could have objects with module attributes:
class Foo {
has module .Bar { ... }
}
Just don't ask me what it means...
Of course, Larry's just joking there...he knows precisely what it means.
It means that every object of class Foo has its own pr
Luke Palmer started a discussion:
I see this idiom a lot in code. You loop through some values on a
condition, and do something only if the condition was never true.
$is_ok is a control flow variable, something I like to minimize. Now,
there are other ways to do this:
if (0..6 ==> grep -> $
Michael Lazzaro wrote:
So, just to make sure, these two lines are both valid, but do completely
different things:
return if $a;
Means:
if ($a) { return }
return if $a { $a }
Means:
if ($a) { return $a } else { return undef }
Damian
Luke Palmer wrote:
My C/C typo may
have misled you, but the original example pushed only if *none* of them
passed the condition.
Ah, sorry, I misunderstood.
So you want:
push @moves, [$i, $j];
for 0..6 -> $t {
if abs(@new[$t] - @new[$t+1]) > 3 {
pop @moves;
Seiler Thomas wrote:
So... lets call a function instead:
my $is_ok = 1;
for 0..6 -> $t {
if abs(@new[$t] - @new[$t+1]) > 3 {
$is_ok = 0;
last;
}
}
if $is_ok {
yada() # has sideeffects...
}
That's just:
for 0..6, 'ok' -> $
Joseph Ryan wrote:
Not to be a jerk, but how about:
my $is_ok = 1;
for @array_of_random_values_and_types -> $t {
if not some_sort_of_test($t) {
$is_ok = 0;
last;
}
}
if $is_ok {
yada() # has sideeffects...
}
That's just:
given @array_
David Wheeler wrote:
Isn't that just:
for @array_of_random_values_and_types, 'ok' -> $t {
when 'ok' { yada(); last }
last unless some_sort_of_test($t);
}
IOW, the topic is only 'ok' when all of the items in the array have been
processed
Unless, of course, the string 'ok'
Jonathan Lang wrote:
multi sub call ($a, $b: $c) {...}
multi submethod invoke ($a, $b: $c) {...}
multi method check ($a, $b: $c) {...}
Why do we suddenly need to append the "multi" keyword to "submethod" and
"method"?
So the compiler knows we really did mean for that (sub)method to be multip
I was reading over some code that used the MIDI module, and saw the
C method. I began wondering, how does one report the
error if he feels like it, but let the module report the error if not,
in a concise way.
What about something along the lines of a C statement modifier,
like:
$opus.write_to
Austin Hastings wrote:
try { $opus.write_to_file($file) }
err die "Couldn't write to $file: $!\n";
Is that C or C ?
It's C, which is low precedence C.
And if so, what's C and where can I find more on it?
http://dev.perl.org/perl6/exegesis/E04.html#Read_or_Die
Damian
Hmm. I think I may have missed Luke's point. Which was (presumably):
what if C<$opus.write_to_file($file);> validly returns C?
In which case I think we just fall back to:
try{$opus.write_to_file($file); CATCH {die "Couldn't write to $file: $!"}}
which is, after all, only 5 characters long
I'm very much in favour of heteronymifying scalar vs list comma too.
Or else eliminating one of them.
Schwern wrote:
"then" sounds too much like "if/then" which is confusing.
Why? "if/then" has never been Perl syntax.
It also doesn't convey anything about "evaluate the left hand side, ignore
th
Schwern observed:
A lot of people read "if (foo) { bar }" as "if foo then bar" in their heads.
I'm one of them. Its not a previous syntax thing, its a translation to
English thing.
Fair enough. It's not something I do myself, but I can see that many people
might prefer to.
This may be a conseq
Austin Hastings wrote:
role Dog {must bark();}
role Tree {must bark();}
class crossPerson {
method bark() {speak_sharply;}
}
class Trog does Tree does Dog {
method bark() {bark_like_a_trog;}
}
multi sub purchase(Dog $mansBestFriend) {...}
multi sub purchase(Tree $shrubbe
Larry mused:
But we also have the ambiguity with <<'' and friends, so maybe the real
problem is trying to make the << and >> workarounds look too much like
« and ». Maybe they should be :<< and :>> or some such. Maybe we
should be thinking about a more general trigraph (shudder) policy.
Nooo
Robin Berjon wrote:
Picking the HTML entity names is better than the Unicode ones as the
latter are way too long. They may not cover all the characters we need,
but we can make up missing ones in a consistent fashion.
I fear there are too many "missing ones" for that.
Any reason we couldn't acce
Robin Berjon wrote:
> I wasn't proposing to come up with short names for all the Unicode
> repertoire, just for the characters that are used as operators :) That
> shouldn't be too long, should it?
I'm not so sure about that. I can already see those mathematician/physicists
gazing hungrily at the
Robin Berjon asked:
>> Unicode has a *lot* of potential operators.
>
> Are all these for use in the core language though?
Not yet...but give us time! >;-)
> I was thinking about defining short names for the core stuff, and people
> can use the thirty letter names for more complicated things.
Yes
Here's a proposed syntax and semantics for C that tries to preserve the
(excellent) features of Uri's "on the right track" proposal whilst integrating
it into the Perl 6 design without multiplying entities (especially colons!)
unnecessarily.
Suppose C's signature is:
type KeyExtractor ::=
Joe Gottman asked:
If we use this signature, won't the code
sort ('foo', 'bar', 'glarch');
attempt to use the first parameter as a Criteria?
No. Because a string like 'foo' wouldn't match the first parameter's type.
Since sort has to be a multi sub anyhow, why don't we do
multi s
Uri wrote:
DC> If a key-extractor block returns number, then C<< <=> >> is used to
DC> compare those keys. Otherwise C is used. In either case, the
DC> returned keys are cached to optimize subsequent comparisons against
DC> the same element.
i would make cmp the default as it is now.
Err
Uri persisted:
> DC> How do you know that the values of %lookup are strings? DC> How
> would the optimizer know?
>
> because that would be the default comparison and the extracted key value
> would be stringified unless some other marker is used. most sorts are on
> strings so this would be a
The design team discussed "The Sort Problem" during yesterday's
teleconference. Here is Larry's decision: final, definitive, and unalterable
(well...for this week at least ;-)
-cut-cut-cut-cut-cut-cut
C in Perl6 is a global multisub:
multi su
Dave Whipp wondered:
@sorted = sort {-M} @unsorted;
One thing I've been trying to figure out reading this: what is the signature
of prefix:-M ? i.e. how does it tell the outer block that it (the
outer-block) needs a parameter?
It doesn't. As A6 explained:
http://dev.perl.org/perl6/apocalypse
Uri checked:
DC> @sorted = sort {$^a <=> $^b} @unsorted;
so because that has 2 placeholders, it is will match this signature:
type Comparator ::= Code(Any, Any) returns Int;
Correct.
i have to remember that placeholders are really implied args to a code
block and not just in the
Uri bemoaned:
DC> sort &infix:<=> @unsorted
my brane hertz!!
so that declares (creates?) an infix op as a code block?
No. C<< &infix:<=> >> is the name of the binary C<< <=> >> operator.
amazing how you and luke both came up with the exact same answer.
"Great minds..." etc. ;-)
> p6 synt
Joe Gottman asked:
How do you decide whether a key-extractor block returns number? Do you
look at the signature, or do you simply evaluate the result of the
key-extractor for each element in the unsorted list? For example, what is
the result of the following code?
sort {$_.key} (1=> 'a
Uri wondered:
DC> No. C<< &infix:<=> >> is the name of the binary C<< <=> >> operator.
so how is that allowed there without a block?
A Code object in a scalar context yields a Code reference.
Damian
Smylers wrote:
sort {$_.key} (1=> 'a', 10 => 'b', 2 =>'c');
There is nothing in the signature of the key-extractor to suggest that
all the keys are numbers, but as it turns out they all are.
Are they? I'd been presuming that pair keys would always be strings
Nope.
> and that the C<< => >>
Luke wrote:
I think you're forgetting what language you're talking about. Those are
numbers. After this statement:
$x = '345';
C<$x> is a number.
I don't think so. C<$x> is, of course, a variable. And what it contains after
that statement will depend on whether the variable is explicitly
Smylers wrote:
Oh. I'd been assuming that quote marks indicated strings, and that,
while a string containing only digits could obviously be treated as a
number (as in Perl 5), it wouldn't be one without being provoked.
Correct.
What about:
$x = '0345';
Is that a number?
Nope. A string (un
Gregor N. Purdy wrote:
Smylers already pointed out a few errors in the document, but
here are a few others I noticed:
* In "Why, how now, ho! From whence ariseth this?"
We have this near the top:
type FormArgs ::= Str|Array|Pair;
and this below:
type FormArgs ::
Smylers wrote:
The C<:page{:length}> sub-option (page 12) is described in the text as
having a default value of infinity but in a comment in the example above
of being 60. How so?
Is that the text normally isn't split into pages at all (so effectively
giving a single page of infinite length), but
Smylers wrote:
I take "valid identifier" to mean something which is syntactically valid
as an identifier, rather than something that is in the finite set of
identifiers which C actually uses.
Correct.
Although, as Larry pointed out, given the compile-time nature of option keys,
there's no reason
Gregor N. Purdy wrote:
In "From the crown of his head to the sole of his foot..." (clearly
a reference to a Gilligan's Island episode where Lovey said something
similar :), we have:
:header{ ..., odd => "Act, $act, Scene $scene...", ... }
and below, text indicating that it will
"prepend
Gregor N. Purdy wrote:
So, what I'm looking for is more explicit phrasing around "immediately
above". In the example, the column range for the overflow field is
exactly the same as that of the $method field in the prior "picture".
But, what does it do if it doesn't match *exactly*? Is it an error,
Gregor N. Purdy wrote:
The Exegesis mentions the Perl6::Slurp module, but I don't see it
on CPAN. Is it just a race condition?
Race condition. That is, I'm racing to get it out. That process is being
slowed by the fact that I'm still designing parts of the interface in line
with feedback from Lar
Smylers wrote:
Praise to Damian for Exegesis 7: the new formats sound very
well-thought-out, flexible, easy-to-use, and extensive -- as well as
being implemented and available right now. I've never used formats in
Perl 5, but I could see myself using Perl6::Form.
Thank-you.
I have a few questio
Smylers wrote:
The :fill option gets a brief mention on page 10, but I didn't spot it
anywhere else or being used in an example:
There is also a general C<:fill> option that sets the default sequence
for any filling that isn't otherwise specified.
That suggests there's a hierarchy of options
Gregor N. Purdy wrote:
In the section "He doth fill fields..." we see an example of Fill
Justification where two spaces fit between every word. This doesn't
give us an idea of how spaces are distributed if the number of
spaces needed does not divide evenly into the number of interstices.
Currently
Luke Palmer wrote:
Arn't there cases where the overflow field want to be bigger then the
first field? Something the ends up looking like:
LABEL: texttexttextexttexttext
texttextexttextetexttexttextte
xttexttexttexttexttexttextttex
where LABEL is in one field and text... is in an oveflow block?
Simon Cozens wrote:
It may take a *couple* of nights, but the elves will be at work.
Bless their pointy little hats/ears/beards/shoes! ;-)
Damian
Mark A. Biggar wrote:
Expect wouldn't that produce a extra blank line if $text is short?
Nope. Formats only generate text lines if at least one of their fields
interpolates at least one character.
Damian
Smylers asked:
* What happens if an undefined format is passed to C? I'm
presuming (and hoping) that's a run-time error.
Currently treated as "", with internal warnings. Probably should throw an
exception.
* In 'What a block art though...' (page 2) I don't think there's
supposed to
Mark A. Biggar wrote:
What if I want to interpolate an empty string and let the fill
characters work?
Then you interpolate a single fill character instead of the empty string.
Damian
Joe Gottman asked:
How do you put a literal '{' or '}' into a format string in Perl 6? Do
you use a backslash?
Yes, a backslash will quote anything (including backslash).
Note that you really only need to backslash '{', since '}' isn't special by
itself.
Damian
But that means I have to pre-process data lists that just happen to
contain empty strings so that they won't disappear on me.
Huh? An empty string already *has* disappeared on you. ;-)
> This seems to violate least surprise.
I'd be much more surprised if an empty string *didn't* disappear.
After
Would that need to be a double backslash in a double-quoted string, or
is there some new Perl 6 magic that keep it from being needed?
No, it would need to be a double backslash in a qq{..} string.
Fortunately qq{..} strings are very rarely needed in Cs.
Damian
I also don't expect
$x = '';
$y = " $x ";
to assign '' to $y either, but that's the equlvalent of what you say
form() will do.
I see your point.
I was more worried about arrays of items some of which are empty strings
and having items disappear out my repost because form() throws them
aw
I wrote:
[Perl6::Slurp] will most likely appear in the next 36 hours.
It's now on the CPAN.
Damian
Mark J. Reed wrote:
Should Perl6::Slurp be added to Bundle::Perl6?
Probably. Along with:
Perl6::Binding
Perl6::Classes
Perl6::Currying
Perl6::Export
Perl6::Form
Perl6::Interpolators
Perl6::Parameters
Perl6::Placeholders
Perl6::Tokener
> Or is that not being kep
Richard Nuttall suggested:
An alternative is to have "fill rightmost gaps" and "fill leftmost gaps" on
alternate lines. This produces more balanced looking columns, so they
don't all look heavier on the left.
That's a *very* interesting idea. What do people think?
For example:
Now is the w
Larry observed:
I think anyone who does full justification without proportional
spacing and hyphenation is severely lacking in empathy for the reader.
Well, it really depends on how neatly
one is able to write. It really isn't
that hard to create a fully justified
text that doesn't inflict pain on
Rick Delaney wrote:
> Why not something like
>
> Single-line Block
> === =
> [<<<] {<<<}
> [>>>] {>>>}
> [|||] {|||}
> ['''] {'''}
>
> which distinguishes the 2 main field types and gives us only the 4
> justifiers
Larry noted:
> There's a lot to be said for being able to write
things like:
[ & + ]
Now I'm supposing that & binds tighter than | as usual, so the
brackets wouldn't always be necessary:
& +
|
& +
FWIW, I'm strongly in favour of adding & to rules.
Indeed, if Larry were to gi
401 - 500 of 1282 matches
Mail list logo
