Re: Exceptuations
On 9/25/05, Luke Palmer [EMAIL PROTECTED] wrote: [...] Exactly which exception is continued? [...] Named restarts in Common Lisp appear to try to solve a related problem, if I'm skimming this thread correctly. :-) (see [1]). Michael [1] http://www.supelec.fr/docs/cltl/clm/node312.html#SECTION00330
Re: A sketch of the security model
On 4/15/05, Shevek [EMAIL PROTECTED] wrote:
How can dropping a privilege for the duration of a (dynamic) scope be
implemented? Does this need to be implemented via a parrot intrinsic,
such as:
without_privs(list_of_privs, code_to_be_run_without_these_privs);
..or is it possible to do so with the primitives you sketched out above?
This is usually done by creating a function f(code) { code() } without
any static privileges in list_of_privs.
To evaluate a function g()
without those privileges, evaluate f(g), and the natural mechanisms of
the interpreter will ensure that these privileges are not held during
g().
I understand, thanks.
Michael
Re: A sketch of the security model
Dan, On 4/13/05, Dan Sugalski [EMAIL PROTECTED] wrote: All security is done on a per-interpreter basis. (really on a per-thread basis, but since we're one-thread per interpreter it's essentially the same thing) Just to get me back on track: Does this mean that when you spawn a thread, a separate interpreter runs in/manages that thread, or something else? Each running thread has two sets of privileges -- the active privileges and the enableable privileges. Active privs are what's actually in force at the moment, and can be dropped at any time. The enableable privs are ones that code can turn on. It's possible to have an active priv that's not in the enableable set, in which case the current running code is allowed to do something but as soon as the privilege is dropped it can't be re-enabled. How can dropping a privilege for the duration of a (dynamic) scope be implemented? Does this need to be implemented via a parrot intrinsic, such as: without_privs(list_of_privs, code_to_be_run_without_these_privs); ..or is it possible to do so with the primitives you sketched out above? Additionally, subroutines may be marked as having privileges, which means that as long as control is inside the sub the priv in question is enabled. This allows for code that has elevated privs, generally system-level code. Does the code marking a subroutines must have any other privilege than the one it is marking the subroutine with? ... Non-continuation invokables (subs and methods) maintain the current set of privs, plus possibly adding the sub-specific privs. Same for closures? Regards, Michael
Re: Documentary annotations: $what docwhy
Make is polymorphic :D
Michael
On Thu, 31 Mar 2005 21:24:52 -0500 (EST), Abhijit Mahabal
[EMAIL PROTECTED] wrote:
On Thu, 31 Mar 2005, Luke Palmer wrote:
Chip Salzenberg writes:
I'd like to annotate Perl 6 parameters and other entities using
traits, since that's the best way (I know of) to have them appear
immediately in the text of the program where they are.
Supposing I had a doc trait, could I say:
sub f2c (Num $temp docTemperature in degrees F)
docConvert degress F to degrees C
{...}
Or would I be forced to spell it doc('stuff') ?
Well, first you need an `is` somewhere in there. And after that I think
you'll need to do it in doc('stuff') form. If we did allow doc, then
this:
is docConvert degrees F to degrees C
But if you are going to use doc('') in a million places, can you not also
make doc a trait_verb and save a little typing? So:
role doc{
sub *trait_verb:doc($container: $string) {
...
}
}
But what do I apply the role to? perhaps
class Object does doc
Now
sub f2c (Num $temp doc Temperature in degrees F) {...}
works(I think): trait_verb:doc is a sub, not a method, and so parens are
not needed.
It works, but that doesn't read too well. We do need a verb there. docs,
perhaps? Or gloss, which is both a noun and a verb?
--abhijit
Re: Scope exit and timely destruction
You could change the GC scheme (*cough*) to use one similar to Python's (ref-counting + additional GC for cyclic references *double-cough*). Out-of-this-world-ly yours, Michael On Fri, 14 Jan 2005 14:40:43 -0700, Luke Palmer [EMAIL PROTECTED] wrote: Hildo Biersma writes: If the number of objects that needs this is relatively small, we could play a trick somewhat like the following (with small changes to the perl compiler): 1. Break the filehandle object into two: a generic wrapper that uses refcounting and forwards all calls, plus the actual filehandle object. There seems to be a misconception about refcounting, and it's showing up here. People seem to think that you can do it to certain objects and not others. The fact is, right now when we're wiggling around PMCs we're just changing some pointers. But if there is one object that likes to be refcounted, then *every* pointer change needs to do the refcount dance. It's a big, potentially cache-blowing speed hit for the whole virtual machine. You can't do refcounting selectively. It's all or none. Of course, in C++, you can, because you tell C++ which pointers are refcountable pointers at compile time. If, by static analysis, we could tell Parrot when PMCs need refcounting before it assembled the bytecode, and also in some other places, we might be able to pull it off. But that's a halting problem problem if the language from which we're compiling is untyped. What I'd most like is to convince Larry to waive the timely destruction requirement. However, that doesn't really solve the problem for other languages that need timely destruction. Are there any? Luke
Re: Scope exit and timely destruction
Hum hum hum. What exactly does destroying mean in Perl 6? As memory
is managed it probably refers to invoking a finalizer..?
If yes, then you could also use an explicit construct such as C++'s
auto_ptr the likes (read: an auto declaration), C# using()
mechanism (read: a block statement thing which gets expanded to the
perl equivalent of foo = ...; try { ... } finally { foo.Dispose(); }
or simply implement a using function (or the more general
UNWIND-PROTECT, as in CL).
Latter would have the advantage of not requiring extra syntax.
- Michael
On Sat, 15 Jan 2005 01:28:22 +, Shevek [EMAIL PROTECTED] wrote:
In which Tigger maintains that code relying on timely destruction in
perl5 is buggy [and relatively rare], and agrees wholeheartedly with
Rabbit on almost everything else.
On Fri, 2005-01-14 at 17:52 -0700, Luke Palmer wrote:
Shevek writes:
The example you described destroyed a ref within a sub, and then assumed
that the object refed would be destroyed at scope exit.
I'm assuming you're referring to my Perl example, which you tactfully
omitted in order to lose the casual reader. Very cunning. :-)
My mistake, I was too heavy with [del]. I meant to put it back in.
Here it is again:
my %data;
sub a {
open my $fh, somefile;
$data{fh} = $fh;
}
sub b {
%data = ();
# $fh is destroyed here, not at scope exit
foo();
bar();
# not here.
}
a();
# ...
b();
And what I mean is that most approximate solutions won't destroy $fh in
time. One example of such a proposal is keeping tabs on objects in the
Timely destruction in C++ (I think the only language we have mentioned
which _officially_ implements it) only happens at scope exit. Timely
destruction in Perl5 happens (probably) kind of when the ref goes away,
although I don't think even that is guaranteed, my memory of temporaries
and targets is too fuzzy.
current scope which need timely destruction and then do a sweep whenever
we lose a reference to one. Another is using generational schemes.
Generational schemes are good for finding *enough* dead objects quickly
when we run out of memory, but they're not good for finding whether a
particular object is dead.
But they may be adequate in a pinch for handling many simple cases of
timely destruction. However we are likely to dig the same hole as perl5
where programmers rely on the behaviour [see bottom].
However, Perl 5, since it uses refcounting everywhere, has no problem
with this. Parrot has decided not to use refcounting at all (a decision
that I think I agree with), and so we have this problem.
This is incorrect: the object refed should be destroyed when the ref is
destroyed in a general refcounting GC system.
And I don't understand what you mean here.
The example above demonstrates.
Anyway, this led me to the (useful?) thought that you could delink the
concept of timely GC and destruction at scope exit by registering
atexit() or atleave() code on a scope (like finally{}) which explicitly
undef'd registered PMCs. That way you would be able to guarantee
destruction even if the PMC was still ref'd, which is probably more use
for things like critical section locks than just relying on a
side-effect of the GC, and is certainly easier to implement since it's
just a flag on the lexical in the pad.
Precisely! But if we have to support this area of Perl 5 (I'm not
certain that we do yet), we have to implement its semantics
backward-compatibly. The programmer of Perl 5 relied on the side
effects because they worked then. So we're not allowed to break them.
I maintain that relying on those semantics is a clear violation of the
documentation, as explicitly stated somewhere I can't immediately find,
but someone else must be able to find the passage. Such code may be
considered broken. I also suspect it's not a hugely common case.
And because of Perl 6's many lexical scope hooks, I hope that we can get
rid of any timely destruction policy, to encourage the use of lexical
hooks instead of destruction rules.
Yes. Lexical hooks good.
No matter how we slice it, it would royally suck to add a sweep at the
end of every lexical scope.
I wouldn't worry too much about a last-generation sweep at that point,
especially if we know which zones are in scope (as opposed to extent) at
that time. However, I doubt anyone is going to implement this.
S.
Re: Dimension of slices; scalars versus 1-element arrays?
6 elements..? On Mon, 10 Jan 2005 07:33:11 -0800, David Storrs [EMAIL PROTECTED] wrote: On Sat, Jan 08, 2005 at 11:37:06AM -0700, Craig DeForest wrote: @a[4; 0..5]; a 1x6 array (probably correct)? Or a 6 array (probably not correct)? For the ignorant among us (such as myself), what is a 6 array? Google and pdl.perl.org did not yield any immediate answers. --Dks -- [EMAIL PROTECTED]
Re: mandelbrot
On Tue, 14 Dec 2004 10:07:43 -0500 (EST), Jeff Horwitz [EMAIL PROTECTED] wrote: is it useful? not really. does it help you waste 5 minutes of your day? certainly. :) Waiting for the request to time out indeed wasted some idle time :-) wink-ingly yours, Michael
Re: mandelbrot
Ah yep, that surely is the reason. Too bad, have to wait until I get home ;-) - Michael On Tue, 14 Dec 2004 11:25:32 -0500 (EST), Jeff Horwitz [EMAIL PROTECTED] wrote: hm, works fine for others. maybe the weird port i'm using for that web server isn't agreeing with your firewall. -jeff On Tue, 14 Dec 2004, Michael Walter wrote: On Tue, 14 Dec 2004 10:07:43 -0500 (EST), Jeff Horwitz [EMAIL PROTECTED] wrote: is it useful? not really. does it help you waste 5 minutes of your day? certainly. :) Waiting for the request to time out indeed wasted some idle time :-) wink-ingly yours, Michael
Re: Premature pessimization
On Sun, 5 Dec 2004 11:46:24 -0700, Luke Palmer [EMAIL PROTECTED] wrote: Leopold Toetsch writes: This term came up in a recent discussion[1]. But I'd like to give this term a second meaning. Except what you're talking about here is premature *optimzation*. Yes, indeed. Cheers, Michael
Re: [CVS ci] opcode cleanup 1 - minus 177 opcodes
There is also such thing as premature pessimization. I'm not in the position to judge whether it is appropriate in this case, though. Back-to-reading-mode-ly yours, Michael On Mon, 29 Nov 2004 20:25:48 -0500, Dan Sugalski [EMAIL PROTECTED] wrote: At 8:29 AM +0100 11/28/04, Leopold Toetsch wrote: Thomas Seiler [EMAIL PROTECTED] wrote: Dan Sugalski wrote: At 10:34 AM +0100 11/27/04, Leopold Toetsch wrote: See also subject Too many opcodes. [...] Could you undo this please? Now is not the time to be trimming ops out. When is the time? After another 1000 opcodes are in, which all ought to be functions? Yes. Y'know, when we start doing the optimization based on a fully designed and implemented engine. Anything before that's premature. (Shall I go dig up a half dozen or more archive references with you chiding me for premature optimizations?) OTOH, it won't hurt anyone and it is already in. That's my point. Then your point's wrong. This patch broke a lot of my code. You keep wanting to chop things out of the core. Stop. That's not your call -- it's mine, and it will be made, but not now. Put these back. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Fwd: Re: Parrot BASIC
On Tue, 16 Nov 2004 21:59:39 +0100, Klaas-Jan Stol [EMAIL PROTECTED] wrote: (I've been trying a lot to implement a Lua compiler (version 5), but I'm seriously stuck on generating code for assignments (it's not as simple as it seems, but then again, I may be thinking in the wrong direction; for that I need either an implementation example (doesn't do Perl do multiple assignments? (i.e. a, b, c = c, b, a) , but that's another story).) I've no idea, but Python does. a, b, c = c, b, a = (a, b, c) = (c, b, a) What's the matter exactly (maybe we should continue that off-list)? Cheers, Michael
Re: Continuations, basic blocks, loops and register allocation
On Mon, 15 Nov 2004 17:19:01 -0500, Matt Fowles [EMAIL PROTECTED] wrote: Which gives me an evil idea. We could allow bytecode to specify that it wanted to start taking full continuations everywhere, but that these would never be used below it on the callstack. Thus the regex engine could do this and not suffer too much efficiency loss for taking new continuations for every backtrack point. This is not really evil - it's known as an escape continuation or weak continuation, or - more commonly - as an exception. Cheers, Michael
Re: Tail calls and continuations
On Thu, 11 Nov 2004 12:30:16 -0500, Dan Sugalski [EMAIL PROTECTED] wrote: Tail calls should be explicit, compile-time things. Otherwise we're going to run afoul of traceback requirements and suchlike things, and I think that's just not worth the risk and hassle. Besides, it's a lot easier in general for a language compiler to decide when a tail call's in order than it is for us. Fully agreed. Even further, it's necessary for some languages (Scheme)/paradigms (loop by recursion) that a tailcall is not just a hint but mandatory. Cheers, Michael
Re: Tail calls and continuations
On Thu, 11 Nov 2004 21:59:06 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: Above is *without* tail calls. The next one was with tail calls, and it obviously did succeed, because tail calls do not contribute to any kind of stack depth. So there is for sure no limit. It's the same as an iteration loop for the recursive tail call case - no limits. That's great to hear (this is the point I was trying to make before). Michael
Re: Tail calls and continuations
Scheme is a counterexample, it supports both mandatory tail calls continuations. I've no idea how stuff is implemented in Parrot, but an obvious idea would be to have some kind of lazy copying scheme (i.e. maintain a reference count for the stack frames copy the respective one before mutating it in a tail call, if necessary). Cheers, Michael On Wed, 10 Nov 2004 10:40:45 -0800, Jeff Clites [EMAIL PROTECTED] wrote: I was thinking: Implementing tail calls seems easy; the normal calling sequence of do some setup, then jump just turns into don't bother with (most of) the setup, just jump. That is, don't move a new register base-pointer into place, etc. But there's one wiggle: If you've created a continuation previously (and it still exists), then any call has to preserve the frame--you basically can't do a tail call, with its key implication of the current frame vaporizing, or being re-used (depending on how you want to describe it). But that's not too much of a problem, with the following: 1) Consider a tailcall op a recommendation--but have the VM do a regular call, if necessary. 2) Regular calls create continuations, so you can't do a tail call out of a function, if you've already done a regular call inside that function, _unless_ we have an (efficient) way to tell if any such continuation was saved. You can figure some of that out at compile-time (whether a regular call could have been already made), but you'd need runtime checks for other cases, unless you just forego a tail call any time you _could_ have already done a regular call (which avoids the runtime checks, but allows less actual tail calls). Do any existing languages have both tail calls and continuations? Scheme mandates that anything which looks like a tail call, must be optimized as expected (other languages like Lisp merely permit it), but I don't know of Scheme having continuations. Scheme cares, of course, so that you can have ostensibly unlimited recursion, without running out of stack space (or really, memory). Tail calls and continuations seem a bit like opposites--one preserves state, the other destroys it. Just thought I'd send out these thoughts, since the topic was mentioned recently. JEff
Re: Does Parrot have True coroutines?
I sense confusion between closure, continuation and coroutine. http://c2.com/cgi/wiki?ContinuationExplanation http://c2.com/cgi/wiki?ContinuationsAndCoroutines http://c2.com/cgi/wiki?CoRoutine http://c2.com/cgi/wiki?LexicalClosure Cheers, Michael On Thu, 04 Nov 2004 22:11:07 +0100, Klaas-Jan Stol [EMAIL PROTECTED] wrote: Well, I don't know how true coroutines are defined, but Parrot, as it's CPS based, has no problems with coroutines and there are no restrictions to coroutines, AFAIK. To be honest, I hadn't thought of this, either (this true-ness of coroutines), but then again, I'm no expert on these things. How coroutines finally really behave WRT argument passing isn't really layed out. There is a good article in Dan's blog IIRC. I'll read it again. co = coroutine.create(function () for i=1,10 do print(co, i) coroutine.yield() end end) In Parrot's enough to include a .yield() ... ,--[ simplest usage ]- | $ cat coro.imc | .sub main @MAIN | $I0 = coro() | print $I0 | $I0 = coro() | print $I0 | .end | .sub coro | .yield(4) | .yield(2) | .end | | $ ./parrot coro.imc | 42 `- I hadn't seen .yield(x) Is .yield(x) the same as: .pcc_begin_yield .return x .pcc_end_yield ? to get a static coroutine. Above Lua snippet would use the Cnewsub opcode to create a Coroutine function object. Such objects act as closures too (modulo untested, unimplemented features ;) So, correct me if I'm wrong, a Coroutine is also a closure? In that case, anytime you would create a closure, you could also create a coroutine? I've also included the reply I got from Roberto: quote Untested code: function f(x) A = function () x=x+1 end B = coroutine.wrap( function (y) C = coroutine.wrap( function (z) while true do coroutine.yield(x+y+z) end end) while true do y=y+1 coroutine.yield() end end) end X = f() -- Now we have: - function A: each call increments x (in the main thread) - coroutine B: each call increments y (in that coroutine) - coroutine C: each call returns x+y+z (each in a different coroutine) Of course, all this wold be more fun with recursion :) -- Roberto /quote Do you think the above code snippet could work? That is, without much special code, can this be done in PIR? (Of course, why would one ever want to write /such/ code :-P, but that's another issue) Thanks, Klaas-Jan
Re: macros, local variables...
gensym, hehe. History repeats ;-) - Michael On Thu, 07 Oct 2004 21:49:22 -0400, William Coleda [EMAIL PROTECTED] wrote: A macro example in the docs shows: .macro swap (A,B,TEMP) # . marks the directive set .TEMP,.A # . marks the special variable. set .A,.B set .B,.TEMP .endm # And . marks the end of the macro. Is there a way to write this macro without specifying the TEMP parameter? For example, something like: .macro swap (A,B) .local pmc .TEMP .TEMP = .A .A = .B .B = .TEMP .endm I've tried a few obvious permutations, but don't see anything that works as is.
Re: Metaclasses
http://members.rogers.com/mcfletch/programming/metaclasses.pdf On Mon, 4 Oct 2004 11:45:50 -0400, Dan Sugalski [EMAIL PROTECTED] wrote: Okay, color me officially confused. I'm working on the assumption that metaclasses are needed, but I don't, as yet, understand them. So, with this bit of ignorance exposed, could someone point me to a good explanation of what they are and how they work? Theory's fine (possibly better than fine :) or if someone's local to me and wants to sit me down and fill me in, that'd be fine too. (I am, alas, limited to docs that're on-line. My book budget's blown for the year or I'd go track down the smalltalk book everyone points to as the Good Resource for 'em) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
