Leopold Toetsch (via RT) wrote:
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #20315]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=20315 >
Attached is a first try towards eval.
I have now
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
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
Jerome Quelin (via RT) wrote:
- currently I'm just printing on stdout the resulting parrot code, I
lack an eval instruction in Parrot. Dan, Leo? :-)
$ diff -ub ~/src/parrot/languages/ook/ook.pasm ook.pasm
--- /home/lt/src/parrot/languages/ook/ook.pasm Wed Jan 1 01:34:16 2003
+++ ook.pasm
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).
> > >
> > >
>> > >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
Leopold Toetsch wrote:
> 1)
> The call function to the compiler/assembler is kept as a NCI. Better
> would be a subclass of NCI (Compiler.pmc or so), which provides
> invoke_keyed(key, next)
Hmm, I don't know what a NCI is. Where (which files) can I find
information about them?
Jerome
--
[EMAI
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
Leopold Toetsch wrote:
> Jerome Quelin (via RT) wrote:
> > - currently I'm just printing on stdout the resulting parrot code,
> > I lack an eval instruction in Parrot. Dan, Leo? :-)
> $ diff -ub ~/src/parrot/languages/ook/ook.pasm ook.pasm
> --- /home/lt/src/parrot/languages/ook/ook.pasm Wed Jan
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
> 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'
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
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
At 8:27 PM + 1/14/03, Leopold Toetsch (via RT) wrote:
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #20315]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=20315 >
Attached is a first try towa
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
In perl.perl6.internals, you wrote:
> Leopold Toetsch wrote:
>> 1)
>> The call function to the compiler/assembler is kept as a NCI. Better
>> would be a subclass of NCI (Compiler.pmc or so), which provides
>> invoke_keyed(key, next)
> Hmm, I don't know what a NCI is. Where (which files) can I find
In perl.perl6.internals, you wrote:
> Leopold Toetsch wrote:
>> $ ../imcc/imcc -r ook.pasm hello.ook
>> Hello World!
> You don't seem to have checked in the compile thing...
No, its not ready yet.
> About the eval: you said that compile does eval here. In the future, how
> should I eval after co
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
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
Dan Sugalski wrote:
At 8:27 PM + 1/14/03, Leopold Toetsch (via RT) wrote:
Yow, Cool! We *have* to get IMCC built into parrot now.
You do get this wrong - always ;-)
imcc = parrot + assemble.pl - pre-processor + PIR-assembler +
optimizer/10#yet & now & already
With the help
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 likely stored in a hash.
--
Jonathan Sillito
>
> "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
[EMAIL PROTECTED] (Michael Lazzaro) writes:
> Great -- then I have only one more question, I think. In the words of
> a certain cartoon character, what's *this* button do?
>
>my $b is $a;
I think at this stage it's probably worth reminding everyone that not
every string of characters *needs*
[EMAIL PROTECTED] (Mr. Nobody) writes:
> Unicode operators in the core are a very, very, very, very, very, very, very,
> very, very, very, very, very, very bad idea.
We've done that.
--
COBOL is for morons.
-- E.W. Dijkstra
[EMAIL PROTECTED] (Dan Sugalski) writes:
> Ah, that's a different question. Having Unicode synonyms may well be
> considered reasonable thing
Sounds like the good old days of trigraphs.
--
A witty saying means nothing. -Voltaire
At 12:05 AM + 1/16/03, Simon Cozens wrote:
[EMAIL PROTECTED] (Dan Sugalski) writes:
Ah, that's a different question. Having Unicode synonyms may well be
considered reasonable thing
Sounds like the good old days of trigraphs.
I was shooting for the good old days of sarcasm that people no
26 matches
Mail list logo
