on the current summary
1: string cat is an old and reliable horsehide drum. I've been
doing C programming recently, where you can concat two literal
strings by having no other language tokens between them. Really.
That's the real basis for repeating the suggestion of juxtaposition
as a string joining operator. Syntactic arguments can all be deflated
by retreating what gets recognized as a string juxtaposition to the
point where it is clear that other things are happenind when other
things are meant to happen. Besides, there's always join('',...).
2: deprecating bitwise ops. I've also been working with C++ recently
where the
bitwise ops, particularly shift-left, were completely overrun and are
rarely missed.
Multiple dispatch means the same syntax can mean completely different
things. A
more perlish solution to the situation might be, since bitwise ops are
used rarely, to
explicitly bring them in with a pragma.
{
use bitwiseops;
...
}
3: I propose "means" as a postfix macro indicator. Macros are not
allowed to alter
the blocking structure, theymust be block-sane (like Lisp, unlike C).
Tokens on both sides are the pieces that get replaced. Tokens and other
syntax on the
left that does not appear on the right is the pattern that will get
matched to invoke the
macro. The right hand side guides the rewriting.
No reserved begin and end markers are required because of the blocking
sanity
requirement. For example
for( initialize ; test ; increment ) body
means
{initialize ; while (test) {body ; increment }}
;
thanks
--
David Nicol, independent consultant and contractor 312 587
2868
"For every old blackboard there are now hundreds of new electronic
computers"
Re: on the current summary
> From: david nicol <[EMAIL PROTECTED]>
> Date: 15 Nov 2002 18:56:35 -0600
>
I don't know if you haven't been paying attention, or you're
summarizing what's happened. I'll assume the former. Forgive me if
I've misunderstood you.
>
> 1: string cat is an old and reliable horsehide drum. I've been
> doing C programming recently, where you can concat two literal
> strings by having no other language tokens between them. Really.
> That's the real basis for repeating the suggestion of juxtaposition
> as a string joining operator. Syntactic arguments can all be deflated
> by retreating what gets recognized as a string juxtaposition to the
> point where it is clear that other things are happenind when other
> things are meant to happen. Besides, there's always join('',...).
>
If you're saying that juxtaposition should be string cat, see Larry's
post on the subject. If you're saying that string I
juxtaposition should concatenate, that's more sane, but why if we
already have a cat? If you're saying juxtaposition is bad, good for
you.
>
> 2: deprecating bitwise ops. I've also been working with C++ recently
> where the
> bitwise ops, particularly shift-left, were completely overrun and are
> rarely missed.
> Multiple dispatch means the same syntax can mean completely different
> things. A
> more perlish solution to the situation might be, since bitwise ops are
> used rarely, to
> explicitly bring them in with a pragma.
Bitwise ops in their traditional form are depricated. They're
replaced by I-don't-know-what-godawful-symbol (I think .& and .|, but
I don't remember well). The | and & are junction constructors now
(which I think is fantastic).
> {
> use bitwiseops;
> ...
> }
>
> 3: I propose "means" as a postfix macro indicator. Macros are not
> allowed to alter
> the blocking structure, theymust be block-sane (like Lisp, unlike C).
>
> Tokens on both sides are the pieces that get replaced. Tokens and other
> syntax on the
> left that does not appear on the right is the pattern that will get
> matched to invoke the
> macro. The right hand side guides the rewriting.
> No reserved begin and end markers are required because of the blocking
> sanity
> requirement. For example
>
> for( initialize ; test ; increment ) body
> means
> {initialize ; while (test) {body ; increment }}
> ;
Ummm... why? Why not just grammar-munge or define a sub?
FYI, this macro thing has been discussed before, and failed to reach a
conclusion. People wanted the power of Lisp macros, but found it
would be hard to do because Perl has so much more structural
complexity than Lisp. C-like-macros (as this is) don't give a big
advantage in a spicy language like Perl. That is, unless you can come
up with a good advantage
Luke
Re: Continuations
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
Re: Superpositions and laziness
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
Re: Meta-operators
Timothy S. Nelson asked: Question: are there any plans to have user-defined meta-operators in perl6? Explanation: By meta-operators, I mean operators which operate on other operators (much as APL operators do to APL functions). Yes. The vectorizing notation (»OP«) is an example. Larry has also pondered general "adverbs", introduced by a colon, that modify a subroutine, method, or operator call. Damian
Re: Unifying invocant and topic naming syntax
Luke Palmer wrote:
My favorite was from ages ago:
sub bar(;$foo //= $_) {...}
I think that today that would be written more like this:
sub bar(;$foo) is given($def_foo) {
$foo = $def_foo unless exists $foo;
...
}
Though we might get away with:
sub bar(;$foo = $def_foo) is given($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
Re: More junctions
Deborah Ariel Pickett wrote:
Luke wrote:
$foo = 1 | 2 | 4
print $foo;
# Foo is now just one of (1, 2, 4); i.e. not a junction
Just a sanity check, but is this kind of behaviour something we still
want from junctions?
Perhaps the above should just print JUNCTION(0x1234) or something,
like the other built-in types do.
But in Perl 6, they *don't*. The serialize somehow (probably by calling
their C<.serialize> method).
And I suspect that junctiosn serialize as follows:
* Disjunctions (Cs) serialize to their eigenstates.
* Conjunctions (Cs) and abjunctions (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
Re: Unifying invocant and topic naming syntax
Andrew Wilson wrote:
It's the difference between this:
print;
and this:
print $_;
It is as far as I'm concerned exactly what topic is all about.
Exactly.
It let's you write subroutines that behave like builtins with respect
> to $_. I think it's generally intended to be used like so:
sub my_print is given($default) {
my @args = @_ // $default;
...
}
i.e. only doing stuff with $_ if no explicit parameters are passed.
I would expect that to be by far the most common use of C.
I don't think that'll be a massive problem with this. It's not the same
thing at all because $_ is now lexical it's not passed to stuff you call
unless it specifically asks for it. This will eliminate the trampling
over $_ several levels down. Needlessly messing with caller's $_ will
become like not using strict or warnings. Occasionally 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
Re: Continuations
At 8:31 AM +1100 11/17/02, Damian Conway wrote: 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. I dunno. One of the things I've seen with coroutines is that as long as you call them with no arguments, you get another iteration of the coroutine--you actually had to call it with new arguments to reset the thing. (Which begs the question of what you do when you have a coroutine that doesn't take any args, but that's a separate issue) OTOH, forcing a closure allows you to have multiple versions of the same coroutine instantiated simultaneously, which strikes me as a terribly useful thing. Perhaps we'd be better with an explicit coroutine instantiation call, like: $foo = &bar.instantiate(1, 2, 3); or something. (Or not, as it is ugly) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: More junctions
Luke Palmer wrote:
sub foo($x) {
if ($x != 4) {
print "Not four\n";
}
if ($x == 4) {
print "Four\n";
}
}
sub oof($x) {
if ($x != 4) {
print "Not four\n";
}
else {
print "Four\n";
}
}
If given 3 | 4, foo would print "Not Four\nFour\n", while oof would
print "Not four\n".
Maybe not. We're still pondering the interactions of subroutines and
junctive arguments. There are two possibilities (naturally ;-):
1. Passing a junction as a subroutine argument calls the
subroutine (in parallel, perhaps in separate threads)
with each value of the junction, then juncts the results
(in which case both C and C print both strings).
2. Junctions are just passed in as any other scalar argument.
(in which case what Luke suggested is correct).
The reason that 1) might be a better semantics is that it makes
something like:
sub longest_common_substr($a, $b) {
my $substrs_a = substr $a, any(0,$a.end), any(0,$a.length);
my $substrs_b = substr $a, any(0,$a.end), any(0,$a.length);
my $common = $substrs_a == $substrs_b;
return $common >= any($common.states);
}
work correctly.
That is, we generally want C to produce C.
In those cases where the junction *should* be passed into the subroutine
(primarilyboolean predicates, I suspect), that would have to be marked
explicitly:
sub even ($x is junctive) { # Allow C to work on junctions too
return $x % 2 == 0;
}
Note that C would work for regular scalars too, since they can be
considered a degenerate case of a disjunction (or of a conjunction or
abjunction, for that matter).
I don't know how much this would 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
Re: More junctions
Brent Dax wrote:
More simply, !($x == 4) is no longer exactly equivalent to ($x != 4).
Correct. Junctive algebra and logic is slightly different. yet another
reason not to allow junctions to seep into subroutines by default.
Actually, this suggests to me a flaw in the != operator, not a flaw in
junctions. We should probably make != exactly equivalent to the
negation of ==; this implies that when != gets a junction the type of
junction is reversed (any becomes all, all becomes any).
I don't think so. I think it's important to preserve the useful
intuitive distinction between:
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
Re: More junctions
On Saturday, November 16, 2002, at 04:52 PM, Damian Conway wrote:
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
Although I admit I don't mind the lack of space on either side of the
C<|> operator, it bugs me with the C<&> operator. Couldn't C<&$larry>
in the above snippet dereference a code reference? I really hope that,
stylistically, we'll more often see code like this:
if $damian | $larry | $dan == $hurt {...} # i.e. any of them hurt
if $damian & $larry & $dan == $hurt {...} # all hurt
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Re: Control Structures I: given
Scott Duff essayed:
So, I was all set to show how this could work with junctions, but then
I realized that I don't understand them well enough, so here's what I
came up with:
$j0 = $that_happens | $that_doesnt_happen;
$j1 = !$that_happens | !$that_doesnt_happen;
given ($this) {
when $j0 ~~ $that_happens { ... }
when $j0 ~~ $that_doesnt_happen { ... }
when all($j0) { ... }
when any($j0) { ... }
when any($j1) { ... } # "some" Rare, I expect
when none($j0) { ... }
}
Is that right?
Not quite. The first problem is that if either of the first two C
fire, we immediately break out of the C. There will probably be
a lexical pragma to reverse that default behaviour.
The other problem is that your using junctions of junctions, which have
quite different semantics.
Here's some code that has (what I construe to be) the desired behaviour:
@possible_states = ($that_happens, $that_doesnt_happen);
given ($this) {
use fallthrough;
when $that_happens { "Have a party" }
when $that_doesnt_happen{ "Sing" }
when all(@possible_states) {
# Do something
}
when any(@possible_states) {
# Do something else
}
when $_ !~ all(@possible_states) {
# Do something other
}
when none(@possible_states) {
# Do something however
}
}
> What happens when there's a
junction on either side of a smart match?
That depends (multimorphically) on the types of the junctions.
Here's a handy table:
all(A,B) ~~ all(C,D)--> ( A~~C && A~~D ) && ( B~~C && B~~D )
all(A,B) ~~ any(C,D)--> ( A~~C || A~~D ) && ( B~~C || B~~D )
all(A,B) ~~ one(C,D)--> ( A~~C ^^ A~~D ) && ( B~~C ^^ B~~D )
all(A,B) ~~ none(C,D) --> (!(A~~C) && !(A~~D)) && (!(B~~C) && !(B~~D))
any(A,B) ~~ all(C,D)--> ( A~~C && A~~D ) || ( B~~C && B~~D )
any(A,B) ~~ any(C,D)--> ( A~~C || A~~D ) || ( B~~C || B~~D )
any(A,B) ~~ one(C,D)--> ( A~~C ^^ A~~D ) || ( B~~C ^^ B~~D )
any(A,B) ~~ none(C,D) --> (!(A~~C) && !(A~~D)) || (!(B~~C) && !(B~~D))
one(A,B) ~~ all(C,D)--> ( A~~C && A~~D ) ^^ ( B~~C && B~~D )
one(A,B) ~~ any(C,D)--> ( A~~C || A~~D ) ^^ ( B~~C || B~~D )
one(A,B) ~~ one(C,D)--> ( A~~C ^^ A~~D ) ^^ ( B~~C ^^ B~~D )
one(A,B) ~~ none(C,D) --> (!(A~~C) && !(A~~D)) ^^ (!(B~~C) && !(B~~D))
none(A,B) ~~ all(C,D) --> (!(A~~C && A~~D)) && (!(B~~C && B~~D))
none(A,B) ~~ any(C,D) --> (!(A~~C || A~~D)) && (!(B~~C || B~~D))
none(A,B) ~~ one(C,D) --> (!(A~~C ^^ A~~D)) && (!(B~~C ^^ B~~D))
none(A,B) ~~ none(C,D) --> !(!(A~~C) && !(A~~D)) && !(!(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
Re: String concatentation operator
Dan Sugalski pondered: What does: > $foo = any(Bar::new, Baz::new, Xyzzy::new); $foo.run; do? Creates a disjunction of three classnames, then calls the C<.run> method on each, in parallel, and returns a disjunction of the results of the calls (which, in the void context is ignored, or maybe optimized away). Damian
Re: Unifying invocant and topic naming syntax
Acadi asked:
> Just ( my ) terminology clean-up : in this example sub{ } is implicit
> topicalizer
No. It isn't a topicalizer at all.
> ( it does not set $_ explicitly )
Or implicitly.
> and you are setting $_ for perl .
Yes.
> that's why you can use "when" .
Yes.
is this valid ?
(morning() is function that analyse stringifyed time )
#!/usr/bin/perl -w
when ~time ~~ &morning { print "good morning" }
Yep. If C is given a boolean, it acts like an C
(except for the automatic C at the end of its block.
and also
#!/usr/bin/perl -w
$_ = ~time
when &morning() { print "good morning" }
Almost. You want:
when &morning { print "good morning" }
(i.e. no explicit call parens)
Damian
Re: Hmm...
Austin Hastings pondered:
my $outfh = all(@input_handles);
while (<$outfh>) print;
No. Apart from the bug (leaving off the braces around the C...spot
the C hacker! ;-), this reads from each of the @input_handles and returns
a conjunction of the values that were read. The print then serializes the
conjunction and prints it. But serialization of a conjunction probably
involves putting an "all(...)" around its states.
You'd get *closer* to the desired behaviour with:
my $outfh = any(@input_handles);
while <$outfh> { print; }
because the serialization of a disjunction is just the list of
states. However, junctions don't guarantee the order of their
states so your interleaving might be messed up. Moreover, they
*do* guarantee uniqueness of their states, so any lines that
happened to be identical in two or more files would appear only
once. :-(
What you want here is probably just:
print zip »readline« @input_handles;
> Do junctions know about the origins of their components?
No.
Is "preserving order" a meaningful concept?
No.
(Especially in light of entanglement, which will require origin
> info if it is to be added as an external module.)
Junctions aren't quantum mechanical, so this doesn't apply.
Damian
Re: is sigil user - extensible ? Was: UTF-8 and Unicode FAQ, demos
Acadi asked: is it possible to extend the perl sigil behaviour . Yes. that is , one day somebody decides it needs ¢ as sigil for certain class of variables . will it be possible to do . ( without rewriting the whole perl ) Yes. Just inherit the standard Perl grammar, extend the C rule and install the derived grammar as the caller's parser. Damian
Re: Continuations
Dan Sugalski wrote:
I dunno. One of the things I've seen with coroutines is that as long as
you call them with no arguments, you get another iteration of the
coroutine--you actually had to call it with new arguments to reset the
thing.
The formulation of coroutines I favour doesn't work like that.
Every time you call a suspended coroutine it resumes from immediately
after the previous C than suspended it. *And* that C
returns the new argument list with which it was resumed.
So you can write things like:
sub pick_no_repeats (*@from_list) {
my $seen;
while (pop @from_list) {
next when $seen;
@from_list := yield $_;
$seen |= $_;
}
}
# and later:
while pick_no_repeats( @values ) {
push @values, some_calc($_);
}
Allowing the list of choices to change, but repetitions still to be avoided.
OTOH, forcing a closure allows you to have multiple versions 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
