always assumed (e.g. in the implementation of Q::S and Perl6::Junctions)
that the junctive operators had an assignment form. Assignment-comma and
assignment-zip are harder to imagine uses for, but assignment-any,
assignment-all, etc. are *very* useful for incrementally building up complex
junctions.
Damian
e)
>
> However, I'll freely admit that I hadn't investigated much further
> to see if this might cause other syntax ambiguities.
I think the main problem there would be the *visual* similarity
between the two.
Damian
This useful construct would then be ambiguous:
$val = some_cond()
?? $arg1 // $arg1_default
// $arg2 // $arg2_default;
> ?? !! ain't bad either.
It's definitely much better that sabotaging the (highly useful) // operator
within (highly useful) ternaries.
Damian
o the type-only domain.
Yes, I'd certainly like that too. But not at the cost of turning // into a
bear-pit for the unsuspecting.
Damian
H. The arity of a given multi might be 3 or 4 or 5.
If *only* there were a way to return a single value that was simultaneously
any of 3 or 4 or 5.
Oh, wait a minute...
Damian
and later...
if constraints($value) {...}
> $a <= any($a, $b).
> any($a, $b) <= $b.
> Therefore, $a <= $b.
No. This is a simple fallacy. You're ignoring the inherent logical
asymmetry of the implicit alternative. Consider:
Luke is no smarter than (Luke or a rock).
(Luke or a rock) is no smarter than a rock.
Therefore Luke is no smarter than a rock.
Clearly a false conclusion. ;-)
But the logical error is made clearer when the distribution is made explicit:
Luke is no smarter than Luke or Luke is no smarter than a rock.
Luke is no smarter than a rock or a rock is no smarter than a rock.
Remove the false assertions (since nothing correct can ever be deduced
from a false assertion):
Luke is no smarter than Luke
a rock is no smarter than a rock.
But now the remaining assertions support *no* new conclusion.
Damian
make one. Because it doesn't
makes *sense* to even talk about an ordered set of junctions. Any more
than it makes sense to talk about an ordered set of vectors, or lists,
or regexes. Will you also be recommending that lists and regexes not be
values???
More seriously, since the ordered set's methods presumably *won't* use
(Item(+)Junction) type arguments, why will this be a problem? The
ordered set will never *see* junctions.
Damian
<( $ < @indents[-1] )>
{ pop @indents while @indents && $ < @indents[-1];
let @indents = (@indents, $);
}
}
rule samedent {
^^ $:=(\h*)
{ $ = expand_tabs($).chars }
<( $ == @indents[-1] )>
}
}
Damian
t;"}, q{0+} and q{bool} (a practice I strongly
recommend in "Perl Best Practices").
Finding useful and predictable defaults for the basic coercions on all
built-in types is a vital part of the design of Perl 6.
Damian
cified, but I believe it should be 42 (i.e. numerifies to the value)
say ?$pair; # true (because 42 is true)?
# true (because pairs are always true)?
Not yet specified but I believe it should be true because 42 is true
In summary: when applied to a pair, the value-coercing operators should coerce
the pair's value.
Damian
"
quite differently (i.e. as "interpolate a useful string representation of the
entire value").
More importantly, as we have already seen with regexes, inconsistent
numerification and stringification is an even more serious problem.
Damian
quot;]baz\n";
And what context does "foo{ $bar }" use?
Stringification, of course. No interpolation is occurring.
In my opinion, making the string value in interpolation different from
the value in Str context is madness.
It's dwimmery. Which often looks like madness until you realize that it's just
a reflection of how most hackers think. ;-)
Damian
Rather than addition Yet Another Feature, what's wrong with just using:
for @list ¥ @list[1...] -> $curr, $next {
...
}
???
Damian
ist) {
return [undef, @list[0...]] ¥ @list ¥ [EMAIL PROTECTED], undef]
}
for contextual( create_list_here() ) -> $last, $curr, $next {
...
}
The horror!!!
;-)
Damian
ctly as well as your "all but
illegible" solution did.
Also, there's a #4: modified state, which is hinted at but not really
covered by #3.
4 is not possible using the pointy sub syntax in any form, since all params to
pointy subs are always constant aliases.
Damian
'a'..'c' ;
@i6 = 1..6 ;
zip(@a3, @i3)# 'a', 1, 'b', 2, 'c', 3
zip(@i3, @i6)# fail
zip(100..., @a3, @i3)# 100, 'a', 1, 101, 'b', 2, 102, 'c', 3
zip(100..., @a3, @i6)# fail
Damian
ndef, 4
zip(1..6, @i3 but fill(3), @i4 but fill('?'))
# 1,1,1,2,2,2,3,3,3,4,3,4,5,3,'?',6,3,'?'
Damian
sting.
My recollection is that $Larry has previously said that this is not the
case...that adverbs are suffixed.
Damian
lists ought to produce
an error, unless the user specifies how to deal with the imbalance.
Damian
Anyway, I have said my peace, what do you all think?
I think there are serious problems with this proposal. For a start, it would
be very difficult to create *any* objects at all if the C class method
wasn't inheritable.
Damian
Driver::Qualified::drive
$perDUI.drive(); # calls &Driver::Disqualified::drive
$postDUI.drive(); # calls &Driver::Qualified::drive
Damian
which many mathematically inclined folks might find annoying.
(It also precludes intriguing possibilities like:
multi sub circumfix:«| >» ($q) { return Quantum::State.new(val => $q) }
which I personally would find irritating. ;-)
Damian
In his use.perl.org journal, Luke wrote:
> To be fair, Damian responded to my query, but he didn't answer my
> question. He gave more an example of how submethods are used, rather
> than why they are used.
Subroutines are useful inside classes, for factoring class-specific
attern syntaxes; i.e., :perl5 and :glob are shortcuts for
:syntax('perl5') and :syntax('glob') or something like that.
Agreed.
Damian
Larry wrote:
> But the language in the following lexical scope is a constant, so what can
> :syntax($foo) possibly mean? [Wait, this is Damian I'm talking to.]
> Nevermind, don't answer that...
Too late! ;-)
Regex syntaxes already are a twisty maze of variations, mostly
Luke wrote:
On 11/22/05, Damian Conway <[EMAIL PROTECTED]> wrote:
:syntax
:syntax
:syntax
:syntax
:syntax
:syntax
Aren't we providing an interface to define your own regex modifiers?
Sure. But it'd lead to much less namespace pollution
eq are communative: because that's the only thing that makes
sense. When you're comparing two apples (or an apple and a
handgrenade), it shouldn't matter which of the two is in your left
hand, and which is in your right.
Damian
tions. Or, more simply, only turn on block interpolation in a
non-interpolating string:
my $code = q:c{
package {$package_name};
sub {$sub_name} \{
return {$return_val}
\}
};
Damian
k the "entire rule" clause was intended to cover cases like
/ [ ]* /
where is indirectly quantified and therefore is an array of
match objects. We should probably reword it, or get a clarification
of what is intended. (Damian, @Larry: can you confirm or clarify
this for us?)
Sorr
sub data() returns Str {...}
The declarator is only needed if you want to "prefix" your return type
(presumably because you're pining for C/C++ ;-):
our Str sub data() {...}
Damian
mment
...
=end comment
form.
(And, yes, they nest correctly).
Damian
ent (design)
See www.dev.il/design/S25.pod
=end comment
=begin comment (etc. etc.)
>:-)
=end comment
Damian
PS: I'll have a draft of S26 for this list to pore over after Ingy and I
work on it at YAPC::Tokyo in just over a week's time.
t". ;-)
All that being said, the final syntax hasn't been nailed down yet,
there are certainly differences of opinion among the designers that
you might successfully drive a wedge into. :-)
But *please* give us a week or two for Ingy and I to release our proposal and
for %Larry{no
cially given that you can already write those:
"filename" ==> chmod(MODE)
==> chmod(MODE)
if you want the filenames out front.
Damian
-cut--cut--cut--cut--cut-
Partial Perl 5 implementation:
sub chmod {
my ($m
BOOL { [EMAIL PROTECTED] }
SCALAR { [EMAIL PROTECTED] }
LIST { @failed }
}
You haven't studied the Contextual::Return module closely enough. Lazy
evaluation of the different return contexts is precisely what it already does. :-)
Damian
lt-ins). It feels like
there's a more universal "status reporting from list-op" mechanism here, just
waiting to be generalized out.
Damian
w whitespace in dot operations is to put it after the
dot.
Damian
Dan Kogai wrote:
With that understood, I would welcome if we have a version of slurp()
which unconditionally returns a scalar.
That'd be:
~slurp $file;
:-)
Damian
ey };
foo$obj: $arg = $get_foo( $arg );
barb $obj: $arg = $get_barb($arg );
bazaar $obj: $arg = $get_bizarre( $arg );
Maybe we're trying too hard to let people have their postfix dotted space
(and eat it too).
Damian
.
##
say $*PROGRAM_NAME.slurp.elems;
##
That call to .slurp is in scalar context, since the result is immediately used
as an object.
This says 1 but
##
my @lines = $*PROGRAM_NAME.slurp; say @lines.elems;
##
says 3.
That .slurp is in list context.
Damian
;t
switch back to expecting a term here".
And the postfix Larry decided upon (rightly, I believe) was dot.
Damian
espace, no backtracking
rule :ratchet :words Skips whitespace, no backtracking
Using C and C as the typical grammar components would make
Perl 6 grammars *much* more accessible to those already familiar with
grammar-based parsing. And using C for "plain old backtracking regular
expressions" would make them much more accessible to those already familiar
with Perl 5 regexes.
Damian
@list, bar => 'baz';
for the indirect object syntax.
Damian
o. ?bar()
foo. +bar()
foo. *bar()
since they're highly misleading if you happen to miss the dot.
Damian
PS: While I can understand the appeal to laziness, I'm not at all convinced
by the argument:
> And it's a lot of work (many, many keystrokes!)
>
(easily alignable) indirect object syntax?
Is:
> $antler. .bar;
> $xyzzy. .bar;
> $blah. .bar;
> $foo..bar;
really so intolerable, for those who are gung-ho to line up the method names?
Damian
for the keywords and behaviour, I think the right set is:
Default Default
KeywordWhere BacktrackingSkipping
regex anywhere :!ratchet :!skip
rule grammars :ratchet :skip
term grammars :ratchet :!skip
I do agree that a rule should inherit properties from its grammar, so
you can write:
grammar Perl6 is skip(/[+ | \# | \# \N]+/) {
...
}
to allow your grammar to redefine in one place what its rules skip.
Damian
e real question should
be "are 'scans' useful enough to justify introducing context sensitivity
to the reduce operation?"
Amen!
Damian
ar rules and
non-grammar rules. Which is why the external rules (which don't act like
grammatical rules at all, but like standard backtracking non-skipping regexes)
need a different keyword (like "regex").
And removing the "term" keyword (or "token" or whatever) removes the obvious
syntactic marking of a fundamentally important semantic distinction, as I
discussed above.
I'm still utterly convinced my original three-keyword list is the right one
(and that the three keywords in it are the right ones too). Collapsing these
three clearly distiguishable concepts into one keyword and then requiring that
keyword be adverbially modified about 2/3 of the time, seems like a false
economy to me: a loss in readability *and* a signiciant increase in the amount
of code required. :-(
Damian
yself out of context:
But almost nobody knows what [the word] actually means, and of
those few only a tiny number of pedants actually *care* anymore.
So does it matter?
;-)
Damian
| \s*
| \s*
}
> following skippy behavior (and it always behaves the same no matter
> what the current :skip pattern is)
Damian
cut at a parser for that mark-up notation. The new Pod
looks very much like the old POD, only cleaned up and simplified.
Kinda like Perl 6 itself. Stay tuned. If I hear nothing more from the
design team, and if I can get the parser stable in the next week or
so, I'll post a new S26 here RSN.
Damian
t we already have both placeholders (above) and pointy blocks:
for @array -> $index, $value {
say "$index\t$value";
}
to achieve this task, and given that both mechanisms allow you to choose the
name of the counter variable (rather than being stuck with some unreadable
punctuation variable), I don't think we need a third mechanism for this.
Damian
>> But it can hardly be blamed for clarity.
>
> That's a little unfair.
"can hardly be blamed" -> "can easily be praised"
Apologies to Carl if I misinterpreted. I read it as:
"can hardly be blamed for (having) clarity"
;-)
Damian
alias of $index?
No. There's no such magic. I simply screwed up. I should have written:
for @array.kv -> $index, $value {...}
:-(
Damian
the Perl 5 version, since
I'll be able to take advantage of macros.
Damian
nd self-explanatory--CS term for this operation has
always been "filter", which is also currently used by Python, Scheme,
Haskell, and numerous other languages, so *if* we're going to change
it from "grep", we ought to change it to "filter".
Damian
Darren Duncan wrote:
So "filter" is now my preference for a new name, and if
"grep" is kept, then that can be an alias for it;
We've also had a policy of removing synonyms (e.g. "for"/"foreach"),
so I think we should have only one name for any one function.
Damian
label.
Personally, I don't have a problem with us keeping 'grep'. However, if we do
decide to change the name, I suspect 'keep' might be readable, short, SWIM,
and not confused with other operations:
my @evens = keep { $^num % 2 == 0 } @numbers;
Damian
Juerd wrote:
Which can also be written as:
do { do { say 1 if 1 } if 1 } if 1;
Sorry, no it can't. From S4
(http://dev.perl.org/perl6/doc/design/syn/S04.html#The_repeat_statement):
"Unlike in Perl 5, applying a statement modifier to a do block is
specifically disallowed
Which if
"Unlike in Perl 5, applying a statement modifier to a do block is
specifically disallowed..."
FWIW, I completely agree with Larry that multiple postfix modifiers are a bad
idea and would only serve impair the comprehensibility of code (even in the
cases where they're not ambiguous).
Damian
, there's this syntactic problem:
do { say "vale, munde asper"; mori(); }
if $lang eq 'Latinus';
As well as the fact that do..if has no discernable advantage in either
writability
or readability over:
if $lang eq 'Latinus' {
say "vale, munde asper"; mori();
}
Damian
The use case here is
do { .foo for @bar } if $baz;
But I guess you can always "protect" it with a parens:
(do { .foo for @bar }) if $baz;
Or just:
if $baz { .foo for @bar }
or even:
@bar».foo if $baz;
;-)
Damian
Before Christmas, as promised!
I have a 95% complete Perl 5 implementation of a parser for this, but it is
too large to fit in the margin. I may release the beta of that next week, once
I'm home from my travels.
Damian
-cut--cut--cut--cut--cut-
ndard Perldoc dialect.
You'll be able to flip into kwid mode (for Perldoc parsers that support it)
using:
=begin kwid
=end kwid
Damian
ame users start screaming about it, we can
mournfully point to the passage in the original spec and silently shake our
heads. ;-)
Damian
uld either still be
fatal, or they should warn-and-ignore.
Damian
stopped at S26.pod, line 1
would be preferable to actually rendering that Pod, no matter how badly.
Damian
ferent lexical scope?
Assuming the =cut wasn't there, the =head3 would be numbered, since you'd be
in the same lexical scope. Lexical scopes are defined by =begin..=end pairs,
not by the "chunking" of Pod within ambient code.
(Actually, I don't see any reference to =cut in this spec. Is it
still there or not?)
Not. :-)
Damian
e named Unicode or XHTML entities, use the C> code.
If the contents are not a number, they are interpreted as an upper-case
Unicode character name, or as a lower-case XHTML entity. For example:
Thanks for that.
Damian
ry much more readable 'zip' and 'minmax' are
to be replaced with 'ZZ' and 'MM', then I think that's a serious step
backwards in usability.
Damian
On 21/02/07, Damian Conway <[EMAIL PROTECTED]> wrote:
[Off-list]
Apparently not.
Just pretend I'm not here.
;-)
Damian
Thom Boyer wrote:
I never could find the Pod-to-XHTML'd version of S26 -- the document
attached to that email was S26.pod6, not S26.xhtml.
Attached.
I don't want to bug Damian, because obviously he has enough of life
"happening", as it were.
More than enoug
ks for your patience.
Damian
[recloak]
to:
for @files -> $file {
printf "%-70s %t %t %t\n",
$file,
$file <<~~<< (:r, :w, :x);
}
Damian
tests
don't require any YAML support either.
Special thanks to Ævar Arnfjörð Bjarmason for thoroughly investigating the
previous problems with the test suite, and to Matthew Wilson for SVNing the
previous version and offering to tackle the testing problems.
Damian
generating and inserting tables-of-contents
- Vastly improved robustness of XHTML translation
- Added option to allow XHTML translator to build complete documents
(thanks Nick)
Damian
least) a few weeks, as I will be
preoccupied with other projects.
Thanks again to everyone for the valuable feedback. Please keep it coming.
Damian
rt makes cascaded ternaries a safer, more
robust choice than if-elsif-else chains in many cases.
Damian
a null operation, as far as Pod is
concerned).
For all of the above reasons, I'm strongly convinced that the total separation
of Church (i.e. documentation of belief) and State (i.e. specification of
action) is as a good thing for programming languages as it is for nations. :-)
Damian
gt; `message object. May be undef as long as the message is
> `begin composed.
>
> .has $content_type = 'text/plain';
> }
>
> Damian, can you show how you would document the same code in POD6
> syntax to get a comparible short man-page?
Like so:
clas
tarts a Pod
block. Always.
To get the multi-line quote, you'd need:
say :to(END);
=begin POD
blah blah blah
=end POD
END
Damian
\=end POD
END
Damian
ersed code), as well as standardized parsing tools from converting a
source document to an internal representation.
These features (along with Perl 6's ability to parse Perl 6 source) will make
it vastly easier to build man-page generators.
[ Damian, we didn't change our opinion
to teach: "a = in column 1 is Pod"
* not context-sensitive: "a = in column 1 is ALWAYS Pod"
* easy for humans to identify: "is there an = in the first column?"
* easy for machines to parse: "is there an = in the first column?"
* easy to use: "put a = in column 1"
* easy to avoid"keep the = out of column 1"
I truly think it works better that way :-)
Damian
whatsoever learning that "A 'C' in the first column is a comment".
> There are other things to consider, and to me it looks like this
> design decision isn't based on what's easier for the Perl 6 programmer
> but what's easier for the implementors.
I assure you that that is categorically *not* the case (as I'll discuss
at length in a subsequent message).
Damian
ss::Contract, Class::Multimethods, Class::Std, Config::Std,
Contextual::Return, Filter::Simple, Getopt::Euclid, IO::Prompt,
Module::Starter, NEXT, Parse::RecDescent, Regexp::Common,
Smart::Comments, Switch, Text::Autoformat...etc., etc.
Indeed the term "a Damian module" is now widely
ian: as a person, as an
educator, and as an expert on Perl. I respect his opinion (even
when--as now--I strongly disagree with it) and I respect his right to
hold and express that opinion.
It was a mistake to publicly express my private dismay. I apologize to
anyone who was hurt or upset by my having done so.
Damian
iate-level representation for
interwoven code and Pod.)
Damian
-cut--cut--cut--cut--cut-
=head3 Ambient aliases
The C> formatting code specifies an B.
This is like a L, except
that the text that is inserted to replace the C> formatting code is
some
Ambient aliases
The A<> formatting code specifies an alias to an
ambient antecedent.
This is li
t still the Perl6 and POD6 parsers are
fully separate.
That's not the case. As Larry has confirmed recently, to each parser (perl6 or
Perl6::Pod::Parser) everything in a source file will be either Perl or Pod
(and never both). And the only place where the two parsers will disagree is
inside a Perl string that happens to contain a Pod block.
In the example you gave, both Perl 6 and Pod 6 would treat the line:
> =definition
> method eat(Food $meal) {...}
*only* as Pod. So those two lines are pure documentation, not executable code.
Damian
alternative, why not document it and
put it before the community for consideration and assessment? If it is
indeed better, I have no doubt we will happily steal it. Even if only
parts of your proposal are better, your technological distinctiveness
is sure to be assimilated. ;-)
Damian
Smylers reported:
I was with you right up until the mention of C<=encoding>; what's that
got to do with anything?
C&P bug. Patched. Thanks!
Damian
Juerd wrote:
Damian Conway skribis 2007-06-21 11:45 (+1000):
A dedicated OO documentation tool could certainly do a better job in that
case, I heartily agree. I'm looking forward to using one.
This dedicated OO documentation must be core, because Perl itself is
heavily OO.
Y
ant", without nailing down the specifics of how,
whilst another says "this isn't good enough", without clearly indicating what
would be.
What I was actually suggesting was that this design *isn't* set in stone, and
that the best way to convince Larry that the existing design could be better
is to actually offer a better design.
Damian
take the following argument list: A<(..)>
would look under such an alternative scheme?
Damian
Mark Overmeer sought to clarify:
* Damian Conway ([EMAIL PROTECTED]) [070621 23:54]:
Yes. I completely agree that such a tool not be standard and universally
Do you mean "must be" i.s.o. "not be"?
Oops. Indeed. Can't even claim it must have been a Freudian
ision not to
attempt a full alternative design (if anything, your estimate of it only
taking "weeks" is optimistic ;-), but unless someone is willing to step up and
suggest some specific improvements to the current proposal, how can we move
forward towards the best possible result?
Damian
your documentation tool can then analyze and
convert to whatever content and layout you prefer (including
non-semantic Pod that you can then feed into any of a dozen
back-ends).
Damian
s...a range of schemes
suited to different documentation goals, different paradigms, different source
code structures, and different readers.
Damian
the necessary syntactic extensibility and the essential
building blocks (parser, DOM, module support) required for the
proponents of each individual documentation philosophy to create a
mark-up system and supporting tools best suited to their specific needs
and objectives.
Damian
301 - 400 of 1296 matches
Mail list logo
