On Wed, Jan 23, 2002 at 09:57:49PM +0100, Juergen Boemmels wrote:
Ok, here is the updated schemepair-patch.
Thanks for this, but I'm afraid I'm not going to apply it. The reason
being:
To implement nested pairs its nessary to introduce 2 new vtable functions
and the acompaning core.ops to
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Larry == Larry Wall [EMAIL PROTECTED] writes:
Larry I think our terminology is getting sloppy here. What
Larry do you mean by inherit from that method? If the
Larry derived method overrides the base method, it will
Larry manage its
At 6:04 PM +0100 1/22/02, Juergen Boemmels wrote:
Hello,
some time ago (before I went to holidays) I posted a patch
implementing Schemepairs, but I didn't get any comments about this. I
am wondering what is the reason for this.
Was the patch too long, or too outdated (I can resend a newer
At 9:25 AM + 1/23/02, Alberto Manuel Brandao Simoes wrote:
Hellows
Can anybody give me a simple but complete explanation of the
PMC register
type? Thanks
Sure--a PMC register is, in C terms:
struct PMC *;
And the register set is just an array of PMC pointers. If that's
From interpreter.h:
INTVAL flags;/* Various
interpreter flagBut whBut what
that signal that runops
should do something */
I'd supply a patch, but I'm not
These are the items that iam interested in selling..
Could you help me with some details on the goods, history, origin etc.
are these worth anything and if so who would i contact with regards to
selling them? and the best way to sell them ie auction etc
APOLOGISE IF YOU HAVE ALREADY RECEIVED
Dan Sugalski [EMAIL PROTECTED] wrote:
That was my biggest objection. I like the thought of having a scheme
pair data type. The interpreter should see it, and it should be
accessed, as a restricted array, one with only two entries.
Is this then the same datatype as a Perl6 pair (cf '=' op in
At 4:19 PM + 1/24/02, Dave Mitchell wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
That was my biggest objection. I like the thought of having a scheme
pair data type. The interpreter should see it, and it should be
accessed, as a restricted array, one with only two entries.
Is this then
DS == Dan Sugalski [EMAIL PROTECTED] writes:
DS At 4:19 PM + 1/24/02, Dave Mitchell wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
That was my biggest objection. I like the thought of having a scheme
pair data type. The interpreter should see it, and it should be
accessed, as a
At 11:32 AM 01-24-2002 -0500, Dan Sugalski wrote:
At 4:19 PM + 1/24/02, Dave Mitchell wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
That was my biggest objection. I like the thought of having a scheme
pair data type. The interpreter should see it, and it should be
accessed, as a
From: Glenn Linderman [mailto:[EMAIL PROTECTED]]
Graham Barr wrote:
But the base class may be just an interface class. And thus
by inheriting the pre conditions you are enforcing the API.
So I can see a use for it, but I can also see where you
don't want it too.
So if the base
From: Garrett Goebel [mailto:[EMAIL PROTECTED]]
From: Glenn Linderman [mailto:[EMAIL PROTECTED]]
So maybe your point was that when you replace a method from a
base class that you only have 1 subroutine for that method,
the replacement one, because there wasn't really one there
in the
On Thu, 2002-01-24 at 08:48, Garrett Goebel asked:
So which Apoc will be the OO one?
Apoc 12, to go by the chapters of the 3rd Camel.
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
On Wed, Jan 23, 2002 at 08:30:41AM -0800, Larry Wall wrote:
: INIT, DESTROY, AUTOLOAD, etc., all make sense to me. They really are
: special blocks that normally only occur once in a file. But CATCH and
: NEXT are part of normal syntax. I don't think they're any more unusual
: in their
On Wed, Jan 23, 2002 at 06:00:21PM -0500, Melvin Smith wrote:
final and private are completely different concepts as I understand
them.
I wouldn't say completely different. They are both used for enforcement
of similar means, but you are correct, they are different.
I view final as being
Damian Conway [mailto:[EMAIL PROTECTED]] wrote:
You *could* instead consider reversing the arguments to
all the list
manipulation operators:
@result = map @data { mapping() }
@result = grep @data { selector() };
@result = sort @data { comparison() };
@result =
[Note: I've resent this - since apparently it never made it
to the list. Can someone please complain offlist if they
did get the previous one?]
Damian Conway [mailto:[EMAIL PROTECTED]] wrote:
You *could* instead consider reversing the arguments to
all the list
manipulation operators:
On Wed, 23 Jan 2002 08:30:41 -0800 (PST), Larry Wall wrote:
Andy Wardley writes:
: Same with 'last/NEXT' - they're so similar
: in concept that the implementation details should not matter.
You mean last/LAST and next/NEXT, I suspect. But there's another
argument for case differentiation.
Simon Cozens [EMAIL PROTECTED] writes:
To implement nested pairs its nessary to introduce 2 new vtable functions
and the acompaning core.ops to get and set the PMC value of the indexed
element. I choosed set_p_p_i and set_p_i_p. The later one is inconsistent
with indexed set operations
On Thu, Jan 24, 2002 at 06:11:46PM +0100, Juergen Boemmels wrote:
code destination, dest_key, source1, source1_key, source2, source2_key
The key parameters are optional, and may be either an integer or a
string. [...] Any time a source or destination can be a PMC register,
Dave Mitchell [EMAIL PROTECTED] writes:
Dan Sugalski [EMAIL PROTECTED] wrote:
That was my biggest objection. I like the thought of having a scheme
pair data type. The interpreter should see it, and it should be
accessed, as a restricted array, one with only two entries.
Is this then
At 06:11 PM 1/24/2002 +0100, Juergen Boemmels wrote:
I've no idea which is the best way to go. The Pair-Implementation just
needs one way to get a PMC-value of an (constant) index.
I will delay my patch until this issue is solved
Maybe you could bang on this issue and work out a good solution
At 05:23 PM 1/24/2002 +, Simon Cozens wrote:
* Introduce a new register-type for Keys.
No, I don't think this is the right way.
Just a question, what is the status of the Scheme parser. Is it even
ready to generate code for working with these constructs? Maybe work top
down on this one?
=?iso-8859-1?q?Jonathan=20E.=20Paton?= writes:
:
: Damian Conway [mailto:[EMAIL PROTECTED]] wrote:
:
: You *could* instead consider reversing the arguments to
: all the list
: manipulation operators:
:
: @result = map @data { mapping() }
: @result = grep @data { selector() };
:
Garrett Goebel writes:
: And this is just looking at it in the simple case. When multiple-dispatch
: comes into the picture, then we'll have different invokations of the same
: method being dispatched to different implementations depending on the
: parameter list. I wonder how PRE/POST will work
Damien Neil writes:
: On Wed, Jan 23, 2002 at 06:00:21PM -0500, Melvin Smith wrote:
: final and private are completely different concepts as I understand
: them.
:
: I wouldn't say completely different. They are both used for enforcement
: of similar means, but you are correct, they are
Peter Haworth writes:
: On Wed, 23 Jan 2002 08:30:41 -0800 (PST), Larry Wall wrote:
: Andy Wardley writes:
: : Same with 'last/NEXT' - they're so similar
: : in concept that the implementation details should not matter.
:
: You mean last/LAST and next/NEXT, I suspect. But there's another
:
On Thu, Jan 24, 2002 at 10:48:45AM -0600, Garrett Goebel wrote:
When multiple-dispatch comes into the picture, then we'll have
different invokations of the same method being dispatched to different
implementations depending on the parameter list. I wonder how PRE/POST
will work once that can
From: Larry Wall [mailto:[EMAIL PROTECTED]]
Garrett Goebel writes:
: And this is just looking at it in the simple case. When
: multiple-dispatch comes into the picture, then we'll
: have different invokations of the same method being
: dispatched to different implementations depending on
At the moment, the assembler doesn't seem to like single character
labels. For instance, this code:
bsr aa
print Didn't branch \n
end
aa: print Branched \n
end
prints Branched, as one would expect, but this code:
bsr a
print Didn't branch
The following line in interpreter.c
interpreter-perl_stash = pmc_new(interpreter, enum_class_PerlHash);
is now causing Solaris 8/Sun Workshop cc to throw the following error:
(reformatted for clarity)
interpreter.c, line 534: warning: assignment type mismatch:
pointer to struct
Uri Guttman [EMAIL PROTECTED] writes:
Is this then the same datatype as a Perl6 pair (cf '=' op in Apo 3) ??
DS Good point. it probably is, yes. (Though there may be potential
DS differences--depends on whether the scheme pair can only have scalars
DS on each side, or should
Melvin Smith [EMAIL PROTECTED] writes:
At 05:23 PM 1/24/2002 +, Simon Cozens wrote:
* Introduce a new register-type for Keys.
No, I don't think this is the right way.
Just a question, what is the status of the Scheme parser. Is it
even ready to generate code for working with
I've been watching the Parrot development with interest and have a few
questions about Parrots capabilities.
Will Parrot support templates (also known as generics)?
Will Parrot support operator overloading?
Do Parrot classes have constructors and destructors?
Does Parrot have garbage
Garrett Goebel writes:
: --_=_NextPart_001_01C1A506.D9BE78D0
: Content-Type: text/plain;
: charset=iso-8859-1
:
: From: Larry Wall [mailto:[EMAIL PROTECTED]]
:
: Garrett Goebel writes:
: : And this is just looking at it in the simple case. When
: : multiple-dispatch comes into
[EMAIL PROTECTED]:
# I've been watching the Parrot development with interest and have a few
# questions about Parrots capabilities.
#
#Will Parrot support templates (also known as generics)?
If you mean like C++ templates, then the answer is that it's up to the
language. There won't be
Simon Cozens [EMAIL PROTECTED] writes:
According to this document the set_p_n_i notation would be wrong. But
I already heard that the index-system is a moving target.
In this case, I'd prefer you trusted the documentation. :)
Which one parrot_assembly.pod or core_ops.pod? They are both
Thanks Brent.
# #Does Parrot have garbage collection?
# Not yet, but it will.
When it does, I'd ask that there be some sort of option on what type of
garbage collection is used. This is because different methods of garbage
collection have very different characteristics.
For example,
[Brent's answered some of these already, but I'll fill in the blanks.
Also some of the answers presume a fully-implemented engine, which we
don't have yet]
At 2:52 PM -0500 1/24/02, [EMAIL PROTECTED] wrote:
I've been watching the Parrot development with interest and have a few
questions about
At 10:08 PM +0100 1/24/02, Juergen Boemmels wrote:
Simon Cozens [EMAIL PROTECTED] writes:
According to this document the set_p_n_i notation would be wrong. But
I already heard that the index-system is a moving target.
In this case, I'd prefer you trusted the documentation. :)
Which one
At 1:49 PM -0500 1/24/02, Andy Dougherty wrote:
The following line in interpreter.c
interpreter-perl_stash = pmc_new(interpreter, enum_class_PerlHash);
is now causing Solaris 8/Sun Workshop cc to throw the following error:
(reformatted for clarity)
D'oh! Thinko. I'll fix.
--
At 8:12 PM +0100 1/24/02, Juergen Boemmels wrote:
Uri Guttman [EMAIL PROTECTED] writes:
Is this then the same datatype as a Perl6 pair (cf '=' op in Apo 3) ??
DS Good point. it probably is, yes. (Though there may be potential
DS differences--depends on whether the scheme pair can
On Thursday 24 January 2002 14:52, [EMAIL PROTECTED] wrote:
I've been watching the Parrot development with interest and have a few
questions about Parrots capabilities.
Brent and Dan have already answered, so I'm going to be so foolish as to
answer, too.
Will Parrot support operator
Who is the keeper of the FAQ? This is gold.
--Josh
--- Forwarded Messages
Date:Thu, 24 Jan 2002 12:35:05 -0800
From:Brent Dax [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: RE: How Powerful Is Parrot?
[EMAIL PROTECTED]:
# I've been watching the Parrot
Larry wrote:
: I strongly suspect that DbC and multimethods are, at best,.
: orthogonal My gut level feeling is that multimethod calls look
: like ordinary subroutine calls, and the method eventually
: selected evaluates only its own PRE/POST conditions, which could
: perhaps explicitly
45 matches
Mail list logo
