Variable registers
hi, I read that with the new calling conventions, there are a variable number of registers. So, if I understand correctly, if a function call takes 2 parameters, then there are only 2, and if there are 30 parameters, there will be a frame holding 30 registers. Is this about right? How does this stand WRT the 32 registers in Parrot. Is this still the case, or will this change as well? thanks, klaas-jan
Re: Exceptuations, fatality, resumption, locality, and the with keyword; was Re: use fatal err fail
Yuval Kogman wrote:
On Thu, Sep 29, 2005 at 13:52:54 -0400, Austin Hastings wrote:
[Bunches of stuff elided.]
A million years ago, $Larry pointed out that when we were able to use
'is just a' classifications on P6 concepts, it indicated that we were
making good forward progress. In that vein, let me propose that:
* Exception handling, and the whole try/catch thing, IS JUST An awkward
implementation of (late! binding) run-time return-type MMD.
Exception handling is just continuation passing style with sugar.
Have a look at haskell's either monad. It has two familiar keywords
- return and fail.
Every statement in a monadic action in haskell is sequenced by using
the monadic bind operator.
The implementation of =, the monadic bind operator, on the Either
type is one that first check to see if the left statement has
failed. If it does, it returns it. If it doesn't it returns the
evaluation of the right hand statement.
Essentially this is the same thing, just formalized into a type
Internally, it may be the same. But with exceptions, it's implemented by
someone other than the victim, and leveraged by all. That's the kind of
abstraction I'm looking for. My problem with the whole notion of Either
errorMessage resultingValue in Haskell is that we _could_ implement it
in perl as Exception|Somevalue in millions of p6 function signatures.
But I don't _want_ to. I want to say MyClass and have the IO subsystem
throw the exception right over my head to the top-level caller.
I guess that to me, exceptions are like aspects in they should be
handled orthogonally. Haskell's Either doesn't do that -- it encodes a
union return type, and forces the call chain to morph whenever
alternatives are added. The logical conclusion to that is that all subs
return Either Exception or Value, so all types should be implicitly
Either Exception or {your text here}. If that's so, then it's a
language feature and we're right back at the top of this thread.
Specifically, if I promise you:
sub foo() will return Dog;
and later on I actually wind up giving you:
sub foo() will return Exception::Math::DivisionByZero;
In haskell:
foo :: Either Dog Exception::Math::DivisionByZero
e.g., it can return either the expected type, or the parameter.
Haskell is elegant in that it compromises nothing for soundness, to
respect referential integrity and purity, but it still makes thing
convenient for the programmer using things such as monads
For appropriate definitions of both 'elegant' and 'convenient'. Java
calls this 'checked exceptions', and promises to remind you when you
forgot to type throws Exception::Math::DivisionByZero in one of a
hundred places. I call it using a word to mean its own opposite: having
been exposed to roles and aspects, having to code for the same things in
many different places no longer strikes me as elegant or convenient.
the try/catch paradigm essentially says:
I wanted to call csub Dog foo()/c but there may be times when I
discover, after making the call, that I really needed to call an anonymous
csub { $inner::= sub Exception foo(); $e = $inner(); given $e {...} }/c.
Yes and no.
The try/catch mechanism is not like the haskell way, since it is
purposefully ad-hoc. It serves to fix a case by case basis of out
of bounds values. Haskell forbids out of bound values, but in most
programming languages we have them to make things simpler for the
maintenance programmer.
Right. At some level, you're going to have to do that. This to me is
where the err suggestion fits the most comfortably: err (or doh!
:) is a keyword aimed at ad-hoc fixes to problems. It smooths away the
horrid boilerplate needed for using exceptions on a specific basis.
do_something() err fix_problem();
is much easier to read than the current
{ do_something(); CATCH { fix_problem(); }}
by a lot. But only in two conditions: first that all exceptions are
identical, and second that the correct response is to suppress the
exception.
To me that fails because it's like Candy Corn: you only buy it at
Halloween, and then only to give to other people's kids.
As syntactic sugar goes, it's not powerful enough yet.
We're conditionally editing the return stack. This fits right in with
the earlier thread about conditionally removing code from the inside of
loops, IMO. Once you open this can, you might as well eat more than one
worm. Another conceptually similar notion is that of AUTOLOAD. As a perl
coder, I don't EVER want to write
say Hello, world
or die Write to stdout failed.;
-- it's correct. It's safe coding. And it's stupid for a
whole bunch of reasons, mostly involving the word yucky.
It's incorrect because it's distracting and tedious.
http://c2.com/cgi/wiki?IntentionNotAlgorithm
Code which does it is, IMHO bad code because obviously the author
does not know where to draw the line and say this is good enough,
anything more would only make it worse.
For instance, some
Re: [perl #37303] [PATCH] Relaxing parrot dependency on parrot_config
References: [EMAIL PROTECTED] [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] Content-Type: multipart/mixed; boundary=090002080107010906030407 X-Antivirus: avast! (VPS 0539-3, 30/09/2005), Outbound message X-Antivirus-Status: Clean --090002080107010906030407 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Joshua Hoblitt wrote: # New Ticket Created by Joshua Hoblitt # Please include the string: [perl #37303] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37303 - Forwarded message from Nick Glencross [EMAIL PROTECTED] - From: Nick Glencross [EMAIL PROTECTED] Guys, I've been wanting to relax the dependency that parrot's core has on parrot_config. I'm not sure that the patch made it into RT. Here it is again, with a small tweak to a Makefile dependency. src/config.c will need to be 'svn add'ed when applying the patch, and Configure rerun to recreate the top-level Makefile. Cheers, Nick --090002080107010906030407 Content-Type: text/plain; name=config.patch_2.txt Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=config.patch_2.txt SW5kZXg6IGJ1aWxkX3Rvb2xzL3BhcnJvdF9jb25maWdfYy5wbAo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0t LSBidWlsZF90b29scy9wYXJyb3RfY29uZmlnX2MucGwJKHJldmlzaW9uIDkyNzMpCisrKyBi dWlsZF90b29scy9wYXJyb3RfY29uZmlnX2MucGwJKHdvcmtpbmcgY29weSkKQEAgLTcsNyAr Nyw3IEBACiAKID1oZWFkMSBOQU1FCiAKLWJ1aWxkX3Rvb2xzL3BhcnJvdF9jb25maWdfYy5w bCAtIENyZWF0ZSBzcmMvcGFycm90X2NvbmZpZy5jCitidWlsZF90b29scy9wYXJyb3RfY29u ZmlnX2MucGwgLSBDcmVhdGUgc3JjL3BhcnJvdF9jb25maWcuYyBhbmQgdmFyaWFudHMKIAog PWhlYWQxIFNZTk9QU0lTCiAKQEAgLTQxLDQ2ICs0MSw0NCBAQAogICoKICAqLwogCi0jaW5j bHVkZSAicGFycm90L3BhcnJvdC5oIgotCi1zdGF0aWMgY29uc3QgY2hhciBwYXJyb3RfY29u ZmlnW10gPSB7CiBFT0YKIAogaWYgKCRtaW5pX3BhcnJvdCkgewotICAgIHByaW50ICIgICAg MFxuIjsKKworICAgIHByaW50IDw8ICJFT0YiOworY29uc3QgY2hhciogcGFycm90X2NvbmZp Z19wdHIgICA9IDA7Cit1bnNpZ25lZCBpbnQgcGFycm90X2NvbmZpZ19zaXplID0gMDsKK0VP RgogfQotZWxzZSB7CitlbHNlCit7CisgICAgcHJpbnQgPDwgIkVPRiI7CitzdGF0aWMgY29u c3QgY2hhciBwYXJyb3RfY29uZmlnW10gPSB7CitFT0YKKwogICAgIG15ICRpbWFnZV9maWxl ID0gJGluc3RhbGxfcGFycm90ID8KLQknaW5zdGFsbF9jb25maWcuZnBtYycgOiAncnVudGlt ZS9wYXJyb3QvaW5jbHVkZS9jb25maWcuZnBtYyc7CisgICAgICAgICdpbnN0YWxsX2NvbmZp Zy5mcG1jJyA6ICdydW50aW1lL3BhcnJvdC9pbmNsdWRlL2NvbmZpZy5mcG1jJzsKICAgICBv cGVuIEYsICRpbWFnZV9maWxlIG9yIGRpZSAiQ2FuJ3QgcmVhZCAnJGltYWdlX2ZpbGUnOiAk ISI7CiAgICAgbXkgJGltYWdlOwogICAgIGxvY2FsICQvOwotCWJpbm1vZGUgRjsKKyAgICBi aW5tb2RlIEY7CiAgICAgJF8gPSA8Rj47CiAgICAgY2xvc2UgRjsKICAgICBteSBAYyA9IHNw bGl0ICcnOwogICAgIHByaW50ZiAnICAgICc7CiAgICAgbXkgJGk7CiAgICAgZm9yIChAYykg ewotCXByaW50ZiAiMHglMDJ4Iiwgb3JkKCRfKTsKLQkrKyRpOwotCXByaW50ICcsICcsIGlm ICgkaSA8IHNjYWxhcihAYykpOwotCXByaW50ICJcbiAgICAiIHVubGVzcyAkaSAlIDg7Cisg ICAgICAgIHByaW50ZiAiMHglMDJ4Iiwgb3JkKCRfKTsKKyAgICAgICAgKyskaTsKKyAgICAg ICAgcHJpbnQgJywgJywgaWYgKCRpIDwgc2NhbGFyKEBjKSk7CisgICAgICAgIHByaW50ICJc biAgICAiIHVubGVzcyAkaSAlIDg7CiAgICAgfQogICAgIHByaW50ICJcbiI7Ci19CiAKIHBy aW50IDw8ICJFT0YiOwogfTsgLyogcGFycm90X2NvbmZpZyAqLwogCi1TVFJJTkcqCi1wYXJy b3RfZ2V0X2NvbmZpZ19zdHJpbmcoSW50ZXJwKiBpbnRlcnByZXRlcikKLXsKLSAgICBpZiAo c2l6ZW9mKHBhcnJvdF9jb25maWcpIDw9IDEpCi0JcmV0dXJuIE5VTEw7Ci0gICAgcmV0dXJu IHN0cmluZ19mcm9tX2NvbnN0X2NzdHJpbmcoaW50ZXJwcmV0ZXIsCi0JcGFycm90X2NvbmZp Zywgc2l6ZW9mKHBhcnJvdF9jb25maWcpKTsKLX0KK2NvbnN0IGNoYXIqIHBhcnJvdF9jb25m aWdfcHRyICAgPSBwYXJyb3RfY29uZmlnOwordW5zaWduZWQgaW50IHBhcnJvdF9jb25maWdf c2l6ZSA9IHNpemVvZihwYXJyb3RfY29uZmlnKTsKIEVPRgotCi0KK30KSW5kZXg6IHNyYy9j b25maWcuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzcmMvY29uZmlnLmMJKHJldmlzaW9uIDApCisr KyBzcmMvY29uZmlnLmMJKHJldmlzaW9uIDApCkBAIC0wLDAgKzEsNjMgQEAKKy8qCisgIENv cHlyaWdodDogMjAwNSBUaGUgUGVybCBGb3VuZGF0aW9uLiAgQWxsIFJpZ2h0cyBSZXNlcnZl ZC4KKyAgJElkJAorCis9aGVhZDEgTkFNRQorCitzcmMvY29uZmlnLmMgLSBSZWdpc3RlciBj b25maWd1cmF0aW9uIGJ1bmRsZSB3aXRoIHBhcnJvdCBydW50aW1lCisKKz1oZWFkMSBERVND UklQVElPTgorCitUaGUgcm91dGluZXMgaW4gdGhpcyBmaWxlIGNhbiBiZSB1c2VkIHRvIHNl dCBhbmQgcmV0cmlldmUgdGhlIGVtYmVkZGVkCitjb25maWd1cmF0aW9uIGRhdGEgZm9yIHRo ZSBwYXJyb3QgcnVudGltZS4KKworVGhlcmUgYXJlIGN1cnJlbnRseSB0aHJlZSBydW50aW1l czoKKworPW92ZXIgNAorCis9aXRlbSAqIGEgZHVtbXkgc3R1YiB1c2VkIGluIG1pbnBhcnJv dCBkdXJpbmcgYW5kIG90aGVyIHV0aWxpdGllcy4gTm8KK2V4cGxpY2l0IHNldCBpcyByZXF1 aXJlZCBmb3IgdGhpcworCis9aXRlbSAqIHRoZSBkZWZhdWx0IGNvbmZpZyB1c2VkIGR1cmlu ZyB0aGUgYnVpbGQKKworPWl0ZW0gKiBhIGNvbmZpZyBwcm9maWxlIHN1aXRhYmxlIG9uY2Ug cGFycm90IGhhcyBiZWVuIGluc3RhbGxlZCBzeXN0ZW0td2lkZQorCis9YmFjaworCis9Y3V0 CisKKyovCisKKyNpbmNsdWRlICJwYXJyb3QvcGFycm90LmgiCisKK3N0YXRpYyBjb25zdCBj aGFyICAqcGFycm90X2NvbmZpZ19wcml2YXRlX3B0ciAgPSBOVUxMOworc3RhdGljIHVuc2ln bmVkIGludCBwYXJyb3RfY29uZmlnX3ByaXZhdGVfc2l6ZSA9IDA7CisKK3ZvaWQKK3BhcnJv dF9zZXRfY29uZmlnX3N0cmluZyhjb25zdCBjaGFyKiAgbmV3X3BhcnJvdF9jb25maWdfcHRy
Re: Variable registers
On Oct 1, 2005, at 8:46, [EMAIL PROTECTED] wrote: hi, I read that with the new calling conventions, there are a variable number of registers. So, if I understand correctly, if a function call takes 2 parameters, then there are only 2, and if there are 30 parameters, there will be a frame holding 30 registers. Is this about right? Yes. The argument passing opcodes take a variable amount of registers How does this stand WRT the 32 registers in Parrot. Is this still the case, or will this change as well? This will change. Register frame size and thus the amount of registers will be adapted to the actual usage of a subroutine. thanks, klaas-jan leo
Re: merge release
On Sep 28, 2005, at 10:50, Leopold Toetsch wrote: 3) Release will follow at the weekend I'll start the release procedure RSN. Please no more svn checkins at all. leo
Re: Exceptuations, fatality, resumption, locality, and the with keyword; was Re: use fatal err fail
TSa wrote: The view I believe Yuval is harboring is the one examplified in movies like The Matrix or The 13th Floor and that underlies the holodeck of the Enterprise: you can leave the intrinsic causality of the running program and inspect it. Usually that is called debugging. But this implies the programmer catches a breakpoint exception or some such ;) Exception handling is the programmatic automatisation of this process. As such it works the better the closer it is in time and context to the cause and the more information is preserved. But we all know that a usefull program is lossy in that respect. It re-uses finite resources during its execution. In an extreme setting one could run a program *backwards* if all relevant events were recorded! The current state of the art dictates that exceptions are to be avoided when it is possible to handle the error in-line. That exceptions should only be used for exceptional cases, and anything you encounter in the manual pages is not exceptional. I don't agree with this, because it is IMO effectively saying We had this powerful notion, but it turned out to be difficult to integrate post-hoc into our stack-based languages, so we're going to avoid it. Rather than admitting defeat, though, we're going to categorize it as some kind of marginal entity. I don't see exceptions as necessarily being outside the intrinsic causality of the running program. They are non-traditional forms of flow control: event-based programming, if you will, in an otherwise sequential program. We do much the same thing when we talk about coroutines: violate the traditional stack model. We do the same thing again when we talk about aspects: de-localize processing of certain (ahem) aspects of the problem domain. The telling part of aspects, though, was the the first popular implementation (AspectJ) required a preprocessor and a special markup language to implement. Why? Because nobody uses extensibility and Java in the same sentence. I guess aspects are traditional in that regard, though: remember CFront. Perl, OTGH, doesn't have the poor body-image or whatever it is that keeps people afraid to change the syntax. It can't be a method because it never returns to it's caller - it's It beeing the CATCH block? Ahh, no. It in this case is the .resume call. My question was is cresume/c a multi, an object method, or what? This is because the types of exceptions I would want to resume are ones that have a distinct cause that can be mined from the exception object, and which my code can unambiguously fix without breaking the encapsulation of the code that raised the exception. Agreed. I tried to express the same above with my words. The only thing that is a bit underspecced right now is what exactly is lost in the process and what is not. My guiding theme again is the type system where you leave information about the things you need to be preserved to handle unusual cicumstances gracefully---note: *not* successfully, which would contradict the concept of exceptions! This is the classical view of exceptions, and so it is subject to the classical constraints: you can't break encapsulation, so you can't really know what's going when the exception occurs. The reason I like the with approach is that it lets us delocalize the processing, but does _not_ keep the exceptions are violent, incomprehensible events which wrench us from our placid idyll mentality. In that regard, exceptuations are resumable gotos. =Austin
Re: Look-ahead arguments in for loops
Damian Conway wrote:
Rather than addition Yet Another Feature, what's wrong with just using:
for @list ¥ @list[1...] - $curr, $next {
...
}
???
1. Requirement to repeat the possibly complex expression for the list.
2. Possible high cost of generating the list.
3. Possible unique nature of the list.
All of these have the same solution:
@list = ...
for [undef, @list[0...]] ¥ @list ¥ [EMAIL PROTECTED], undef] - $last, $curr,
$next {
...
}
Which is all but illegible.
=Austin
Re: Exceptuations, fatality, resumption, locality, and the with keyword; was Re: use fatal err fail
On Sat, Oct 01, 2005 at 05:57:54 -0400, Austin Hastings wrote:
Internally, it may be the same. But with exceptions, it's implemented by
someone other than the victim, and leveraged by all. That's the kind of
abstraction I'm looking for. My problem with the whole notion of Either
errorMessage resultingValue in Haskell is that we _could_ implement it
in perl as Exception|Somevalue in millions of p6 function signatures.
But I don't _want_ to. I want to say MyClass and have the IO subsystem
throw the exception right over my head to the top-level caller.
In haskell it's the job of the Either monad to let you pretend you
aren't doing Exception|Somevalue everywhere.
You can sequence operations in a deeply nested manner, and then
'fail' at some point. Then control flow will just pop back up all
the way with the error, instead of trying to continue.
You don't really need to say 'Either ... ...', you just use do
notation.
For appropriate definitions of both 'elegant' and 'convenient'. Java
calls this 'checked exceptions', and promises to remind you when you
forgot to type throws Exception::Math::DivisionByZero in one of a
hundred places. I call it using a word to mean its own opposite: having
been exposed to roles and aspects, having to code for the same things in
many different places no longer strikes me as elegant or convenient.
I agree with that wholeheartedly, but in haskell you are making no
obligation towards the shape of an exception - it can be 'Either
thing Error' where Error is any data type you like.
In this sense haskell is just as flexible but requires more
abstraction than perl etc. It has it's merits - it's safer, and more
reusable. It tends to win ICFP contests, and so forth.
However, to just get that thing working real fast, without having
to pay too much when the context becomes maintenance instead of
development, i think Perl 6 will be the most suitable language in
the world.
Right. At some level, you're going to have to do that. This to me is
where the err suggestion fits the most comfortably: err (or doh!
:) is a keyword aimed at ad-hoc fixes to problems. It smooths away the
horrid boilerplate needed for using exceptions on a specific basis.
Which is why it's such a nice propsal =)
As syntactic sugar goes, it's not powerful enough yet.
err next # catch all
err Pattern, next # catch some
Putting my code where my mouth is:
sub infix:err (lhs is delayed, Pattern ?$match = Any, rhs is
delayed) {
lhs;
CATCH {
when $match { rhs }
default { die }
}
}
Ofcourse, these can also stack:
my $fh = open file
err rx/Permission Denied/, next
err rx/No such file/, die;
But i don't think this is very useful for one or at the very most
two catches - for anything else it's ad-hoc nature just doesn't
scale as nicely as CATCH blocks, which can be applied to several
error generating blocks of code at once.
Ofcourse, true acid heads can always say:
do {
...;
...;
} err ..., ...
err ..., ...;
but that's their problem. =)
The last sentence is telling, I think. The run-time system SHOULD take
as much care as possible. And rub my feet.
Yes =)
True for any method that invokes exit(), no? Or that says NEXT on a
label outside its scope.
Well, that's a semantic detail. The issue is that those methods
*can* return, but don't.
A continuation will never return - because it already has another
place to return - the place that created it.
This is ignoring CPS, ofcourse, in which every return and every call
is a continuation. While this may be true under the hood, this is
not what the average Perl 6 user can observe.
The scenario is that I try something (error_throwing_code) and catch an
exception. Then while showing a dialog box to the user, for example, I
get another exception: not enough handles or whatever. So someone higher
than me resolves that on my behalf, then resumes me. I'm still trying to
resume the error thrown earlier:
Yes, that should work.
Now I need to ask, what happens when show_dialog_box throws an
exception? Presumably, I don't catch it in this code path, or there will
be a stack fault shortly.
If the exception from show_dialog_box was thrown, and another CATCH
handler fixed it for you, you don't need to worry about it - you can
never know because you don't get access to that exception. It's as
if it was never propagated.
One possibility is that the catcher of an exception knows little or
nothing about the innards of the thrower.
It's the job of exception classes to bridge these - they have a
class, and any number of attributes.
Exception::IO::Open::PermissionDenied
In fact I suspect that Exception::IO::Open enforces a certain type of
fix, too:
class Exception::IO::Open is Exception {
has
Re: Look-ahead arguments in for loops
Austin Hastings wrote:
All of these have the same solution:
@list = ...
for [undef, @list[0...]] ¥ @list ¥ [EMAIL PROTECTED], undef] - $last, $curr,
$next {
...
}
Which is all but illegible.
Oh, no! You mean I might have to write a...subroutine!??
sub contextual (@list) {
return [undef, @list[0...]] ¥ @list ¥ [EMAIL PROTECTED], undef]
}
for contextual( create_list_here() ) - $last, $curr, $next {
...
}
The horror!!!
;-)
Damian
RE: Look-ahead arguments in for loops
-Original Message-
From: Damian Conway [mailto:[EMAIL PROTECTED]
Sent: Saturday, October 01, 2005 8:53 AM
To: perl6-language@perl.org
Subject: Re: Look-ahead arguments in for loops
Austin Hastings wrote:
All of these have the same solution:
@list = ...
for [undef, @list[0...]] ¥ @list ¥ [EMAIL PROTECTED], undef] - $last,
$curr,
$next {
...
}
Which is all but illegible.
Oh, no! You mean I might have to write a...subroutine!??
sub contextual (@list) {
return [undef, @list[0...]] ¥ @list ¥ [EMAIL PROTECTED], undef]
}
for contextual( create_list_here() ) - $last, $curr, $next {
...
This looks useful enough to be in the core, but it needs a couple of
parameters, one to say how many copies of the list it zips up, and another
to say what the first offset is.
sub contextual($number_of_copies, $first_offset, @list) {...} # I'm not
sure how to write it.
Then your example would be
for contextual(3, -1, create_list_here() )- $last, $first, $next {
Joe Gottman
Parrot 0.3.0 Alex Released!
On behalf of the Parrot team I'm proud to announce the release of Parrot 0.3.0. I'd like to thank all involved people as well as our sponsors for supporting us. What is Parrot? Parrot is a virtual machine aimed at running Perl6 and other dynamic languages. Parrot 0.3.0 changes and news - New calling conventions implemented: see PDD03 for details - Merge multiple Parrot bytecode (PBC) files into a singe PBC file - 'make smoke' target going beta - bc now supports if statements, comparison ops, prefix inc/dec - ParTcl adds [lassign], [switch] (partially); [expr] converted to a compiler - Many exciting doc updates, tests, and bugfixes, too numerous to mention After some pause you can grab it from http://www.cpan.org/authors/id/L/LT/LTOETSCH/parrot-0.3.0.tar.gz. As parrot is still in steady development we recommend that you just get the latest and best from SVN by following the directions at http://www.parrotcode.org/source.html Turn your web browser towards http://www.parrotcode.org/ for more information about Parrot, get involved, and: Have fun! leo
Re: Look-ahead arguments in for loops
On Fri, Sep 30, 2005 at 08:39:58PM -0600, Luke Palmer wrote: Incidentally, the undef problem just vanishes here (being replaced by another problem). Which reminds me that this same issue came up a while ago in a different guise. There was a long discussion about the reduce functionality that takes an array and applies an operator to each value and the previously collected result. (Much of the discussion was on determining what the identity value for an operator was to initialize the previous result.) Most of the time that you want a loop that remembers the previous value, it can be equally well expressed an a reduction of the series of value using an customer defined operator. I forget what the final choice was for syntax for the reduce operator (it was probably even a different name from reduce - that's the APL name), but it would be given a list and an operator and run as: my $running = op.identity; $running = $running op $_ for @list; So, to get a loop body that knows the previous value, you define an operator whose identity is the initial value of the list and reduce the rest of the list. --
seeing the end of the tunnel
So, I was thinking about how $Larry's original plan for doing the Perl6 design was something along the lines of write a series of Apocalypses, one for each chapter of the Camel book. I know that the latest version of the Apocalypses are in SVN, but I checked dev.perl.org just to see what the current list was. I see the following: * Apocalypse 1 - The Ugly, the Bad, and the Good * Apocalypse 2 - Bits and Pieces * Apocalypse 3 - Operators * Apocalypse 4 - Syntax * Apocalypse 5 - Pattern Matching * Apocalypse 6 - Subroutines * Apocalypse 7 - Formats (see Exegesis 7) * Apocalypse 12 - Objects Hmm, interesting; that actually sounds like a pretty complete design. So, I pulled down my Camel v3 and started checking to see what was left to do. I was surprised how few of the remaining chapters pertain directly to broad issues of language design; most of them are things like The Command Line Interface, The Debugger, etc...important, but not fundamentally critical to the language design. Many of the others are things like Packages--they probably won't change much, and the differences have already been hammered out, just not consolidated into an Apocalyptic form. Other chapters-- such as Chapter 33, Diagnostic Messages--will be better served by being left unwritten until the implementation is released. All in all, I think that might just be the end of the tunnel up ahead. Go us for getting here, and loud applause to @Larry for guiding us so well! --Dks Here are the chapters which haven't been covered yet: The Gory Details * 8. References * 9. Data Structures * 10. Packages * 11. Modules * 13. Overloading * 14. Tied Variables Perl as Technology * 15. Unicode * 16. Interprocess Communication * 17. Threads * 18. Compiling * 19. The CLI * 20. The Perl Debugger * 21. Internals and Externals Perl as Culture * 22. CPAN * 23. Security * 24. Common Practices * 25. Portable Perl * 26. Plain Old Documentation * 27. Perl Culture Reference Material * 28. Special Names * 29. Functions * 30. The Standard Perl Library * 31. Pragmatic Modules * 32. Standard Modules * 33. Diagnostic Messages
Re: Variable registers
Leopold Toetsch wrote: On Oct 1, 2005, at 8:46, [EMAIL PROTECTED] wrote: hi, I read that with the new calling conventions, there are a variable number of registers. So, if I understand correctly, if a function call takes 2 parameters, then there are only 2, and if there are 30 parameters, there will be a frame holding 30 registers. Is this about right? Yes. The argument passing opcodes take a variable amount of registers How does this stand WRT the 32 registers in Parrot. Is this still the case, or will this change as well? This will change. Register frame size and thus the amount of registers will be adapted to the actual usage of a subroutine. ah I thought so. just making sure. Then another question WRT this; will there be a register allocator? In other words, an attempt to minimize the number of needed registers? (in my simple code generator implementations, any time I need a new register, I just increment a counter, and use that, so in that case there is No register allocation scheme) regards, klaas-jan
Re: Variable registers
On Oct 1, 2005, at 18:11, Klaas-Jan Stol wrote: ah I thought so. just making sure. Then another question WRT this; will there be a register allocator? In other words, an attempt to minimize the number of needed registers? (in my simple code generator implementations, any time I need a new register, I just increment a counter, and use that, so in that case there is No register allocation scheme) Sure, the register allocator will remain. The increment the counter strategy is fine. The only difference will be that all lexicals and persistent variables, which are used around a function call, will be assigned to distinct Parrot registers. This strategy will solve the still lurking continuation bug that was discussed excessively here. Temps, not used around a function call, will have their registers reused as now. regards, klaas-jan leo
Re: About multithreading
Leo wrote: http://www.gotw.ca/publications/concurrency-ddj.htm The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software Herb Sutter On Tue, 20 Sep 2005, Jonathan Worthington replied: Yup, and it's encouraging to see Perl 6 is heading in a good direction on concurrency stuff at a language level too. So can we look towards having things like map and grep be parallel (or at least unordered) by default? -Martin
Re: Look-ahead arguments in for loops
On 10/1/05, John Macdonald [EMAIL PROTECTED] wrote:
I forget what the final choice was for syntax for the reduce
operator (it was probably even a different name from reduce -
that's the APL name), but it would be given a list and an
operator and run as:
my $running = op.identity;
$running = $running op $_ for @list;
So, to get a loop body that knows the previous value, you
define an operator whose identity is the initial value of the
list and reduce the rest of the list.
And that was never quite resolved. The biggest itch was with
operators that have no identity, and operators whose codomain is not
the same as the domain (like , which takes numbers but returns
bools).
Anyway, that syntax was
$sum = [+] @items;
And the more general form was:
$sum = reduce { $^a + $^b } @items;
Yes, it is called reduce, because foldl is a miserable name.
Luke
Re: Look-ahead arguments in for loops
Damian Conway wrote:
Austin Hastings wrote:
All of these have the same solution:
@list = ...
for [undef, @list[0...]] ¥ @list ¥ [EMAIL PROTECTED], undef] - $last, $curr,
$next {
...
}
Which is all but illegible.
Oh, no! You mean I might have to write a...subroutine!??
Austin Hastings wrote:
1. Requirement to repeat the possibly complex expression for the list.
2. Possible high cost of generating the list.
3. Possible unique nature of the list.
The subroutine addresses #1, but not 2 or 3.
Also, there's a #4: modified state, which is hinted at but not really
covered by #3.
=Austin
Re: seeing the end of the tunnel
On 10/1/05, David Storrs [EMAIL PROTECTED] wrote: All in all, I think that might just be the end of the tunnel up ahead. Go us for getting here, and loud applause to @Larry for guiding us so well! Applause for p6l for hashing out the issues that we didn't think of. I recently wrote a Perl 6 design TODO, which was surprizingly small, which enumerated the things to be done before I considered the design of Perl 6 to be finished. Larry replied with a couple more items. In particular: Here are the chapters which haven't been covered yet: * 17. Threads * 26. Plain Old Documentation * 29. Functions Luke
Re: About multithreading
On Oct 1, 2005, at 22:20, Martin D Kealey wrote: So can we look towards having things like map and grep be parallel (or at least unordered) by default? I don't think so. First and foremost, these functions produce ordered results, that's the Perl semantics of it. Second, while we can for sure do some multithreading, if we are waiting for IO or such, it's hard for pure computations. Kicking off more threads has it's cost too and it's only worth the effort, if the computation is taking a lot of time (or CPU cycles). But that's a thing Parrot really doesn't know in advance. That said, it's unlikely that autothreading w/o any user hints will happen soon. -Martin leo
Re: Look-ahead arguments in for loops
Austin Hastings wrote: 1. Requirement to repeat the possibly complex expression for the list. 2. Possible high cost of generating the list. 3. Possible unique nature of the list. The subroutine addresses #1, but not 2 or 3. It does address 2. The list is generated once (wherever) and only passed to the subroutine once. No regeneration required. It's exactly like your all but illegible solution, just factored out and deuglified. Since I don't understand what you mean by 3, I can't really judge whether it addresses it. But I *can* say it addresses it exactly as well as your all but illegible solution did. Also, there's a #4: modified state, which is hinted at but not really covered by #3. 4 is not possible using the pointy sub syntax in any form, since all params to pointy subs are always constant aliases. Damian
Re: Look-ahead arguments in for loops
On Sat, Oct 01, 2005 at 02:22:01PM -0600, Luke Palmer wrote:
And the more general form was:
$sum = reduce { $^a + $^b } @items;
Yes, it is called reduce, because foldl is a miserable name.
So, the target of running a loop with both the current
and previous elements accessible could be written as either:
reduce :identity undef
{ code using $^prev and $^cur ... ; $^cur }
@items;
or:
reduce :identity @items[0]
{ code using $^prev and $^cur ... ; $^cur }
@items[1...];
--
[perl #37321] [TODO] Data::Escape::String needs to escape Unicode
# New Ticket Created by Will Coleda # Please include the string: [perl #37321] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37321 A quick check shows this fails at str[index] on line 78.
Re: Tcl - compiling expressions
The simple version of the compiler is now mostly done in my sandbox:
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t/cmd_global.t 3 768 63 50.00% 2-4
t/cmd_proc.t 4 1024114 36.36% 3-4 8-9
t/cmd_return.t 1 256 21 50.00% 1
t/cmd_string.t 3 768573 5.26% 21 45-46
t/tcl_backslash.t4 1024354 11.43% 31-34
These break down into two classes of errors:
1) ``Pad index out of range'' {global, proc, return}
2) Data::Escape::String can't escape unicode {string, backslash}
I've opened a TODO ticket for #2: [perl #37321] Any takers on this
appreciated.
If I can get #1 working, I'll just TODO everything that depends on #2
and get this checked in.
I've attached the generated PIR output for the sample program, which
outputs 10
set a 0
while {$a 10} {
incr a
}
puts $a
It's functional but ugly. (Patches welcome once I checkin)
.pragma n_operators 1
.sub blah @ANON
.include languages/tcl/lib/returncodes.pir
$P0 = new .String
$P0=a
$P1 = new .String
$P1=0
.local pmc command
$P2 = new .String
$P2=set
$S3=$P2
$S3 = . $S3
push_eh bad_command3
command = find_global Tcl, $S3
clear_eh
if_null command, bad_command3
$P3 = command($P0,$P1)
goto resume3
bad_command3:
$S3=$P2
$S3=concat invalid command name \ ,$S3
$S3.=\
.throw($S3)
resume3:
.include languages/tcl/lib/returncodes.pir
$P3 = new .String
$P3=$a 10
$P4 = new .String
$P4=\n incr a\n
.local pmc command
$P5 = new .String
$P5=while
$S6=$P5
$S6 = . $S6
push_eh bad_command6
command = find_global Tcl, $S6
clear_eh
if_null command, bad_command6
$P6 = command($P3,$P4)
goto resume6
bad_command6:
$S6=$P5
$S6=concat invalid command name \ ,$S6
$S6.=\
.throw($S6)
resume6:
.include languages/tcl/lib/returncodes.pir
.local pmc read
read=find_global _Tcl, __read
$P6 = read(a)
.local pmc command
$P7 = new .String
$P7=puts
$S8=$P7
$S8 = . $S8
push_eh bad_command8
command = find_global Tcl, $S8
clear_eh
if_null command, bad_command8
$P8 = command($P6)
goto resume8
bad_command8:
$S8=$P7
$S8=concat invalid command name \ ,$S8
$S8.=\
.throw($S8)
resume8:
.return ($P8)
.end
.pragma n_operators 1
.sub blah @ANON
.include languages/tcl/lib/returncodes.pir
$P0 = new .String
$P0=a
.local pmc command
$P1 = new .String
$P1=incr
$S2=$P1
$S2 = . $S2
push_eh bad_command2
command = find_global Tcl, $S2
clear_eh
if_null command, bad_command2
$P2 = command($P0)
goto resume2
bad_command2:
$S2=$P1
$S2=concat invalid command name \ ,$S2
$S2.=\
.throw($S2)
resume2:
.return ($P2)
.end
10
On Sep 30, 2005, at 1:39 PM, Amos Robinson wrote:
Eeek. Yes, I forgot just how crazy a language it was. :-D
Yes, that's the plan, but the initial implementation isn't going to
be a compiler like most people would expect:
For example, something like:
while {$a 10} { incr a }
while isn't language syntax. it's a command. So, this code would
result in creating two PMCs for the args (first arg is {$a 10},
second is {incr a}), and then lookup the while PIR .sub, and invoke
it with the two PMC args.
Future versions of the compiler will be able to cheat (presuming the
while builtin hasn't been overriden) and generate inline-able PIR,
which should improve performance.)
Regards.
Re: Tcl - compiling expressions
On Oct 2, 2005, at 1:40 AM, Will Coleda wrote:
I've attached the generated PIR output for the sample program,
which outputs 10
set a 0
while {$a 10} {
incr a
}
puts $a
Ok, technically, it's not the output of a complete PIR program, it's
the concatenated output of several chunks. One of the goals, however,
will be to generate a standalone PIR program that can be compiled to
bytecode.
Regards.
