Re: apo 2
On Fri, May 04, 2001 at 03:00:59PM +0100, Michael G Schwern wrote: > On Fri, May 04, 2001 at 09:51:53AM -0400, John Porter wrote: > > And btw . . . Wouldn't > > > > $thing has property > > > > make more sense than > > > > $thing is property > > "$foo has true" doesn't flow as well as "$foo is true". Dunno quite > what the other expected uses are. Veracity is the ability to be true. Veracity is the property of truthfulness? $thing has veracity. $thing's veracity is true. An object environment I prototyped a few years ago used something similar. There were five levels of objects: Level 0 object: object (the fundamental building block of the universe) Level 1 objects: aspect (a reusable property for templates) is an object template (an intangible, ideal object) is an object Aspects (level 2): clothing (the ability to be worn) is an aspect containable (the ability to be somewhere) is an aspect container (the ability to contain things) is an aspect lidded (the ability to be sealed) is an aspect owner (the ability to own something) is an aspect posession (the ability to be owned) is an aspect session (the ability to service connections) is an aspect shell (the ability to parse commands) is an aspect tcpd (the ability to accept tcp socket connections) is an aspect etc. Templates (level 3): actor (a base class for players) is a template with container, containable, session and shell properties. container (an ideal tangible container) is a template having container properties. lidded container (an ideal sealable container) is a template having container and lidded properties. login daemon (something which answers remote connections and authenticates identities) is a template having tcpd properties. thing (an ideal tangible object) is a template with containable and posession properties. etc. Real tangible objects (level 4): the login server is a login daemon rocco is an actor rocco's backpack is a lidded container schwern is an actor schwern's pants are clothing schwern's fish is a thing etc. Hmm... perhaps I should include magic clothing: a template with clothing, container and lidded properties. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: use parrot;
On Sun, Oct 21, 2001 at 12:20:29PM -0400, Dan Sugalski wrote: > > I suppose. I hadn't planned on inlining parrot assembly into any other > language. (The first person who suggests an asm() function *will* get > smacked... :) You'll certainly be able to use modules written purely in > parrot assembly. 1. B::Parrot 2. Parrot.xs 3. Providing opcodes for libperl functions and linking it in. I haven't suggested asm(), so technically I'm safe. Right? :) -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Re: How shall threads work in P6?
On Mon, Mar 31, 2003 at 10:50:59AM -0800, Michael G Schwern wrote: > 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. It's very easy to automatically translate threads at the language level into cooperative instructions at the VM level. I proposed it to perl5-porters in February 1997, and I proposed it to perl6-language in January 2001. At the language level, cooperative multitasking would look and feel like plain threads. I think this would allow the language to reconcile threading and callback-based I/O, but I agree it would add weight to the VM that most people don't want. > 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. Cooperative threads at the VM level don't preclude support for true threads. For example, it should be possible create a fixed number of threads that act as execution pipelines for a cooperative VM. Divorcing the system threads from the language threads gives you a couple interesting possibilities. It's possible to tune the number of system threads Perl uses. Threads tend to scale poorly after they run out of CPUs. Developers can take this into consideration and limit the number of threads a program uses. Programs are still free to spawn as many "threads" as they want, even if they request more threads than the operating system can provide. > 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. Agreed. > Cooperative multitasking, if you really want it, can be bolted on later or > provided as an alternative backend to a real threading system. Disagreement, but I've grown accustomed to it. Carry on. -- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
