!perl6/one)
# !perl.yaml.org/super-none (longer type name, no format)
sane: !perl/super-none
- Larry
- Damian
- Brian
...
Urk.
It might be more forward thinking to allow any|all|one|none into the
yaml.org type repository.
That's my view.
Danmian
Larry mused:
On Tue, 29 Oct 2002, David Whipp wrote:
: Larry Wall [mailto:larry@;wall.org] wrote:
: > : unary (postfix) operators:
: > :... - [maybe] same as ..Inf [Damian votes Yes]
: > : > I wonder if we can possibly get the Rubyesque leaving out of
: > endpoints by s
could
overload and do whatever they liked with.
In creating my operator list I deliberated shied away from the unary and binary
multimorphic forms. But I do see Graham's point and would favour retaining
polymorphic unary C<^> at least.
Damian
-specific)
+ - force to numeric context
- - force to numeric context, negate
~ - force to string context
Correct?
that was what I was advocating, yes.
Damian
es?
Sure (for sufficiently complex values of simple ;-)
Here's how to find the love of your life:
$requirements = "tall" & "dark & "handsome"
| "old" & "rich"
| "Australian";
for <> -> $candidate {
my $traits = any( split //, $candidate );
print "True love: $candidate\n"
if $requirements eq $traits;
}
Of course, not everyone can hope to be lucky enough to meet an Australian,
but you get the idea. ;-)
Damian
orrected version instead:
$requirements = "tall" & "dark" & "handsome"
| "old" & "rich"
| "Australian";
for <> -> $candidate {
my $traits = any( split //, $candidate );
print "True love: $candidate\n"
if $requirements eq $traits;
}
Damian
Larry elucidated:
In general, for any type, how do you write
[$min .. $max - $step : $step]
when you don't even necessarily have subtraction defined? We don't know
how to do "z" - 1 in Perl 5, for instance.
Okay. I buy that.
Damian
x27;ve already said that appending to a
junk of the same type doesn't add "parentheses". This may be one
of those situations where the assignment operators are overloaded
separately from the basic ops.
I don't believe that's necessary or appropriate. I think it's
important to be able to "append" consistently, regardless of the
current value of the LHS.
Damian
%> always
meaning "hash" is exactly why I *wouldn't* like to see it!
Damian
ors rather than being illegal.
ETOOCLEVERBYHALF, IMHO. ;-)
I'd much rather see these common reductions be predefined C,
C, and C methods of Array, and the more obscure
and bizarre reductions be explicitly marked with a C:
my $countersequence = reduce {$^x-$^y}, @b
Damian
ty for increased semantic
complexity, but only really improves the readability of a
comparatively rare case.
Damian
ince that would involve giving up my first
vacation in two years, and consequently getting divorced...no.
;-)
Damian
$a + $b
that's equivalent to the multimethod call:
operator:+($a,$b)
This way you also get to choose which of the multimethods
gets applied for free...
Err, no you don't. The whole point of multimethods is that *they* choose,
based on the dynamic types of *all* their arguments.
Damian
will collapse in a 'mash everything together in
bitop fashion' way.
Yes. This was more-or-less the solution I proposed last week in
http://archive.develooper.com/perl6-language%40perl.org/msg11835.html
Damian
't we?
Hmmm...I wonder if one could then write:
$str = <<<>;
to make the heredoc terminator *really* stand out ;-)
> Or we could change here docs to vv"TAG"
or some such that points downwards to where the text actually is.
Urk.
Damian
agreement, because that's the plan, as I
understand it.
Great minds obviously think alike. That's what it *will* do.
Except it's:
$a + $b
that's equivalent to the multimethod call:
operator:+($a,$b)
So, in fact, totally different.
Well, yeah. But only at the syntactic level. Which, as Dan will tell you,
is completely irrelevant. ;-)
Damian
er
true or false (or some junction thereof).
$.is_plugged_in = true but false;
So that probably won't even parse.
Thank goodness!
Of course, this *will* parse:
$perplexing = false "true" but false;
>;-)
Damian
Ed Peschko asked:
ps - as an aside, are the apocalypses going to be backdated as changes to the
design come up?
Yes.
Or are the apocalypses just a first draft for more enduring
documentation?
Yes.
;-)
Damian
Interestingly, I find it just the opposite. The use of symbolic
operators makes it easier for me to differentiate the "nouns",
"verbs", and "punctuation" of a piece of code.
Damian
Or something similar '>>*'<<, [>*<], etc...
Much as I hate the notion of di- and trigraphs, this is a possibility.
Though I'd much rather we just allowed POD escapes (e.g. E and E)
in code.
And, yes, I'm aware that makes E*E incredibly ugly.
I'm rather *counting* on it, in fact ;-)
Damian
a syntax like:
method f ($self : $a is topic, $b) is given($c) { ... }
which clearly marks all the irregularities.
Not to mention that this more explicit syntax doesn't inject a spurious
pseudoparameter into the parameter list.
Damian
at's why I semi-seriously suggested replacing C by C<×>.
For some reason alphabetic operators (at least, those that are
pretending to be symbols) really bug me.
It would be really funny to use cent ¢, pound £, or yen ¥ as a sigil, though...
H. Given that a pound is worth more than a dollar, maybe £ is the sigil
for pairs.
;-)
Damian
which give the
same functionality.
Damian
other
than that it expects 3 scalar arguments. And Simon will be happ(y|ier)
that we've removed an exception.
and reinstituted the previous exception that a semicolon in an parameter
list marks the start of optional parameters! :-)
Damian
egardless of which character is used for
the purpose)
Damian
pposite of yacc.)
Is this a valid assumption?
Sure. It's a valid assumption for Perl 5:
sub print {
my ($print, @print) = @_;
${print}->{print}->print(@{print});
}
so I'm sure it will be for Perl 6 too.
Damian
inary ?^: !
Synonym for binary ?^^: !!
Incidentally, that leaves C<^> free to be the unambiguous vectorizing prefix
(modulo the C<^+=> ambiguity). I still vastly prefer C<»op«> though.
Damian
Which would take 2 elements from @a, and one from @b, until both
arrays were exhausted.
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 { ... }
Damian
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
ff of the ark\n"; }
my $arksubs = $twoByTwo | $threeByThree;
for @a, pick($arksubs);
It picks either the 2-by-2 state or the 3-by-3 state of the
$arksubs junction before the loop begins and then iterates
through @a accordingly.
BTW, that last line should probably use either:
pick($arksubs:)
or:
$arksubs.pick
Damian
ested that we might
allow POD escapes in code as well. Thus:
$campers = $a E<263a> $b # make $a and $b happy
Damian
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
?
The re-entry point isn't stored in the subroutine itself. It's stored
(indexed by optree node) in the current subroutine call frame. Which,
of course, is preserved when recursive iterator invocations recursively
yield.
Damian
r:
$foo = { print $^_ };
such that $^_ is effectively converted to
an 'is given($^_)'.
No, that doesn't work. The placeholder $^_ is
entirely unrelated to $_. Besides, what's wrong with:
$foo = sub { print $_ } is given($_);
???
Damian
sired:
%a_students = grep {.key ~~ /:i^a/} %grades;
or:
%a_students = grep {.key ~~ m:i/^a/} %grades;
or:
%a_students = grep sub($k,$v){$k ~~ m:i/^a/}, %grades.kv;
Damian
ubroutine did, or whether
the argument was a simple number, some species of junction,
or some mysterious object of a class derived from Num.
Damian
to test for, and "int" a
subclass?
The latter would be my expectation. Though it's C, not c, I believe.
Damian
:
sub square ( Num $n ) is same {...}
whereas others feel that:
sub square ( Num $n ) is memoized {...}
is more appropriate.
Damian
> Wow, I've never seen such a compact implementation of such a thing. I
> love you, Perl 6
:-)
Damian
ind of *anti*-placeholder.
Introducing that kind of inconsistency would be playing straight
into Simon's hands! ;-)
Why bother with currying?
You mean placeholders. Currying is something else entirely.
Why bother with the "it" concept? None of these are necessary.
They simplify code generation, but their more
general feature is enabling brevity.
Of usage, yes, but not necessarily of declaration.
Damian
>{$attr}\n";
}
You will. But they won't be entries of a hash. They'll be
separate variables and associated accessor methods.
So maybe something like this:
foreach my $attr (qw(foo bar baz))
{
print "$attr: $self.$attr()\n";
}
Damian
te!) C method, allowing something like:
for $this.HAS -> $attr {
print "$attr.key(): $attr.value()\n"
}
Or maybe not. ;-)
Damian
27;t end in i[zs]e (or end ou?r or [cs]e :-)
Except, of course, that many (near-)English speakers would be tempted to
spell your suggestion "cachable".
Hence I suspect that "cached" might be better. Then we will only have to
contend with those few remaining Romantic poets who will want to write
it "cachéd". ;-)
Damian
be sure what optimizations the compiler is
or isn't going to make, or even whether those optimzations will be the
same from platform to platform [*]. So I can never be sure what the
precise behaviour of my sub will be. :-(
Damian
[*] I can easily imagine architectures under which re-calling a p
refers to *the same containers* as
the corresponding ( interlaced keys and
values )
containers of %d.
property example :
e.g.
$a is constant = 1;
$b = 5;
($a,$b) := ($b,$a) ;
$b = 7 # error cannot change constant .
Correct.
another issue : how we know that always under '@a' array variable is
hanging array -type container ? Perl compiler creates and manipulate
containers . So when we declare
my @a = ( 1,2) ;
it creates appropriate container. we cannot manipulate containers
"directly" . only through names or something that refers them . so
perl always takes care that the declared correspondence between name
sigil ant type of container be preserved.
Unless, of course, we specifically ask that it not be preserved:
my @a is MagicArray; # @a implemented by MagicArray class, not Array class.
If needet it destrys
unnecessary contauiners and creates new.
anyway this is my flow of (un) -consciousness.
my feeling is that these things will be confusing for non-perl people.
But only until they are explained to them properly. ;-)
Damian
r. I think we should just agree
to disagree here, and let Larry decide.
Damian
notice that one of the Cs has been renamed to C.
And one of the Cs has become C. And I sincerely hope that the Cs
and Cs will be similarly disambiguated.
For several discussions of why this particular feature of natural languages
*doesn't* map well onto programming
hey're still two completely independent junctions.
Damian
erl modules are doing something
(typically a while loop) which tramples on $_, and so makes something go
wrong in their caller. (possibly several levels down)
Yes. That's why it's not the default in Perl 6, and you have to specify
a verbose and slightly ungainly property in order to get the behaviour.
Damian
Peter Haworth asked:
So to get the same yield context, each call to the coroutine has to be from
the same calling frame. If you want to get several values from the same
coroutine, but from different calling contexts, can you avoid the need to
wrap it in a closure?
I don't think so.
Damian
Piers Cawley wrote:
[Speculations elided]
Which is somewhat dependent on being able to do C.
Which you can't do, since C is compile-time.
Damian
also pondered general "adverbs", introduced by a colon, that modify
a subroutine, method, or operator call.
Damian
($def_foo) {
...
}
Or, if you stick with Perl5 convention, and I imagine this is what
people will expect from the builtins at least:
sub bar($foo; $baz) is given($baz) {...}
I think this should definitely be a compile-time error.
Damian
Cs)
with exactly one eigenstate serialize to that.
* Every other junction serializes to some representation of
its junctive type and internal states (e.g. "all(1,2)",
"none('Crosby', 'Stills', 'Nash', 'Young')", etc.)
Damian
y useful but
generally frowned on in a "don't do that" kind of way.
My sentiments precisely. Though it may only be frowned upon in a
"don't do that without documenting it" kind of way. ;-)
Damian
come up in practice, but I do see it
as an issue. The question is: are junctions more useful if they do
or don't collapse upon examination?
I'm fairly solidly convinced that it's better if they don't.
Damian
ween:
if $moe|$larry|$curly == $hurt {...} # i.e. any of them hurt
and:
if $moe|$larry|$curly != $hurt {...} # at least one not hurt
and also between:
if $moe&$larry&$curly == $hurt {...} # all hurt
and:
if $moe&$larry&$curly != $hurt {...} # none hurt
Damian
B~~C) && !(B~~D))
The logic is straightforward and the pattern not too hard to see: the type of
the left operand determines the "top level" (i.e. lower precedence)
logical connective whilst the type of the right operand determines the "bottom level"
(higher precedence) logical connectives.
BTW, the same table works for any boolean operation between junctives.
And, of course, it generalizes to any number of states on either side.
Damian
s ignored, or maybe optimized away).
Damian
r/bin/perl -w
$_ = ~time
when &morning() { print "good morning" }
Almost. You want:
when &morning { print "good morning" }
(i.e. no explicit call parens)
Damian
added as an external module.)
Junctions aren't quantum mechanical, so this doesn't apply.
Damian
and
install the derived grammar as the caller's parser.
Damian
ersions of the same
coroutine instantiated simultaneously, which strikes me as a terribly
useful thing.
Yep!
Perhaps we'd be better with an explicit coroutine instantiation call, like:
$foo = &bar.instantiate(1, 2, 3);
or something.
Ew!
(Or not, as it is ugly)
That'd be my vote! ;-)
Damian
ertainly expect that the order of execution
is undefined, since the states of a junction are not themselves ordered.
Damian
e caller's topic).
Finally, I would rather we did not have more than one syntax for specifying
default values for parameters.
I still think my original:
sub bar(; $foo = $topic) is given($topic) {...}
is the appropriate compromise.
Damian
# in a disjunction
Damian
instantiate(1, 2, 3);
@array = $foo.as_array;
Well, I think it has to be much less ugly than that! ;-)
Damian
if the iterator's C
method is invoked without arguments, use the old parameters;
if it's invoked with arguments, rebind the parameters.
And the use of the <$foo> operator to mean $foo.next cleans up
teh syntax nicely.
I must say I rather like this formulation. :-)
Damian
yield
them.
Nearly. Filehandles are just iterator objects, each attached to a
coroutine that reads lines constantly and yields them.
I'm really starting to like the concept of those co-routines :)
Likewise.
They elegantify stuff.
If you're going to talk Merkin, talk it propericiously:
"They elegantificatorize stuff"
;-)
Damian
Larry Wall wrote:
On Mon, Nov 18, 2002 at 08:05:47AM +1100, Damian Conway wrote:
: I still think my original:
:
: sub bar(; $foo = $topic) is given($topic) {...}
:
: is the appropriate compromise.
Won't fly. Referring to something lexical before it's declared is
a no-no.
I woul
Ken Fox wrote:
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?
Right.
The < must begin the circumfix <&
filehandle-ish objects that happen to also stringify to the command-line
strings. Hm.
Proposal:
Seemed very complex to me.
That's "elify", to wit:
"Z'at elify the code?"
"Elify - no."
Damian
pass a junction. Suppose I
want to pass a junction to a subroutine instead of calling the sub with
each value of the junction... how would I do that?
Tell the sub that it's expecting an undistributed junction as its argument:
sub foo($param is junction) {...}
Damian
ates over them. (Potentially ad infinitum)
The C loop is still single-threaded, only the values it's iterating
are multiplexed.
And here I thought Quantum INTERCAL was a joke... :)
Junctions Aren't Quantum.
Damian
o C
returns a new Iterator object.
The solution is very simple, of course:
my $nextfib = ;
but we might want to contemplate issuing a warning when someone calls
an argumentless coroutine within a scalar context <...>.
Damian
r
coming from the author of "C++ Resyntaxed". Did the immodest
proposal fix < <> > syntax? ;)
But of course! In SPECS, type parameters live in unambiguously
nestable (and yacc parsable) <[...]> delimiters.
Damian
ot;
"c">>;
Likewise.
Is it illegal now to use quotes in qw()?
Nope. Only as the very first character of a <<...>>.
So any of these are still fine:
print << "a" "b" "c" >>;
print <<\"a" "b" "c">>;
print «\"a" "b" "c"»;
print qw/"a" "b" "c"/;
Damian
e when given a junction.
I've thought about it at considerable length, and played around with
the Q::S module. I concluded that passing junctions into subroutines
by default is a Very Bad Idea. The reason, as Luke has already pointed
out, is that junctive logic is different from scalar logic. So most
subroutines won't be able to "accept anything and DWIM" anyway.
Damian
t so.
while {...} # I'm afraid to ask!
Usually an infinite loop. C returns a new iterator every time,
which <...> then calls C on.
Damian
David Wheeler asked:
while <$fh> {...}# Iterate until $fh.readline returns EOF?
That's a scalar context?
Sure. C always evaluates its condition in a scalar context.
Damian
Luke Palmer asked:
What was the final syntax for vector ops?
@a ≪+≫ @b
@a ≫+≪ @b
The latter (this week, at least ;-).
Damian
g $CALLER::_ ;-)
Though I think:
my sub foo($arg = $=) {...}
would be even better.
Damian
th
a junction of the two exceptions. ;-)
Damian
Iain 'Spoon' Truskett wrote:
@a ???+??? @b
@a ???+??? @b
Y'know, for those of us who still haven't set up Unicode, they look
remarkably similar =)
"Think Of It As Evolution In Action"
;-)
Damian
o guarantee which state of the junction is processed first
(whether they're being processed in parallel or series).
Damian
on't work.
And, yes, I could make it an optional argument, but them I have no way of
preserving my chosen interface. Or porting that code cleanly.
Besides all that, ($_ = $_) where $_ means something different from $_
is Just Plain Wrong. ;-)
Damian
t the backslash here too.
Maybe. It depends on whether Larry decides to make « and <<
synonyms in all contexts (in which case: no).
Damian
ms.
Perhaps. But we need to think through the issues so that we can eventually
move to threaded implementations without changing the semantics.
Damian
"interface" : lazy array is an iterator
object "inside" Array interface :
That's one particular implementation of a lazy array, yes.
Another implementation is an array interface with an subroutine that
maps indices onto values. Perl 6 will undoubtedly need both,
and maybe others as well.
Damian
ust update the same iterator, so any "lazy array" bits
have to update as well.
It means that the lazy array will not contain the lines that were read
by the inner iteration. So the code will behave as expected (i.e. process
each line from the file exactly once).
Damian
hope not!
Damian
Larry wrote:
: But I think we'd definitely like to introduce \d.
Can't, unless we change \d to in regexen.
Which we ought to be very wary of, given how very frequently it's
used in regexes.
Damian
LF (conjectural)
Damian
ntuitive to have to write:
(@false, @true) := classify { $^x > 10 } @nums;
I think it's a small price to pay to avoid tiresome special cases.
Especially since you then get your purge/vrep/antigrep for free:
(@members) := classify {$_->{'quit'}} @members;
;-)
Damian
ther than 0. Perhaps
even the built-in types can just take a range property:
my @array is range(1...);
Surely, that would be:
my @array is domain(1...);
???
Damian
y much as a name for this built-in. Must be
the vaguely biblical association ;-)
Headed off in another direction, having a sub
distribute its results like this reminds me of:
... -> ...
Can arrays on the rhs of a -> ever mean
something useful?
Sure. It means that the key of the pair is an array reference.
Damian
Nicholas Clark mused:
I just had this thought - can I interpolate in there?
Something like
"\c[$(call_a_func())]"
Why not just:
"$(chr call_a_func()]"
???
Damian
for @input -> $v {
push ($v < 10 ?? @under :: $v > 20 ?? @over :: @in_range), $v;
}
Also, can I return superpositions (sorry, junctions), to provide
multiple classifications? Or would I return an array for that?
A (dis)junction ought to work there.
Damian
Michael Lazzaro wrote:
How would you do something like:
(@foo,@bar,@zap) := classify { /foo/ ;; /bar/ ;; /zap/ } @source;
Since I don't understand what that's supposed to do, I probably *wouldn't*
do something like it. What effect are you trying to achieve?
Damian
index:
(@foo,@bar,@zap) := part { /foo/ => 0, /bar/ => 1, /zap/ => 2 }, @source;
or even a arrayed form, when the corresponding index was implicit:
(@foo,@bar,@zap) := part [/foo/, /bar/, /zap/], @source;
Damian
1001 - 1100 of 1296 matches
Mail list logo
