> ---
>
> We need private methods for objects.
>
> ---
just a comment on how this is done for ruby:
#initially objects are created with a given class
#say aFoo is an instance of class Foo
aFoo = Foo.new
#then we can add methods to aFoo
def aFoo.bar()
puts 'invoked bar'
end
#th
>
> If you only allow yeilding from the outermost level of scope in a routine,
> you can do evil things with Duff's Device. Which is what Python does. (But
> it's sufficient for most purposes)
>
> Dan
>
Duff's device being evil enough in and out of itself I'm not sure I see what
this
has to do wit
> As
> for general continuations, I can't remember when I've last used
> co-routines... college?
>
> It seems that the Python people have figured a simple way to
> implement generators. That said... I'd hate to have a generator
> request promoted into a continuation request and then get dumped
>
just to make a point what you are talking about is not destruction (as in
c++)
but finalization (as in any gced language) the difference being in the
determinism.
Destruction is almost always necessary in c++ since the memory allocated
need to
be deallocated. Like you justly specify finalization
> > >Q: What about all the others?
> > >A: *What* others? That's it, unless you count perl, python, or ruby.
> >
> >I thought Pascal's (ancient) p-code was a stack VM... Yup, some web
> >pages that I can find in a hurry, confirm that.
>
> Right, but back then they called 'em "p-code interpreter"
Hi,
as Michael G Schwern showed me I posted a wrong information about ruby
in this list, after testing I found that ruby and perl performance are
roughly equivalent in very simple tests such as a fibonacci's series
computation. My misconception came from an older benchmark I did and it
did not i
Where I studied, they liked ML (objective caml actually) and prolog...
Benoit
- Original Message -
From: "Dan Sugalski" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "Perl 6 Internals" <[EMAIL PROTECTED]>
Sent: Monday, November 19, 2001 6:57 PM
Subject: Re: What happened at little language
> Dan wrote:
> I've reasonably good hope for Ruby, too, but nobody seemed to have heard
of
> it. That's hopefully changed. (I made a point of mentioning it, as it is a
> really nice language and one of our targets)
Yes, I discovered it a year ago and fell in love with the language, now what
it
nee
> There is an effort to compile ruby to the CLR, I don't know more,
> because I can't read japanese :-) And there is someone working on python
> support in the mono compiler, too.
> BTW: we just got our compiler running on linux and compiling a simple
> program, hopefully by next week it can be us
>
>As a last sort of alternative. I had invisioned PMC's has having separate
>vtables for each of the many different types of operations. Meaning, that
a
>scalar-int would be separate from a scalar-string-num, etc. Since it seems
>that we're not currently doing this, it would require 8 times as
> Yes, maybe... but they show many functional and scripting languages
> working, like Haskell, ML, Python and Perl... but that's not the point.
Yes you can do it and you can also do it on the jvm but they are slow...
With the clr I think its not as bad as with the jvm though.
Benoit
> At 10:22 AM 11/8/2001 -0700, Nathan Torkington wrote:
> >I haven't seen much activity surrounding this. I figured there'd be a
> >flood with everyone writing support for their own favourite data
> >types. What's up?
>
> We're not quite there yet with docs and environment, I think.
>
> I'm abou
> On Wed, Nov 07, 2001 at 06:46:20PM -0500, Ken Fox wrote:
> >
> > JITs help when the VM is focused on lots of small instructions
> > with well-known, static semantics. Perl's use of Parrot is going
> > to be focused almost completely on PMC vtable ops. A JIT has
> > no advantage over a threaded
> IMHO, a less dynamic perl is perl no more, though some consideration
> should be made to make it easier to implement the language on virtual
> machines such as the JVM and CLR.
> That said, I'm open to sneak into mono opcode handling that may make it
> easier to run parrot code there, if it is
- Original Message -
From: "James Mastros" <[EMAIL PROTECTED]>
To: "Dan Sugalski" <[EMAIL PROTECTED]>
Cc: "Benoit Cerrina" <[EMAIL PROTECTED]>; "Uri Guttman"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL
>At 09:36 PM 11/4/2001 +0100, Benoit Cerrina wrote:
>
>> > While the PMC structures themselves don't move (no real need--there of
>> > fixed size so you can't fragment your allocation pool, though it makes
>>Sorry can you expand on this. I don't se
>
>- Original Message -
>From: "Michael L Maraist" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Sunday, November 04, 2001 10:10 PM
>Subject: Re: Rules for memory allocation and pointing
>
>
>On Sunday 04 November 2001 03:36 pm, Be
> While the PMC structures themselves don't move (no real need--there of
> fixed size so you can't fragment your allocation pool, though it makes
Sorry can you expand on this. I don't see the relation between the data
being fixed size and the memory not becomming fragmented.
> generational colle
> I think your approuch is much better and cleaner than mine, my brain was
> limited to unix :) so I never worried about anything besides gcc.
> It would also be nice if you can decide which dispatch method use instead
> of asking.
Hum, I think you mean linux, maybe BSD, but the other unixes com
> There will be a mechanism to register PMCs with the interpreter to note
> they're pointed to by something that the interpreter can't reach. (For
> example, a structure in your extension code, or via a pointer stashed in
> the depths of a buffer object, or referenced by another interpreter) This
>
> dan at his recent talk at boston.pm's tech meeting said he was leaning
> towards a copying GC scheme. this would be the split ram in half design
> and copy all objects to the other half at CG time. the old half is
> reclaimed (not even reclaimed, just ignored!) in one big chunk.
>
This schemes
- Original Message -
From: "Ken Fox" <[EMAIL PROTECTED]>
To: "Uri Guttman" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, October 30, 2001 7:05 AM
Subject: Re: Improved storage-to-storage architecture performance
> Uri Guttman wrote:
> > so my point is t
Excuse me,
It is clear that PMCs are object but does the acronym has a signification?
Where can such things be found.
Thank you
Benoit
> We'll be introspective, but probably differently. We at least need to do
> things in ways both perl and python can easily stomach, and I think that's
> going to end up looking different than this will.
>
And ruby ;-)
Benoit
24 matches
Mail list logo
