Re: String concatentation operator
On Thu, 2002-11-21 at 06:57, Mark Biggar wrote: > Martin D Kealey wrote: > > I want Perl to run 128 times faster on a 128 CPU machine... now I know > > that's not entirely realistic, but it should be able to run at least say > > 60 times faster. > > Amdahl's law applies here: "no amount of paralellism will speed up > an inheirently sequential algorithm" True in the abstract, but in practice in most languages an awful lot of algorithms that I inherently sequential get serialized by the compiler because it can't tell it's safe to do otherwise. This is where pure-functional or applicative languages can have a big performance win - because the compile almost alway I see that things are safe to parallelize. -Martin
Re: TERN-discuss mailing list finally available
david wrote: The brazen heresy continues... http://mail.nongnu.org/mailman/listinfo/TERN-discuss Are these people serious? What on earth is the point?
RE: Unifying invocant and topic naming syntax
Martin D Kealey:
# On Wed, 2002-11-20 at 15:01, Brent Dax wrote:
# > We need that capability if we're going to have lexically-scoped
# > exports:
#
# Whilst it would be useful for pragmatic modules to access
# anything and everything in the current compilation scope, I
# submit that access to dynamic scope should (in general) be
# more closely controlled... and of course the former can be
# used to implement the latter:
#
# use visible '$topic';
#
# no visible '$_';
if($error) {
require Carp;
import Carp: 'croak';
croak($error);
}
Are you suggesting this?
if($error) {
use visible '&croak';
require Carp;
import Carp: 'croak';
croak($error);
}
That'll add up rather quickly, and further is dangerously easy to subtly
screw up.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
"If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible."
--Ayn Rand, explaining how today's philosophies came to be
Re: TERN-discuss mailing list finally available
At 9:07 PM -0600 11/20/02, david wrote: The brazen heresy continues... http://mail.nongnu.org/mailman/listinfo/TERN-discuss Perl 5, or perl 6? -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
TERN-discuss mailing list finally available
The brazen heresy continues... http://mail.nongnu.org/mailman/listinfo/TERN-discuss
RE: Superpositions and laziness
Piers Cawley:
# So, how would one create a class which inherits from some
# other class when you don't know what said other class is
# until runtime?
AUTOLOAD! *ducks*
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
"If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible."
--Ayn Rand, explaining how today's philosophies came to be
Re: Unifying invocant and topic naming syntax
On Wed, Nov 20, 2002 at 04:20:07PM -0600, Me wrote:
: > $_ = 1; mumble { $_ = 2 }; print;
: >
: > will print 1 or 2?
:
: Least surprise, visually, is obviously 2.
:
: This would be true if bare blocks (even
: those passed as args) just pick up from
: the surrounding lexical context. And if
: that were true, mumble presumably could
: not do anything about this (without some
: as yet undefined language support).
Yes, that's the problem. A bare block would have to notice at run
time that it was called with unexpected arguments and unbind its
binding to the outer $_. That's probably not gonna fly.
: What does this mean:
:
: $_ = 1; mumble -> { $_ = 2 }; print;
:
: perhaps the '->' could imply that $_ /is/
: going to be private to the block somehow?
As it stands now, explicitly telling it there are no arguments would
have exactly the opposite effect, and bind $_ to the outer $_.
: Could mumble somehow be a continuation that
: alternated between generating values to be
: plugged in to the block and executing it?
Well, sure, doesn't need to be a continuation for that. Doesn't
even need to be a coroutine unless you plan to get the values one
by one.
: > sub mumble (&block) {
: > block()
: > }
: >
: > Oddly, if we make the first argument the
: > topic by default, the second block actually
: > gets &block as its topic. That's...strange.
:
: This would go away with the above scenario.
True, but I think C has to be able to wrap its own idea of $_
around the block at compile time somehow. Perhaps we need to distinguish
the type of a "thunk" from a "sub" in the signature of C.
sub mumble1 (Sub &block) { block($curtopic) }
sub mumble2 (Block &block) { block() }
Then
mumble1 { ... }
would compile to
mumble1 -> $_ { ... }
while
mumble2 { ... }
would compile to
mumble2 -> { ... }
forcing $_ to bind outward like a closure.
Possibly those are declared
sub mumble1 (&block(Scalar)) { block($curtopic) }
sub mumble2 (&block) { block() }
since code blocks are essentially typed by their signatures.
Larry
Re: Superpositions and laziness
Piers Cawley wrote:
C is compile-time.
So, how would one create a class which inherits from some other class
when you don't know what said other class is until runtime?
Use Perl5-ish classes, or an C.
Does this work:
class {
push @ISA, $class;
...
}
I sincerely hope not!
Damian
Re: Coroutines, continuations, and iterators -- oh, my! (Was: Re: Continuations elified)
Austin Hastings wrote:
for each $dance: {
^ note colon
1- Why is the colon there? Is this some sub-tile syntactical new-ance
that I missed in a prior message, or a new thing?
It's the way we mark an indirect object in Perl 6.
2- Why is the colon necessary? Isn't the "each $dance" just a
bassackwards method invocation (as C is to C<$fh.close()>)?
Yes. The colon is needed because the colon-less Perl 5 indirect object
syntax is inherently ambiguous. Adding the colon in Perl 6 fixes the
many nasty, subtle problems that Perl 5's syntax had.
I think this is called "avoiding the question". Now you've converted an
Iterator into an iterator masked behind an array, and asked the C
keyword to create apparently a "private" iterator to traverse it.
There's no second iterator. Just C walking through an array.
What's the value of C? Is this just a shortcut for
re-initializing the iterator?
No. It uses the original coroutine but rebinds its parameters to the new
arguments passed to C.
How is this going to work when the
iterator has opened files or TCP connections based on the parameter
list?
The original files or connections will be unaffected.
Furthermore, what's the syntax for including arguments to next in a
diamond operator?
I very much doubt there would be one. If you need to pass arguments,
you'd call C explicitly.
What's the difference between a lazy array and an iterator? Is there
caching?
Yes. A lazy array is a wrapper-plus-cache around an iterator.
What about the interrelationships between straight iteration
and iteration interrupted by a reset of the parameter list?
Resetting the parameter list doesn't interrupt iteration.
> Or does
calling $iter.next(PARAM_LIST) create a new iterator or wipe the cache?
No.
How do multiple invocations of each() interact with each other? (E.g.,
consider parsing a file with block comment delimiters: one loop to read
lines, and an inner loop to gobble comments (or append to a delimited
string -- same idea). These two have to update the same file pointer,
or all is lost.)
So pass the file pointer to the original continuation.
Some of questions about iterators and stuff:
1- Are iterators now considered a fundamental type?
Probably, since they're fundamental to I/O and C loops.
1a- If so, are they iterators or Iterators? (See 2b1, below)
class Iterator {...}
1b- What value would iterators (small-i) have? Is it a meaningful idea?
Depends what you mean by it. ;-)
2- What is the relationship between iterators and arrays/lists?
None. Except that some arrays/lists may be implemented using Iterators.
2a- Is there an C or C<.toList()> method?
Iterator::each.
2a1- The notion that Iterator.each() returns a lazy array seems a
little wierd. Isn't a lazy array just an iterator?
No. It's an array that populates itself on-demand using an iterator.
2b- Is there a C method? Or some other standard way of
iterating lists?
Probably.
2b1- Are these "primitive" interfaces to iteration, in fact
overridable? That is, can I override some "operator"-like method and
change the behavior of
while <$fh> { print; }
Sure. Derive a class from Iterator and change its C method.
2b2- Is that what C does in scalar context -- returns an
iterator?
No. C returns a lazy array, so in a scalar context it returns
a reference to the lazy array.
3- What's the difference among an iterator, a coroutine, and a
continuation?
Iterator: an object that returns successive values from some source
(such as an array, a filehandle, or a coroutine)
Coroutine: a subroutine whose state is preserved when it returns
such that it may be restarted from the point of previous
return, rather than from the start of the subroutine
Continuation: a mechanism for capturing the "what-happens-next"
at any point in a program's execution
BTW, there's rather a nice discussion of these three at:
http://mail.python.org/pipermail/python-dev/1999-July/000467.html
3a- Does imposing Damian's iterator-based semantics for coroutines
(and, in fact, imposing his definition of "any sub-with-yield ==
coroutine") cause loss of desirable capability?
No. Not compared to other potential coroutine semantics.
> 3b- Is there a corresponding linkage between continuations and some
object, a la coroutine->iterator?
Continuations can be used to implement virtually any control structure.
In a sense they link to everything.
3c- Is there a tie between use of continuations and use of thread or
IPC functionality?
Hmmm. I *suppose* a continuation could continue into a different thread.
That might be something worth proscribing. ;-)
3d- Conversely, what happens when continuations, coroutines, or
iterators are used in a threaded environment? Will there need to be
locking?
Yes. Threaded environments *always* require locking at some level.
4- Given the historical behavior of binding $_ to the actual data in
question (
Re: Unifying invocant and topic naming syntax
> $_ = 1; mumble { $_ = 2 }; print;
>
> will print 1 or 2?
Least surprise, visually, is obviously 2.
This would be true if bare blocks (even
those passed as args) just pick up from
the surrounding lexical context. And if
that were true, mumble presumably could
not do anything about this (without some
as yet undefined language support).
What does this mean:
$_ = 1; mumble -> { $_ = 2 }; print;
perhaps the '->' could imply that $_ /is/
going to be private to the block somehow?
Could mumble somehow be a continuation that
alternated between generating values to be
plugged in to the block and executing it?
> sub mumble (&block) {
> block()
> }
>
> Oddly, if we make the first argument the
> topic by default, the second block actually
> gets &block as its topic. That's...strange.
This would go away with the above scenario.
--
ralph
Re: Unifying invocant and topic naming syntax
> Date: Wed, 20 Nov 2002 12:11:52 -0800 (PST)
> From: Austin Hastings <[EMAIL PROTECTED]>
>
>
> --- Larry Wall <[EMAIL PROTECTED]> wrote:
> > ...
>
> > This might work now, presuming
> >
> > sub foo (;$_ = $=)
> >
> > (or whatever) is really a binding, and not an assignment. (That's
> > another reason why //= is *wrong*--it implies assignment.)
>
> Umm, that's what it was supposed to do.
>
> IOW: sub($param //= $=)
>
> means "if you don't get one, grab the value of $=."
More like "if you don't get one, bind to $="
Copying stuff should always be explicit, as it can take awhile. I'm
wondering how //= implies assignment while = doesn't. But I tend to
like = better anyway. And using := :
sub foo ($param := $=) {...}
Just feels wrong. I guess there was no point to what I just wrote...
> As opposed to sub($param ://= $=)
>
> which would be a horrible-looking way of getting something by
> reference.
Using an operator that doesn't exist.
> Which is also why I asked about value/reference semantics.
>
> Or is ";" supposed to be the "here be reference-args" delimiter? (I
> thought it meant "here be named parameters"...)
Neither. It means "here be optional parameters." Just like Perl 5.
Luke
Re: Continuations elified
Arcadi wrote:
> > > > while <$iter> {...} # Iterate until $iter.each returns false?
> you mean "Iterate until $iter.next returns false?"
Oops. Quite so.
what is the difference between the Iterator and lazy array ?
am I right that it is just "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
Re: String concatentation operator
Dan Sugalski wrote: Whups, misunderstanding there. I realize that we need to throw an exception (or a junction of exception and not exception) if evaluating one of the junction members. The question is whether we should evaluate them all regardless and then figure it out at the end, and what to do with currently running junction evaluations if we've spawned off multiple threads to evaluate them in parallel. I expect I'm getting a bit too Quantum here, though. Not at all. It's an important question, especially if the other threads have side effects. I suspect, however, that once one state of a junction throws an exception, we should just kill off the other states immediately. I'm thinking that we shouldn't parallelize junction evaluation by default. Dealing with threads has too many issues that must be dealt with to spring it on unsuspecting programs. Perhaps. But we need to think through the issues so that we can eventually move to threaded implementations without changing the semantics. Damian
Re: Continuations
Paul Johnson wrote: Is it illegal now to use quotes in qw()? Nope. Only as the very first character of a <<...>>. Paging Mr Cozens. ;-) It's just another instance of whitespace significance. print «\"a" "b" "c"»; Presumably without the backslash here too. Maybe. It depends on whether Larry decides to make « and << synonyms in all contexts (in which case: no). Damian
Re: Unifying invocant and topic naming syntax
--- Larry Wall <[EMAIL PROTECTED]> wrote: > ... > This might work now, presuming > > sub foo (;$_ = $=) > > (or whatever) is really a binding, and not an assignment. (That's > another reason why //= is *wrong*--it implies assignment.) Umm, that's what it was supposed to do. IOW: sub($param //= $=) means "if you don't get one, grab the value of $=." As opposed to sub($param ://= $=) which would be a horrible-looking way of getting something by reference. Which is also why I asked about value/reference semantics. Or is ";" supposed to be the "here be reference-args" delimiter? (I thought it meant "here be named parameters"...) =Austin
RE: Unifying invocant and topic naming syntax
On Wed, 2002-11-20 at 15:01, Brent Dax wrote: > We need that capability if we're going to have lexically-scoped exports: Whilst it would be useful for pragmatic modules to access anything and everything in the current compilation scope, I submit that access to dynamic scope should (in general) be more closely controlled... and of course the former can be used to implement the latter: use visible '$topic'; no visible '$_'; -Martin
Re: Unifying invocant and topic naming syntax
On Tue, Nov 19, 2002 at 03:09:40PM -0600, Allison Randal wrote:
: Larry wrote:
: > I'm trying to remember why it was that we didn't always make the first
: > argument of any sub the topic by default. I think it had to do with
: > the assumption that a bare block should not work with a copy of $_ from
: > the outside.
:
: I dug through the archives. We were considering allowing dynamic scoping
: of $_ across subroutine calls (for backward compatibility with p5), so
: we delayed any final call on whether subs topicalize their first
: argument. We've pretty much resolved the first: such an abuse of lexical
: scope should be explicitly marked.
:
: For consistency, I think the first argument of subs should be the topic by
: default.
This might work now, presuming
sub foo (;$_ = $=)
(or whatever) is really a binding, and not an assignment. (That's another
reason why //= is *wrong*--it implies assignment.)
I guess it's almost an epistemological issue. Suppose you see the
following general code:
$_ = 1;
mumble {
$_ = 2;
}
print $_;
How can you know whether it will print 1 or 2? It will depend on
both the signature of C, and the signature of the bare closure
passed to it. Things that are trying to look like C or C
obviously want to have a private $_. Things that are trying to look
like C or C will want to share $_ with the outside scope.
I suspect the bare block has to have a signature like (;$_ = $=) in the
absence of $^a etc. That means that a bare block always treats $_ as
pseudo-dynamic (by aliasing two lexicals). That means
$sub = {
$_ = 2;
};
$_ = 1;
$sub();
print $_;
would print 2.
But if the bare block always binds $_ inward, it's the wrapper that
actually decides the issue. For something if-like:
sub mumble (█ $_ = $=) {
block();
}
For something grep-like:
sub mumble (&block) {
block()
}
Oddly, if we make the first argument the topic by default, the second
block actually gets &block as its topic. That's...strange. People will
expect it (rightly or wrongly) to be initialized with the outer value,
even if it's just a copy. Hmm...need to think about this s'more...
Larry
Re: String concatentation operator
Martin D Kealey wrote: On Mon, 2002-11-18 at 18:10, Dave Whipp wrote: Why do we need to use preemptive threads? If Parrot is a VM, then surely the threading can be implemented at its level, or even higher. And what about *lower*? Like down among the CPUs? I want Perl to run 128 times faster on a 128 CPU machine... now I know that's not entirely realistic, but it should be able to run at least say 60 times faster. Amdahl's law applies here: "no amount of paralellism will speed up an inheirently sequential algorithm" -- Mark Biggar [EMAIL PROTECTED]
Re: String concatentation operator
On Mon, 2002-11-18 at 18:10, Dave Whipp wrote: > Why do we need to use preemptive threads? If Parrot is a VM, then surely > the threading can be implemented at its level, or even higher. And what about *lower*? Like down among the CPUs? I want Perl to run 128 times faster on a 128 CPU machine... now I know that's not entirely realistic, but it should be able to run at least say 60 times faster. It's not that we necessarily want *preemptive* threads, but if we can't do that, we certainly can't do multiprocessor threads. -Martin
Re: Hmm...
Austin Hastings <[EMAIL PROTECTED]> writes: > --- Piers Cawley <[EMAIL PROTECTED]> wrote: >> Austin Hastings <[EMAIL PROTECTED]> writes: >> >> > --- Piers Cawley <[EMAIL PROTECTED]> wrote: >> >> I wonder what would happen if you had a junction of >> >> continuations. Producing something practical is left as an >> >> exercise for the interested reader. >> > >> > Isn't this effectively "paste(1)" ? >> > >> > That is, >> > >> > my $outfh = all(@input_handles); >> > while (<$outfh>) print; >> > >> > for suitable tunings of chomp/append-newlines modes? >> >> Okay, I'm confused, how is that a junction of continuations? > > A diamonded FH is just an iterator over blobs from a file. And an > iterator is just a continuation. I thought an iterator was just a coroutine. Continuations are a little more 'basic' than that. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: Superpositions and laziness
Damian Conway <[EMAIL PROTECTED]> writes:
> 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.
So, how would one create a class which inherits from some other class
when you don't know what said other class is until runtime? Does this work:
class {
push @ISA, $class;
...
}
Admittedly it's not something you'd want to do often (though I have
done something like it several times in Perl 5...), but it's really
handy to be able to.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Unifying invocant and topic naming syntax
Me wrote: > Well, I could argue that c) already exists > in the form of passing parameters in parens. This reminds me of the Law of Demeter. It specifies what your methods should and shouldn't be able to do if you want to build a bright, shiny system that never has bugs, maintains itself, turns water into wine, etc. The essence is about limiting what you can access (and therefore screw up) from a particular scope. It's like a mild form of the "no side effects" policy of certain functional programming languages. I'm not sure how applicable it's going to be to Perl 6, but here's the view from 30,000 feet. Object Form of Law of Demeter - "Do not talk to strangers". Within a method, messages can only be sent to the following objects: 1. A parameter of the method, including the enclosing object (this or self); 1.1. For pragmatic reasons: a global object; 2. An immediate part object (computed or stored): 2.1 An object that a method called on the enclosing object returns, including attributes of the enclosing object; 2.2 An element of a collection which is an attribute of the enclosing object; 3. An object created within the method. Usenet Form of Law of Demeter - * You can play with yourself. * You can play with your own toys (but you can't take them apart), * You can play with toys that were given to you. * You can play with toys you've made yourself. Interested parties should Google[ law of demeter ] for the full story. A
