Re: temporization
On Mon, Mar 31, 2003 at 10:56:14AM +0200, Matthijs van Duin wrote: temp $foo := $bar; # temporarily bind $foo to $bar temp $foo = $bar;# temporarily assign the value of $bar to $foo I just realize 'temp $foo = 3' might just as well mean bind $foo to a new scalar and initialize it to 3 as temporarily assign 3 to $foo I guess it wasn't a nice idea anyway considering it'd change the meaning of temp based on which operator you let loose on it, which is rather evil and rude now that I think of it. -- Matthijs van Duin -- May the Forth be with you!
How shall threads work in P6?
Okay, I've been thinking about closures, continuations, and coroutines, and one of the interfering points has been threads. What's the P6 thread model going to be? As I see it, parrot gives us the opportunity to implement preemptive threading at the VM level, even if it's not available via the OS. Thinking about coroutines and continuations leads to the conclusion that you need a segmented stack (duh). But it also makes you wonder about how that stack interoperates with the threading subsystem. If there's one stack per thread (obvious) then you're committing to an overt threading model (user declares threads). If the stacks are allowed to fork (which they must, to support even Damian's generator-style coroutines) then there's the possibility of supporting a single, unified stack-tree which means that generators might contain their state across threads, and full coroutines may run in parallel. Anyway, I though the list was too quiet... =Austin
Re: This week's Perl 6 Summary
On Monday, March 31, 2003, at 07:39 AM, Piers Cawley wrote:
Argument initializations
Michael Lazzaro summarized the various different and proposed
assignment
operators available in Perl 6, including a proposed ::= for 'only
assign to uninitialized variables'. Michael wondered how these
could be
used in method signatures and proposed some changes to the
signature
system as set out in Apocalypse 6. People were dubious about this,
with
Damian saying I don't think that allowing 20 different types of
assignment in the parameter list of a subroutine actually helps at
all.
I'm not sure Michael is convinced yet.
Nah, I'm convinced that nobody likes the
putting-more-initializers-in-the-sig idea, so it can die. And I'm
convinced that we can't use ::= for the purpose of if-uninitialized,
because it's not consistent with the other meaning.
I'm still hoping rather desperately for a if-uninitialized op in
general, even if only for hashes, because the difference between
present but undefined and not present is rather crucial for some
common algorithms. But I have no idea what to propose calling it,
which is a bit of a pickle. :-/
$h{ k } = 'blah'; # always
$h{ k } //= 'blah'; # if not defined
$h{ k } ///= 'blah'; # if not exists ???
MikeL
Re: How shall threads work in P6?
On Mon, Mar 31, 2003 at 07:45:30AM -0800, Austin Hastings wrote: I've been thinking about closures, continuations, and coroutines, and one of the interfering points has been threads. What's the P6 thread model going to be? As I see it, parrot gives us the opportunity to implement preemptive threading at the VM level, even if it's not available via the OS. I think we should consider cooperative threading, implemented using continuations. Yielding to another thread would automatically happen when a thread blocks, or upon explicit request by the programmer. It has many advantages: 1. fast: low task switching overhead and no superfluous task switching 2. no synchronization problems. locking not needed in most common cases 3. thanks to (2), shared state by default without issues 4. most code will not need any special design to be thread-safe, even when it uses globals shared by all threads. 5. no interference with continuations etc, since they're based on it 6. less VM code since an existing mechanism is used, which also means less code over which to spread optimization efforts And optionally if round-robin scheduling is really desired for some odd reason (it's not easy to think of a situation) then that can be easily added by using a timer of some kind that does a context switch - but you'd regain the synchronization problems you have with preemptive threading. One problem with this threading model is that code that runs a long time without blocking or yielding will hold up other threads. Preventing rude code from affecting the system is one of the reasons modern OSes use preemptive scheduling. This problem is obviously much smaller in perl scripts however since all of the code is under control of the programmer. And if a CPAN module contains rude code, this would be known soon enough. (the benefits of Open Source :-) Another problem is the inability to easily take advantage of symmetrical multiprocessing, but this basically only applies to code that does heavy computation. I think if we apply the Huffman principle here by optimizing for the most common case, cooperative threading wins from preemptive threading. People who really want to do SMP should just fork() and use IPC, or use the Thread::Preemptive module which *someone* will no doubt write :-) -- Matthijs van Duin -- May the Forth be with you!
Re: This week's Perl 6 Summary
On Mon, Mar 31, 2003 at 10:09:43AM -0800, Michael Lazzaro wrote: I'm still hoping rather desperately for a if-uninitialized op in general, even if only for hashes, because the difference between present but undefined and not present is rather crucial for some common algorithms. Can you give some examples? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: How shall threads work in P6?
[EMAIL PROTECTED] (Matthijs Van Duin) writes: I think if we apply the Huffman principle here by optimizing for the most common case, cooperative threading wins from preemptive threading. Well, if you optimize for the most common case, throw out threads altogether. -- The bad reputation UNIX has gotten is totally undeserved, laid on by people who don't understand, who have not gotten in there and tried anything. -- Jim Joyce, former computer science lecturer at the University of California
Re: This week's Perl 6 Summary
On Monday, March 31, 2003, at 10:15 AM, Jonathan Scott Duff wrote:
On Mon, Mar 31, 2003 at 10:09:43AM -0800, Michael Lazzaro wrote:
I'm still hoping rather desperately for a if-uninitialized op in
general, even if only for hashes, because the difference between
present but undefined and not present is rather crucial for some
common algorithms.
Can you give some examples?
Sure, edited slightly from my last mail...
I suppose my own most common example is a hash representing a cache...
it's entirely possible for Cundef to be calculated and cached, but
that doesn't mean the cache entry is invalid and should be
recalculated every time -- a nonextant key would mean the cache entry
is invalid.
{
$cache.{ $key } = foo($key)# (1)
if not exists $cache.{ $key };
$cache.{ $key };
}
In my own experiences, code similar to the above is awfully common.
An assign-if-not-present form (at least for hashes, but in a magical
fairy world, for arrays/params/whatever, too) such as:
$cache.{ $key } ///= foo($key); # (2)
would be a lot cleaner, and maybe a little faster, since it's testing
C$cache.{ $key } once instead of -- what, 2.5 or 3 times, I guess,
depending on how you count it?
There are other examples -- working with external data sources,
primarily -- but they pretty much always boil down to the same general
concept. I basically want the shortest, *fastest* possible way to say
the caching code above given above.
MikeL
Re: How shall threads work in P6?
On Mon, Mar 31, 2003 at 08:13:09PM +0200, Matthijs van Duin wrote: I think we should consider cooperative threading, implemented using continuations. Yielding to another thread would automatically happen when a thread blocks, or upon explicit request by the programmer. It has many advantages: It has major disadvantages: I must write my code so each operation only takes a small fraction of time or I must try to predict when an operation will take a long time and yield periodicly. Worse, I must trust that everyone else has written their code to the above spec and has accurately predicted when their code will take a long time. Cooperative multitasking is essentially syntax sugar for an event loop. We already have those (POE, Event, MultiFinder). They're nice when you don't have real, good preemptive threads, but cannot replace them. It is a great leap forward to 1987. The simple reason is that with preemptive threads I don't have to worry about how long an operation is going to take and tailor my code to it, the interpreter will take care of it for me. All the other problems with preemptive threads aside, that's the killer app. We need preemptive threads. We need good support at the very core of the langauge for preemptive threads. perl5 has shown what happens when you bolt them on both internally and externally. It is not something we can leave for later. Cooperative multitasking, if you really want it, can be bolted on later or provided as an alternative backend to a real threading system. -- I'm spanking my yacht.
Re: This week's Perl 6 Summary
Piers Cawley writes:
is static?
Discussion of static/state variables continued. Arcadi Shehter wondered
if it made sense to attach but properties to closures. I confess I
didn't really understand what he was driving at. Austin Hastings and
Actually, I was confused , thinking that state declare trait (is
property ) of the closure , and that could explain examples before
that letter in the thread. But then it became clear that state declare
property ( but property ) of the closure - in the sence that it is born
anew every time closure is created. But then , it is still unclear ,
how one should look at closure - as a variable , as a value , or both.
also , From the post of Larry Wall ,
{...
state $a = INIT/FIRST/ENTER/... { ... } ;
...}
force evaluation of the whole closure at the time prescribed by
INIT/FIRST/ENTER/... .
this is similar to behaviour in perl5:
sub a{ my $x = shift ; my $y ; return sub { INIT{$y=1}; $x+$y } }
print a(1)-(), a(2)-() ; #print 22
so , yes, state creates but property of the closure , but its
initialization controlls when and how many times that closure will be
created.
arcadi
Re: How shall threads work in P6?
--- Dan Sugalski [EMAIL PROTECTED] wrote: At 8:13 PM +0200 3/31/03, Matthijs van Duin wrote: On Mon, Mar 31, 2003 at 07:45:30AM -0800, Austin Hastings wrote: I've been thinking about closures, continuations, and coroutines, and one of the interfering points has been threads. What's the P6 thread model going to be? As I see it, parrot gives us the opportunity to implement preemptive threading at the VM level, even if it's not available via the OS. I think we should consider cooperative threading, implemented using continuations. Yielding to another thread would automatically happen when a thread blocks, or upon explicit request by the programmer. It has many advantages: And one disadvantage: Dan doesn't like it. :) Well, there are actually a lot of disadvantages, but that's the only important one, so it's probably not worth much thought over alternate threading schemes for Parrot at least--it's going with an OS-level preemptive threading model. No, this isn't negotiable. More information please. =Austin
Re: How shall threads work in P6?
On Mon, Mar 31, 2003 at 10:50:59AM -0800, Michael G Schwern wrote: I must write my code so each operation only takes a small fraction of time or I must try to predict when an operation will take a long time and yield periodicly. Really.. why? When you still have computation to be done before you can produce your output, why yield? There are certainly scenarios where you'd want each thread to get a fair share of computation time, but if the output from all threads is desired, whoever is waiting for them probably won't care who gets to do computation first. Worse, I must trust that everyone else has written their code to the above spec and has accurately predicted when their code will take a long time. Both this and the above can be easily solved by a timer event that forces a yield. Most synchronization issues this would introduce can probably be avoided by deferring the yield until the next checkpoint determined by the compiler (say, the loop iteration) I think this is a minor problem compared to the hurdles (and overhead!) of synchronization. Cooperative multitasking is essentially syntax sugar for an event loop. No, since all thread state is saved. In syntax and semantics they're much closer to preemptive threads than to event loops. We need good support at the very core of the langauge for preemptive threads. perl5 has shown what happens when you bolt them on both internally and externally. It is not something we can leave for later. I think perl 6 will actually make it rather easy to bolt it on later. You can use fork(), let the OS handle the details, and use tied variable for sharing. I believe something already exists for this in p5 and is apparently faster than ithreads. I haven't dug into that thing though, maybe it has other problems again. No doubt you'll point 'em out for me ;-) Cooperative multitasking, if you really want it, can be bolted on later or provided as an alternative backend to a real threading system. I agree it can be bolted on later, but so can preemptive threads probable. As Simon pointed out, optimizing for the common case means skipping threads altogether for now. And I resent how you talk about non-preemptive threading as not being real threading. Most embedded systems use tasking/threading models without round-robin scheduling, and people who try to move applications that perform real-time tasks from MacOS 9 to MacOS X curse the preemptive multitasking the latter has. -- Matthijs van Duin -- May the Forth be with you!
Re: Conditional Creturns?
On Mon, Mar 31, 2003 at 11:04:35AM -0800, Michael Lazzaro wrote:
my bool $x = result_of_some_big_long_calculation(...args...);
return $x if $x;
Is there a way that doesn't require the named variable?
$_ and return given big_calculation();
or:
given big_calculation() {
return when true;
}
--
Matthijs van Duin -- May the Forth be with you!
Re: How shall threads work in P6?
On Mon, Mar 31, 2003 at 01:58:19PM -0500, Dan Sugalski wrote: Dan doesn't like it. :) Well, there are actually a lot of disadvantages, but that's the only important one, so it's probably not worth much thought over alternate threading schemes for Parrot at least--it's going with an OS-level preemptive threading model. If you can ensure me that the hooks will be available in critical routines (blocking operations) to allow proper implementation of cooperative threads in a perl module, then that's all the support from the parrot VM I need :-) I just hope you won't make my non-preemptive-threaded applications slower with your built-in support for preemptive threads :-) -- Matthijs van Duin -- May the Forth be with you!
Re: Conditional Creturns?
On Monday, March 31, 2003, at 11:18 AM, Matthijs van Duin wrote:
On Mon, Mar 31, 2003 at 11:04:35AM -0800, Michael Lazzaro wrote:
my bool $x = result_of_some_big_long_calculation(...args...);
return $x if $x;
Is there a way that doesn't require the named variable?
$_ and return given big_calculation();
or:
given big_calculation() {
return when true;
}
Don't those return Cundef, as opposed to the value of C$_? I.E.
wouldn't it be:
$_ and return $_ given big_calculation();
-or-
given big_calculation() {
return $_ when true;
}
MikeL
Re: Conditional Creturns?
On Mon, Mar 31, 2003 at 12:12:54PM -0800, Michael Lazzaro wrote:
Don't those return Cundef, as opposed to the value of C$_? I.E.
wouldn't it be:
$_ and return $_ given big_calculation();
-or-
given big_calculation() {
return $_ when true;
}
Personally I'd just use
return big_calculation();
and make sure that big_calculation() returns the right thing.
If you *really* needed the exactly semantics given above, you could put
big_calculation() in a wrapper that does it for you.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: How shall threads work in P6?
On Mon, Mar 31, 2003 at 11:58:01AM -0800, Michael G Schwern wrote: Off-list since this tastes like it will rapidly spin out of control. On-list since this is relevant for others participating in the discussion Classic scenario for threading: GUI. GUI uses my module which hasn't been carefully written to be cooperative. The entire GUI pauses while it waits for my code to do its thing. No window updates, no button pushes, no way to *cancel the operation that's taking too long*. OK, very true, I was more thinking of something like a server that uses a thread for each connection. Luckily I already mentioned that automatic yielding is not too hard. A timed that sets a yield asap flag that's tested iteration of a loop should work - maybe something with even less overhead can be cooked up. I hope this is not a serious suggestion to implement preemptive threads using fork() and tied vars. That way ithreads lie. Actually, ithreads are slower because they don't do copy-on-write while the OS usually does. fork() moves the problem to the OS, where bright people have already spent a lot of time optimizing things, I hope at least ;) I suppose how much faster it is to do things within the VM rather than using forked processes depends on how much IPC happens. In your GUI example, the answer is: very little, only status updates. The existing system you probably mean is POE No, I wasn't. I looked it up, it's called forks. Besides, it would be silly as Dan has already said Parrot will support preemptive multitasking and that's half the hard work done. The other half is designing a good language gestalt around them. OK, as long as it doesn't hurt performance of non-threaded apps I obviously have no problem with *supporting* preemptive threading, since they're certainly useful for some applications. But coop threads are more useful in the general case - especially since they're simpler to use thanks to the near-lack of synchronization problems. Simplicity is good, especially in a language like perl. And I resent how you talk about non-preemptive threading as not being real threading. My biases come from being a MacOS user since System 6. MultiFinder nightmares. Valid point (I'm also a long-time MacOS user), but cooperative multitasking isn't the same as cooperative threading. We're talking about the scheduling between threads inside one process; and we can avoid the lockup problem in the VM with automatic yielding. This makes most of the problems of cooperative threading disappear, while leaving the advantages intact. If we want to support real-time programming in Perl No, I was merely pointing out that it's not always a step forward for all applications. Some people made good use with the ability to grab all the CPU time you need on old MacOS. None of this precludes having a cooperative threading system, but we *must* have a preemptive one. must is a big word; people happily used computers a long time before any threading was used ;-) It looks like we could use both very well though -- Matthijs van Duin -- May the Forth be with you!
Re: Conditional Creturns?
On Mon, Mar 31, 2003 at 12:12:54PM -0800, Michael Lazzaro wrote:
On Monday, March 31, 2003, at 11:18 AM, Matthijs van Duin wrote:
Don't those return Cundef, as opposed to the value of C$_? I.E.
wouldn't it be:
$_ and return $_ given big_calculation();
-or-
given big_calculation() {
return $_ when true;
}
Oops, yes, you're right ofcourse
Sorry :)
--
Matthijs van Duin -- May the Forth be with you!
Re: Conditional Creturns?
--- Jonathan Scott Duff [EMAIL PROTECTED] wrote:
On Mon, Mar 31, 2003 at 12:12:54PM -0800, Michael Lazzaro wrote:
Don't those return Cundef, as opposed to the value of C$_?
I.E. wouldn't it be:
$_ and return $_ given big_calculation();
-or-
given big_calculation() {
return $_ when true;
}
Personally I'd just use
return big_calculation();
I started to suggest this myself, then realized that you might not want
it to return at all if the value is false. Maybe you're looking for the
first nonzero return in a set on inputs:
my $y;
for my $x (@data) {
return $y if $y = big_calc($x);
}
Otherwise, I'd *definitely* just
return big_calc();
__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
Re: How shall threads work in P6?
On Mon, Mar 31, 2003 at 07:21:03PM +0100, Simon Cozens wrote: [EMAIL PROTECTED] (Matthijs Van Duin) writes: I think if we apply the Huffman principle here by optimizing for the most common case, cooperative threading wins from preemptive threading. Well, if you optimize for the most common case, throw out threads altogether. Well, I almost would agree with you since cooperative threading can almost entirely be done in perl code, since they are built in continuations. I actually gave an example of that earlier. The only thing is that blocking system operations like file-descriptor operations need some fiddling. (first try it non-blocking fd operation, if that fails block the thread and yield to another; if all threads are blocked, so a select() or kqueue() or something similar over all fds on which threads are waiting) If the hooks exist to handle this in a perl module, then I think we can skip the issue mostly, except maybe the question what to include with perl in the default installation. -- Matthijs van Duin -- May the Forth be with you!
Re: Conditional Creturns?
Michael Lazzaro writes: Forgive me; a very minor style efficiency question... what would the canonical way to do this be, given what we know of Perl6? # the hapless, inefficient version: return result_of_some_big_long_calculation(...args...) if result_of_some_big_long_calculation(...args...); The obvious answers are this: my bool $x = result_of_some_big_long_calculation(...args...); return $x if $x; That does something different, in that it has coerced the result into a Cbool[*0]. So after the first line C$x can only be 0 or 1[*1]. And given that one of those states is false, the code becomes equivalent to: my bool $x = result_of_some_big_long_calculation(...args...); return 1 if $x; or simply: return 1 if result_of_some_big_long_calculation(...args...); However if you permit the function to return more than two different values (of which more than one are true) then it becomes a more interesting question. [*0] Do we have Cbool? I thought Larry wanted Cbit. [*1] Or whatever the two states of a Cbool are. Smylers
Re: Conditional Creturns?
On Monday, March 31, 2003, at 11:21 AM, Smylers wrote:
Michael Lazzaro writes:
Forgive me; a very minor style efficiency question... what would the
canonical way to do this be, given what we know of Perl6?
# the hapless, inefficient version:
return result_of_some_big_long_calculation(...args...)
if result_of_some_big_long_calculation(...args...);
The obvious answers are this:
my bool $x = result_of_some_big_long_calculation(...args...);
return $x if $x;
That does something different, in that it has coerced the result into a
Cbool[*0]. So after the first line C$x can only be 0 or 1[*1].
And
given that one of those states is false, the code becomes equivalent
to:
snip
However if you permit the function to return more than two different
values (of which more than one are true) then it becomes a more
interesting question.
My apologies, you are correct -- $x should _not_ be typed. It's the
more interesting question I'm asking.
On Monday, March 31, 2003, at 12:30 PM, Paul wrote:
I started to suggest this myself, then realized that you might not want
it to return at all if the value is false.
Yes, exactly:
sub foo(...args...) {
# We first attempt to get our return value the easy way.
# If successful (the resulting value is defined and true),
# just return that value.
my $x = baz(...args...);
return $x if $x;
# Still here? OK, then... we've got a lot more work
# to do before we can return a reasonable value
...
}
I'm looking for a Perl6 way to say that oft-repeated, oft-chained
two-line snippet up there without declaring the temporary variable.
Using Cgiven or Cwhen, maybe?
MikeL
Re: Conditional Creturns?
On Mon, Mar 31, 2003 at 02:58:12PM -0800, Michael Lazzaro wrote: my $x = baz(...args...); return $x if $x; I'm looking for a Perl6 way to say that oft-repeated, oft-chained two-line snippet up there without declaring the temporary variable. Using Cgiven or Cwhen, maybe? $_ and return $_ given baz(...args...); note that putting in front of a sub call won't work in perl 6 (that syntax is used to actually refer to the right sub var itself, iirc) -- Matthijs van Duin -- May the Forth be with you!
Re: Conditional Creturns?
Matthijs van Duin wrote:
On Mon, Mar 31, 2003 at 02:58:12PM -0800, Michael Lazzaro wrote:
my $x = baz(...args...);
return $x if $x;
I'm looking for a Perl6 way to say that oft-repeated, oft-chained
two-line snippet up there without declaring the temporary variable.
Using Cgiven or Cwhen, maybe?
$_ and return $_ given baz(...args...);
Yep. Or:
given baz(@args) { return $_ when true }
Which generalizes nicely to other definitions of success:
given baz(@args) { return $_ when defined }
given baz(@args) { return $_ when $_ 0 }
# etc.
note that putting in front of a sub call won't work in perl 6 (that
syntax is used to actually refer to the right sub var itself, iirc)
baz does refer to the Code object itself, as you say.
However, the bar(...) syntax *will* DWYM too. That's because:
baz(@args);
is just a shorthand for:
baz.(@args);
and baz in the scalar context of the . dereferencer returns a Code reference.
Damian
Re: Conditional Creturns?
On Tue, Apr 01, 2003 at 09:25:39AM +1000, Damian Conway wrote: baz does refer to the Code object itself, as you say. However, the bar(...) syntax *will* DWYM too. That's because: baz(@args); is just a shorthand for: baz.(@args); That's not what page 5 of Apoc 6 says: quote Note that when following a name like factorial, parentheses do not automatically mean to make a call to the subroutine. (This Apocalypse contradicts earlier Apocalypses. Guess which one is right...) $val = factorial($x); # illegal, must use either $val = factorial($x); # this or $val = factorial.($x); # maybe this. In general, don't use the form when you really want to call something. /quote -- Matthijs van Duin -- May the Forth be with you!
Re: Conditional Creturns?
On Monday, March 31, 2003, at 12:30 PM, Paul wrote:
I started to suggest this myself, then realized that you might not want
it to return at all if the value is false.
Yes, exactly:
sub foo(...args...) {
# We first attempt to get our return value the easy way.
# If successful (the resulting value is defined and true),
# just return that value.
my $x = baz(...args...);
return $x if $x;
# Still here? OK, then... we've got a lot more work
# to do before we can return a reasonable value
...
}
I'm looking for a Perl6 way to say that oft-repeated, oft-chained
two-line snippet up there without declaring the temporary variable.
Using Cgiven or Cwhen, maybe?
The idea of a pronoun, something other than $_, has occasionally crossed
my mind. I haven't given it any real thought, but perhaps this is the
time.
return it if baz(...args...);
Something that represents the last evaluated expression... or
something similar that is sufficiently DWIMmy. I'm trying to stay
away from punctuation variables for fear of repeating Perl 5's
mistakes.
Cit might be just the thing... now all that has to be done is come
up with semantics. And decide whether it's a good idea.
Luke
== vs. eq
Since my mail server has been down for a week, I've had a lot of time to look through Perl 6 as it stands, without being concerned with current issues. I'll do them one-message-at-a-time (and rather slowly, too). The first thing I noticed was the == / eq distinction. This has been invaluable for scripting, but since Perl 6 is desiring to be more of a formal language, I'm wondering whether the distinction is profitable. In generic programming (my specialty :), it is very useful to have a standard sort of equality[*] that all participating objects define. The problem is that there's Itwo kinds at the moment, and for all but simple scalars, the distinction is fuzzy. Sure, you could say that == always compares the numerical representations, and eq compares the string representations, but this breaks down for more complex concepts. The solution that springs to mind is to conform to other languages' thought and make == polymorphically compare equality. Thanks to context-forcing, the string/numeric distinction is still there, at the expense of a little extra verbosity: +$a == +$b; # Numeric compare ~$a == ~$b; # String compare $a == $b; # Generic compare Then we could also use eq for real identity, if we wanted to. [*] Not to mention, identity. The current $a.id == $b.id is unsatisfactory as I see it, but that's a different issue. Luke
is is overoverloaded?
While my last post was about removing entities, this one will be about
adding them.
Now, I don't know what Larry has up his sleeve in this respect, but as
I see it now, Cis is too heavily overloaded. As it stands, it means
3 things:
(1) Attributing traits
(2) Inheriting base classes
(3) Tying variables
Depending on how traits are implemented, (1) and (3) might be
unified. But, even so, this is a case of Different Things Looking
Similar in similar context. Consider the following ambiguities:
(a) class Foo is Bar { }# Bar a trait or a base class?
(b) my $x is Baz; # Container class or trait?
This seems to be analogous to the bareword in Perl 5: is it a sub or a
string? It depends on previous declaration.
I don't think Cisa is such a bad keyword, especially considering how
many people have mistakenly used it on this list.
Luke
Re: Conditional Creturns?
Matthijs van Duin wrote: That's not what page 5 of Apoc 6 says: Wow, I guess I should read those things, eh? ;-) Thanks for correcting my mistake, Matthijs. Damian
This week's Perl 6 Summary
The Perl 6 Summary for the week ending 20030330
Welcome once again to the gallimaufry that is a Perl 6 summary.
Unfettered this week by the presence of feline distraction we plunge
straight into the crystal clear waters of perk6-internals.
Iterator proof of concept
People must really like Leo Tötsch's Iterator proposal and patch. There
was only one comment about it this week (from Leo, so I'm not sure if it
counts) asking for thoughts about a possible Ref or Reference class.
Anyone?
http://xrl.us/fao
Bonsai
Zach Lipton announced that he has Bonsai up and running on the Parrot
CVS repository. This gives us a shiny new way of looking at the history
of the distribution. Thanks Zach.
http://tinderbox.perl.org/bonsai
BASIC, IMCC and Windows
Clinton A Pierce had problems trying to get IMCC building correctly
under Win32 in order to generate a binary distribution for the win32
platform. He finally brought up a working IMCC on Friday and asked for
comments about what a binary distribution should look like.
http://xrl.us/fap
http://xrl.us/faq
getopt.macro
Inspired by the argument processing in Leon Brocard's uniq(1)
implementation, Jonathan Scott Duff presented a getopt macro for Parrot
programmers. Benjamin Goldberg had a few suggestions about how to make
things a little more flexible.
http://xrl.us/far
Patch to examples/assembly/cat.pasm
Paul Duncan offered a patch to examples/assembly/cat.pasm which would
cause it to terminate when it received a ctrl-D.
http://xrl.us/fas
IMCC and scientific notation
Having got IMCC working in a win32 environment, Clinton A Pierce
discovered that IMCC didn't understand scientific notation, but the
parrot assembler does. Leo Tötsch pointed out that it sort of does, but
instead of 1e20 you have to write 1.e20. Joseph Ryan wondered if
handling scientific notation wasn't really a job for individual
compilers, but Clint and Mark Biggar explained why this wasn't a good
idea. As Mark said, in a world with BigFloats you don't want to have to
expand 1e2048 into a 2049 character string if you can possibly help it.
http://xrl.us/fat
RT spam
Someone claiming to be Marla Hurley crawled out from under a stone and
took it upon themselves to offer credit to the perl6 RT installation.
Thanks. We needed that.
Meanwhile, over in perl6-language
The language list was again busier than the internals list this week,
but volume has fallen on both lists. (If you don't count an off topic
thread on the internals list, which I haven't, there were only 22
messages there this week. And very few patches from Leopold Tötsch, I
hope he's all right.)
is static?
Discussion of static/state variables continued. Arcadi Shehter wondered
if it made sense to attach but properties to closures. I confess I
didn't really understand what he was driving at. Austin Hastings and
Larry saw something in it, and the question shifted to ways of doing
state variable initialization, which in turn led to possible changes in
the various control of flow keywords. As Larry pointed out, if you have
a static variable:
state $variable
Then, assuming that you need 'undef' to be a possible value for your
variable, you need some way of doing once and only one initialization of
that variable.
state $variable;
ONCE_AND_ONLY_ONCE { $variable = $initial_value };
The problem is that INIT and CHECK blocks happen too early; in the code
above, $initial_value may well not be set, if your state variable is set
up inside a closure this becomes even more likely. Larry reckons that
the most useful initialization semantics appear to be 'just in time'. In
other words you want initialization to happen on the first actual call
to a closure. But FIRST {...} is already taken, so Larry is
considering renaming FIRST and LAST to ENTER and LEAVE, freeing up FIRST
to mean my very first time. Freudian analysis was discouraged.
http://xrl.us/fau
Argument initializations
Michael Lazzaro summarized the various different and proposed assignment
operators available in Perl 6, including a proposed ::= for 'only
assign to uninitialized variables'. Michael wondered how these could be
used in method signatures and proposed some changes to the signature
system as set out in Apocalypse 6. People were dubious about this, with
Damian saying I don't think that allowing 20 different types of
assignment in the parameter list of a subroutine actually helps at all.
I'm not sure Michael is convinced yet.
http://xrl.us/fav
P6ML?
Michael Lazzaro asked if anyone was actually working on P6ML (a project
name that popped up last week in the 'XML is too hard for Programmers'
thread) and if there was any idea of what such a project would
Re: How shall threads work in P6?
At 8:13 PM +0200 3/31/03, Matthijs van Duin wrote: On Mon, Mar 31, 2003 at 07:45:30AM -0800, Austin Hastings wrote: I've been thinking about closures, continuations, and coroutines, and one of the interfering points has been threads. What's the P6 thread model going to be? As I see it, parrot gives us the opportunity to implement preemptive threading at the VM level, even if it's not available via the OS. I think we should consider cooperative threading, implemented using continuations. Yielding to another thread would automatically happen when a thread blocks, or upon explicit request by the programmer. It has many advantages: And one disadvantage: Dan doesn't like it. :) Well, there are actually a lot of disadvantages, but that's the only important one, so it's probably not worth much thought over alternate threading schemes for Parrot at least--it's going with an OS-level preemptive threading model. No, this isn't negotiable. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Conditional Creturns?
Forgive me; a very minor style efficiency question... what would the canonical way to do this be, given what we know of Perl6? # the hapless, inefficient version: ... return result_of_some_big_long_calculation(...args...) if result_of_some_big_long_calculation(...args...); ... The obvious answers are this: my bool $x = result_of_some_big_long_calculation(...args...); return $x if $x; -or the identical - my bool $x; return $x if $x = result_of_some_big_long_calculation(...args...); Is there a way that doesn't require the named variable? Perhaps using Cwhen? Just a thought experiment on my part, reduced from some code examples that do this sort of thing in a duplicitous fashion, switch-like... my bool $x; return $x if $x = calc_try_1(...); return $x if $x = calc_try_2(...); return $x if $x = calc_try_3(...); ... MikeL
