Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 11:52 AM + 1/27/03, Piers Cawley wrote:
>>Dan Sugalski <[EMAIL PROTECTED]> writes:
>>
>>> At 9:24 PM + 1/21/03, Piers Cawley wrote:
Dan Sugalski <[EMAIL PROTECTED]> writes:
> Hrm, interesting. Single symbol table for methods and att
At 11:52 AM + 1/27/03, Piers Cawley wrote:
Dan Sugalski <[EMAIL PROTECTED]> writes:
At 9:24 PM + 1/21/03, Piers Cawley wrote:
Dan Sugalski <[EMAIL PROTECTED]> writes:
> Hrm, interesting. Single symbol table for methods and attributes,
though that's not too surprising all things co
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 9:24 PM + 1/21/03, Piers Cawley wrote:
>>Dan Sugalski <[EMAIL PROTECTED]> writes:
>> > Hrm, interesting. Single symbol table for methods and attributes,
>>> though that's not too surprising all things considered. That may make
>>> interoperabili
At 8:16 PM +0530 1/23/03, Gopal V wrote:
If memory serves me right, Erik Bågfors wrote:
> Ruby needs to call the missing_method method (if I remember correctly).
So if "foo" doesn't exist, it would be good to be able to override
callmethods behavior and make it call missing_method.
like I sa
At 1:46 PM -0500 1/22/03, Christopher Armstrong wrote:
On Wed, Jan 15, 2003 at 01:57:28AM -0500, Dan Sugalski wrote:
At 9:37 PM -0500 1/14/03, Christopher Armstrong wrote:
>But who knows, maybe it could be made modular enough (i.e., more
>interface-oriented?) to allow the best of both worlds -
At 8:42 AM +0100 1/23/03, Erik Bågfors wrote:
On Wed, 2003-01-22 at 19:46, Christopher Armstrong wrote:
On Wed, Jan 15, 2003 at 01:57:28AM -0500, Dan Sugalski wrote:
> At 9:37 PM -0500 1/14/03, Christopher Armstrong wrote:
> >But who knows, maybe it could be made modular enough (i.e., more
>
At 10:10 PM +0530 1/23/03, Gopal V wrote:
If memory serves me right, Erik Bågfors wrote:
But if I write a library in ruby that depends on the missing_method
method it will not be usable from other languages, since those languages
doesn't call missing_method if the method they try to call does
If memory serves me right, Erik Bågfors wrote:
> But if I write a library in ruby that depends on the missing_method
> method it will not be usable from other languages, since those languages
> doesn't call missing_method if the method they try to call doesn't
> exist.
Hmm... that's twisting lang
On Thu, 2003-01-23 at 15:46, Gopal V wrote:
> > Ruby needs to call the missing_method method (if I remember correctly).
> > So if "foo" doesn't exist, it would be good to be able to override
> > callmethods behavior and make it call missing_method.
>
> like I said , the compiler designer can put
If memory serves me right, Erik Bågfors wrote:
> > :-) Python basically requires that each step in the process be
> > overridable. (1. look up attribute 2. call attribute, at least in
> > `callmethod's case).
would this be more of what you need ?
obj.__dict__["foo"].__call__();
/me again shows
Christopher Armstrong:
# On Wed, Jan 15, 2003 at 01:57:28AM -0500, Dan Sugalski wrote:
# > At 9:37 PM -0500 1/14/03, Christopher Armstrong wrote:
# > >But who knows, maybe it could be made modular enough (i.e., more
# > >interface-oriented?) to allow the best of both worlds --
# I'm far too
# > >
On Wed, 2003-01-22 at 19:46, Christopher Armstrong wrote:
> On Wed, Jan 15, 2003 at 01:57:28AM -0500, Dan Sugalski wrote:
> > At 9:37 PM -0500 1/14/03, Christopher Armstrong wrote:
> > >But who knows, maybe it could be made modular enough (i.e., more
> > >interface-oriented?) to allow the best of b
On Wed, Jan 15, 2003 at 01:57:28AM -0500, Dan Sugalski wrote:
> At 9:37 PM -0500 1/14/03, Christopher Armstrong wrote:
> >But who knows, maybe it could be made modular enough (i.e., more
> >interface-oriented?) to allow the best of both worlds -- I'm far too
> >novice wrt Parrot to figure out what
heory."
-???
> -Original Message-
> From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 22, 2003 2:55 AM
> To: Piers Cawley
> Cc: Christopher Armstrong; [EMAIL PROTECTED]
> Subject: Re: Objects, finally (try 1)
>
>
> At 9:24 PM + 1/21/03, Piers
At 9:24 PM + 1/21/03, Piers Cawley wrote:
Dan Sugalski <[EMAIL PROTECTED]> writes:
> Hrm, interesting. Single symbol table for methods and attributes,
though that's not too surprising all things considered. That may make
interoperability interesting, but I was already expecting that to som
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 3:06 PM -0500 1/15/03, Christopher Armstrong wrote:
>>On Wed, Jan 15, 2003 at 01:57:28AM -0500, Dan Sugalski wrote:
>>> At 9:37 PM -0500 1/14/03, Christopher Armstrong wrote:
>>> >But who knows, maybe it could be made modular enough (i.e., more
>>>
At 3:03 PM -0800 1/15/03, Jonathan Sillito wrote:
Sounds like we want objects *and* classes to support:
static_attribs - which are defined at compile time and
accessed by offset probably stored in an array.
dynamic_attribs - which come and go at run time and are
generally accessed by name and li
At 8:54 PM + 1/15/03, Nicholas Clark wrote:
On Wed, Jan 15, 2003 at 01:00:59AM -0500, Dan Sugalski wrote:
At 8:53 PM -0800 1/14/03, Adriano wrote:
>I think what Jonathan asked for was an operator for returning a
>method (as an object) which can be invoked later with some arguments
>(or
At 3:06 PM -0500 1/15/03, Christopher Armstrong wrote:
On Wed, Jan 15, 2003 at 01:57:28AM -0500, Dan Sugalski wrote:
At 9:37 PM -0500 1/14/03, Christopher Armstrong wrote:
>But who knows, maybe it could be made modular enough (i.e., more
>interface-oriented?) to allow the best of both worlds -
At 9:38 AM -0800 1/15/03, Jonathan Sillito wrote:
I realize this will vary from language to language, but generally we will
need a PMC that encapsulates a method (and responds to the invoke vtable
method like Sub, or maybe the Sub PMC could do?). This python code is
interesting:
a = A()
a.f()
At 11:44 AM -0600 1/15/03, Garrett Goebel wrote:
From: attriel [mailto:[EMAIL PROTECTED]]
>> > >I think what Jonathan asked for was an operator for
>> > >returning a method (as an object) which can be invoked
>> > >later with some arguments (or even applied with a
>> > >partial list of argum
At 11:44 AM -0500 1/15/03, attriel wrote:
>> > >I think what Jonathan asked for was an operator for
> >returning a method (as an object) which can be invoked
> >later with some arguments (or even applied with a
> >partial list of arguments for currying).
> >
> >This would be a lot more usef
At 10:28 AM -0600 1/15/03, Garrett Goebel wrote:
Peter Haworth wrote:
Dan Sugalski wrote:
> Adriano wrote:
> >
> >I think what Jonathan asked for was an operator for
> >returning a method (as an object) which can be invoked
> >later with some arguments (or even applied with a
> >partial li
If memory serves me right, Jonathan Sillito wrote:
> x = a.f # get the method, a limited form of currying
> # since the first arg (a==self) is stored
> x() # output: A.f()
>
> setattr(A, "f", g) # replace A's f with g
>
> a.f()# output: g()
> x() # output (still): A.f()
> "JS" == Jonathan Sillito <[EMAIL PROTECTED]> writes:
JS> Sounds like we want objects *and* classes to support:
JS> static_attribs - which are defined at compile time and
JS> accessed by offset probably stored in an array.
JS> dynamic_attribs - which come and go at run time and are
> -Original Message-
> From: Nicholas Clark [mailto:[EMAIL PROTECTED]]
> Sent: January 15, 2003 12:41 PM
> To: Dan Sugalski
> Cc: Gopal V; [EMAIL PROTECTED]
> Subject: Re: Objects, finally (try 1)
>
>
> On Wed, Jan 15, 2003 at 11:17:17AM -0500, Dan Sugalski wro
On Wed, Jan 15, 2003 at 01:00:59AM -0500, Dan Sugalski wrote:
> At 8:53 PM -0800 1/14/03, Adriano wrote:
> >I think what Jonathan asked for was an operator for returning a
> >method (as an object) which can be invoked later with some arguments
> >(or even applied with a partial list of arguments
On Wed, Jan 15, 2003 at 11:17:17AM -0500, Dan Sugalski wrote:
> In that case they'd correspond to our properties, and I can already
> feel a massive terminology disconnect looming. Maybe we should rename
> properties and attributes to frobs and thingies, just so there's no
> overlap. :(
We coul
At 3:10 PM + 1/15/03, Peter Haworth wrote:
On Wed, 15 Jan 2003 01:00:59 -0500, Dan Sugalski wrote:
At 8:53 PM -0800 1/14/03, Adriano wrote:
>I think what Jonathan asked for was an operator for returning a method
>(as an object) which can be invoked later with some arguments (or even
>appl
At 7:11 PM +0530 1/15/03, Gopal V wrote:
If memory serves me right, Dan Sugalski wrote:
rather than attributes, but I may be incorrect here. Are the current
python instance attributes both:
*) defined per object rather than per class
*) Essentially global, that is not hidden from parent clas
On Wed, Jan 15, 2003 at 01:57:28AM -0500, Dan Sugalski wrote:
> At 9:37 PM -0500 1/14/03, Christopher Armstrong wrote:
> >But who knows, maybe it could be made modular enough (i.e., more
> >interface-oriented?) to allow the best of both worlds -- I'm far too
> >novice wrt Parrot to figure out what
> Perhaps I'm misunderstanding Dan's meaning when he talks of invalidating
> method handles. In Perl5:
>
> package Foo;
> sub bar { print "hello world\n" }
> package main;
> my $cref = Foo->can('bar');
> undef *Foo::bar;
> Foo->$cref();
> Foo->bar();
> 1;
>
> would result in:
>
> hello world
> Can'
From: attriel [mailto:[EMAIL PROTECTED]]
>
> >> > >I think what Jonathan asked for was an operator for
> >> > >returning a method (as an object) which can be invoked
> >> > >later with some arguments (or even applied with a
> >> > >partial list of arguments for currying).
> >> > >
> >> > >This wou
I realize this will vary from language to language, but generally we will
need a PMC that encapsulates a method (and responds to the invoke vtable
method like Sub, or maybe the Sub PMC could do?). This python code is
interesting:
class A:
def f (self):
print "A.f()"
def g (self):
print "g
>> > >I think what Jonathan asked for was an operator for
>> > >returning a method (as an object) which can be invoked
>> > >later with some arguments (or even applied with a
>> > >partial list of arguments for currying).
>> > >
>> > >This would be a lot more useful than a yes-or-no
>> > >answer ab
Peter Haworth wrote:
> Dan Sugalski wrote:
> > Adriano wrote:
> > >
> > >I think what Jonathan asked for was an operator for
> > >returning a method (as an object) which can be invoked
> > >later with some arguments (or even applied with a
> > >partial list of arguments for currying).
> > >
> > >
On Wed, 15 Jan 2003 01:00:59 -0500, Dan Sugalski wrote:
> At 8:53 PM -0800 1/14/03, Adriano wrote:
> >I think what Jonathan asked for was an operator for returning a method
> >(as an object) which can be invoked later with some arguments (or even
> >applied with a partial list of arguments for curr
If memory serves me right, Dan Sugalski wrote:
> rather than attributes, but I may be incorrect here. Are the current
> python instance attributes both:
>
> *) defined per object rather than per class
> *) Essentially global, that is not hidden from parent classes or
> anything. (Basically one b
At 9:37 PM -0500 1/14/03, Christopher Armstrong wrote:
On Tue, Jan 14, 2003 at 03:00:17PM -0500, Dan Sugalski wrote:
At 11:44 AM -0800 1/14/03, Mr. Nobody wrote:
>Seems pretty reasonable, but don't you mean PerlRef, PerlAttr, PerlClass,
>PerlObject?
Nope. There's nothing particularly perlish
At 9:18 PM -0500 1/14/03, Christopher Armstrong wrote:
On Tue, Jan 14, 2003 at 12:38:35PM -0800, Jonathan Sillito wrote:
> -Original Message-
> From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> A property is a runtime assignable name/value pair that you stick on
> a variable or value.
At 8:53 PM -0800 1/14/03, Adriano wrote:
On Tue, 14 Jan 2003 17:18:22 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
Dan:
You're off. It'll be something like:
callmethod Px, "method_name"
or
jmpmethod Px, "method_name"
Jonathan:
Is there going to be any way to (in PASM) find a method with
At 6:16 PM -0500 1/14/03, attriel wrote:
Short version: I think both are good. Yes/No is inferrable from a
pointer, but if the pointer has to include other information (and thus be
a full PMC or however, precisely) seperate might be good.
I think we're going to have to go with can and method
On Tue, Jan 14, 2003 at 03:00:17PM -0500, Dan Sugalski wrote:
> At 11:44 AM -0800 1/14/03, Mr. Nobody wrote:
> >Seems pretty reasonable, but don't you mean PerlRef, PerlAttr, PerlClass,
> >PerlObject?
>
> Nope. There's nothing particularly perlish about them, and if we're
> going to have a common
On Tue, Jan 14, 2003 at 12:38:35PM -0800, Jonathan Sillito wrote:
> > -Original Message-
> > From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
>
> > A property is a runtime assignable name/value pair that you stick on
> > a variable or value. An attribute is a named variable that all
> > objec
> Dan:
>> Yep. There should be a can operator, though I'm not sure how often one
>> wants to check for the existence of a method in an object without
>> calling it. But no reason not to. More for rev 2.
Adriano:
> I think what Jonathan asked for was an operator for returning a method
> (as an o
On Tue, 14 Jan 2003 17:18:22 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
Dan:
You're off. It'll be something like:
callmethod Px, "method_name"
or
jmpmethod Px, "method_name"
Jonathan:
Is there going to be any way to (in PASM) find a method with out invoking
it? I am not sure, but it may
At 3:05 PM -0600 1/14/03, Garrett Goebel wrote:
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
Properties can come and go at runtime, but attributes are fixed. (I
think you could also consider attributes "instance variables", but
I'm a bit OO fuzzy so I'm not sure that's entirely right)
Both
At 1:24 PM -0800 1/14/03, Mr. Nobody wrote:
So a property is just an element in a hash attribute?
No. Properties are separate from anything OO.
--
Dan
--"it's like this"---
Dan Sugalski
At 12:38 PM -0800 1/14/03, Jonathan Sillito wrote:
> -Original Message-
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
A property is a runtime assignable name/value pair that you stick on
a variable or value. An attribute is a named variable that all
objects of a particular class h
--- Garrett Goebel <[EMAIL PROTECTED]> wrote:
> From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> > At 9:51 AM -0800 1/14/03, Jonathan Sillito wrote:
> > >
> > >Below are some questions about this ...
> >
> > And now some answers. :)
> >
> > >> From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> > >
>
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> At 9:51 AM -0800 1/14/03, Jonathan Sillito wrote:
> >
> >Below are some questions about this ...
>
> And now some answers. :)
>
> >> From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> >
> >[snip]
> >
> >> Objects, as far as I see it, have the followi
> -Original Message-
> From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> A property is a runtime assignable name/value pair that you stick on
> a variable or value. An attribute is a named variable that all
> objects of a particular class have.
>
> Properties can come and go at runtime, but
At 11:44 AM -0800 1/14/03, Mr. Nobody wrote:
Seems pretty reasonable, but don't you mean PerlRef, PerlAttr, PerlClass,
PerlObject?
Nope. There's nothing particularly perlish about them, and if we're
going to have a common base set of object functionality, they'll
probably be named ParrotRef/At
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 9:51 AM -0800 1/14/03, Jonathan Sillito wrote:
> >Dan,
> >
> >Below are some questions about this ...
>
> And now some answers. :)
>
> > > -Original Message-
> >> From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> >
> >[snip]
> >
> >> Objec
At 9:51 AM -0800 1/14/03, Jonathan Sillito wrote:
Dan,
Below are some questions about this ...
And now some answers. :)
> -Original Message-
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
[snip]
Objects, as far as I see it, have the following properties:
1) They have runtime-
Dan,
Below are some questions about this ...
> -Original Message-
> From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
[snip]
> Objects, as far as I see it, have the following properties:
>
> 1) They have runtime-assignable properties
Terminology question: what is the difference between a p
On Fri, 10 Jan 2003 11:49:14 -0500, Dan Sugalski wrote:
> At 1:37 PM + 1/10/03, Peter Haworth wrote:
> >On Thu, 9 Jan 2003 16:40:20 -0500, Dan Sugalski wrote:
> >> #10 We do MI, but we don't instantiate a class' attributes multiple
> >>times if its in the hierarchy for a class more than on
At 10:07 AM -0800 1/12/03, Brent Dax wrote:
Gopal V:
# But coming back to parrot ... I don't think parrot uses UTF8
# (from what I could gather it seems to be all ASCII ?) ... Or
# is UTF8 hiding in
# somewhere ?...
Parrot will have a "default string type" that's build-specific, so that
e.g. Asia
At 7:27 PM +0530 1/12/03, Gopal V wrote:
But coming back to parrot ... I don't think parrot uses UTF8 (from what
I could gather it seems to be all ASCII ?) ... Or is UTF8 hiding in
somewhere ?...
Unicode is hiding in the ICU directory, which we need to get
integrated. We'll probably be mostly U
Gopal V:
# But coming back to parrot ... I don't think parrot uses UTF8
# (from what I could gather it seems to be all ASCII ?) ... Or
# is UTF8 hiding in
# somewhere ?...
Parrot will have a "default string type" that's build-specific, so that
e.g. Asian nations can have whatever the most popu
On 01/12/03 Gopal V wrote:
> If memory serves me right, Paolo Molaro wrote:
> > The CLR runtimes use 16 bit chars and UTF16-encoded strings (at least as
> > far as it's visible to the 'user' programs).
>
> 1023.2.3 #Strings heap
> 11 The stream of bytes pointed to by a "#Strings" h
If memory serves me right, Paolo Molaro wrote:
> The CLR runtimes use 16 bit chars and UTF16-encoded strings (at least as
> far as it's visible to the 'user' programs).
1023.2.3 #Strings heap
11 The stream of bytes pointed to by a "#Strings" header is the physical
representation o
On 01/11/03 Nicholas Clark wrote:
> > This allows us to declare 8bit characters and strings of those and all the
> > stuff we're used to with C like unions ... (C# has 16bit chars, and strings
> > are UTF8 encoded , IIRC) ...
>
> That doesn't sound right. But if it is right, then it sounds very w
At 6:12 PM +0100 1/10/03, Jerome Quelin wrote:
Dan Sugalski wrote:
and who's got
questions on how this works? (I can put together examples, but this
is pretty long as it is, and I think it's reasonably
self-explanatory. Besides, assembly language isn't generally the best
way to demonstrate a
At 4:08 PM + 1/11/03, Nicholas Clark wrote:
On Thu, Jan 09, 2003 at 04:40:20PM -0500, Dan Sugalski wrote:
The find_method vtable entry should die, and be replaced with a plain
method entry. This should return either the address of the start of
the method's bytecode, or NULL. The NULL retur
If memory serves me right, Nicholas Clark wrote:
> That doesn't sound right. But if it is right, then it sounds very wrong.
>
> (Translation: Are you sure about your terms, because what you describe sounds
> wonky. Hence if they are using UTF8 but with 16 bit chars, that feels like a
> silly desig
On Sat, Jan 11, 2003 at 06:34:56PM +0530, Gopal V wrote:
> If memory serves me right, Nicholas Clark wrote:
> > fussy. I presume Rhys is thinking about compiling C code to parrot, and then
> > linking through to native C code (such as the native standard C library) via
> > parrot.
>
> Nope ... At
If memory serves me right, Nicholas Clark wrote:
> fussy. I presume Rhys is thinking about compiling C code to parrot, and then
> linking through to native C code (such as the native standard C library) via
> parrot.
Nope ... At least for our .NET platorm stuff ,we are planning to compile
glibc i
On Sat, Jan 11, 2003 at 10:12:42AM +0530, Gopal V wrote:
> If memory serves me right, Chris Dutton wrote:
> > Actually, if you really want Eiffel to compile to Parrot, it might be
> > interesting to work on getting ANSI C to compile to Parrot first, since
> > most Eiffel compilers use compilation
Jerome Quelin wrote:
Dan Sugalski wrote:
... Besides, assembly language isn't generally the best
way to demonstrate anything... :)
Indeed, once you wrote some Parrot assembly code to support a^Htwo
stupid^Wesoteric languages, Parrot assembly is quite a nice and easy
way to see how theory b
If memory serves me right, Chris Dutton wrote:
> Actually, if you really want Eiffel to compile to Parrot, it might be
> interesting to work on getting ANSI C to compile to Parrot first, since
> most Eiffel compilers use compilation to C as an intermediate step.
This won't be too much of stretch
ond to attriel
To: <[EMAIL PROTECTED]>
cc:
Subject:Re: Objects, finally (try 1)
> On Thu, 9 Jan 2003 16:40:20 -0500, Dan Sugalski wrote:
>> #10 We do MI, but we don't instantiate a class' attributes multiple
>> times if its
On Friday, January 10, 2003, at 11:49 AM, Dan Sugalski wrote:
At 1:37 PM + 1/10/03, Peter Haworth wrote:
This will mean we can't support Eiffel
Nope. :)
What it means is that the proposed base object system won't work for
eiffel.
Actually, if you really want Eiffel to compile to Parrot,
Dan Sugalski wrote:
> and who's got
> questions on how this works? (I can put together examples, but this
> is pretty long as it is, and I think it's reasonably
> self-explanatory. Besides, assembly language isn't generally the best
> way to demonstrate anything... :)
Well, as far as I'm concerned
At 10:37 AM -0500 1/10/03, attriel wrote:
> On Thu, 9 Jan 2003 16:40:20 -0500, Dan Sugalski wrote:
#10 We do MI, but we don't instantiate a class' attributes multiple
times if its in the hierarchy for a class more than once. If it is,
the leftmost instance is real, the rest are virtual
My
At 1:37 PM + 1/10/03, Peter Haworth wrote:
On Thu, 9 Jan 2003 16:40:20 -0500, Dan Sugalski wrote:
#10 We do MI, but we don't instantiate a class' attributes multiple
times if its in the hierarchy for a class more than once. If it is, the
leftmost instance is real, the rest are virtual
> On Thu, 9 Jan 2003 16:40:20 -0500, Dan Sugalski wrote:
>> #10 We do MI, but we don't instantiate a class' attributes multiple
>> times if its in the hierarchy for a class more than once. If it is,
>> the leftmost instance is real, the rest are virtual
My only question here is: What is leftmos
On Thu, 9 Jan 2003 16:40:20 -0500, Dan Sugalski wrote:
> #10 We do MI, but we don't instantiate a class' attributes multiple
> times if its in the hierarchy for a class more than once. If it is, the
> leftmost instance is real, the rest are virtual
This will mean we can't support Eiffel, which
Okay, as promised, here's the object proposal for parrot. (And yes,
it was finished by 5PM EST--if you got it later, it just means I
lingered over coffee in a blissfully wireless-free coffee shop down
the street from my apartment)
Objects, as far as I see it, have the following properties:
1) The
79 matches
Mail list logo
