---
We need private methods for objects.
---
just a comment on how this is done for ruby:
code
#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
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
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 with
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 which was far
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
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
needs
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 languages?
At
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 used
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
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
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 about to go
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
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 come
- Original Message -
From: James Mastros [EMAIL PROTECTED]
To: Dan Sugalski [EMAIL PROTECTED]
Cc: Benoit Cerrina [EMAIL PROTECTED]; Uri Guttman
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Monday, November 05, 2001 12:03 AM
Subject: Re: vmem memory
- 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 the the speed
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
19 matches
Mail list logo
