At 05:41 PM 4/30/2001 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: At 03:08 PM 4/25/2001 -0300, Branden wrote:
>:
>: >At 01:52 PM 25/04/2001 -0400, Dan Sugalski wrote:
>: >>Seriously, I don't see why this should be a scary thing. So, the opcode
>: >>table's extendable. So what? It'll make lan
At 11:05 PM 4/30/2001 +0200, Kai Henningsen wrote:
>[EMAIL PROTECTED] (Dan Sugalski) wrote on 25.04.01 in
><[EMAIL PROTECTED]>:
>
> > If you have the double-indirect, the window of vulnerability is smaller,
> > but it's still there if you're running multithreaded.
>
>Looks zero-sized to me. One
[EMAIL PROTECTED] (Dan Sugalski) wrote on 25.04.01 in
<[EMAIL PROTECTED]>:
> If you have the double-indirect, the window of vulnerability is smaller,
> but it's still there if you're running multithreaded.
Looks zero-sized to me. One memory write, let the garbage collector
collect the old vt
Dan Sugalski writes:
: At 03:08 PM 4/25/2001 -0300, Branden wrote:
:
: >At 01:52 PM 25/04/2001 -0400, Dan Sugalski wrote:
: >>Seriously, I don't see why this should be a scary thing. So, the opcode
: >>table's extendable. So what? It'll make language X mode simpler, for some
: >>value of X, if
At 03:08 PM 4/25/2001 -0300, Branden wrote:
>At 01:52 PM 25/04/2001 -0400, Dan Sugalski wrote:
>>Seriously, I don't see why this should be a scary thing. So, the opcode
>>table's extendable. So what? It'll make language X mode simpler, for some
>>value of X, if that language can load in its own
At 11:01 AM 4/25/2001 -0300, Branden wrote:
>At 09:39 AM 25/04/2001 -0400, Dan Sugalski wrote:
>>At 06:46 PM 4/24/2001 -0700, Larry Wall wrote:
>>>I think we definitely have to be able to resize vtables at compile time,
>>>which is a form of run time. It's vaguely possible we could restrict
>>>mu
At 02:01 PM 4/25/2001 -0300, Branden wrote:
>At 11:34 AM 25/04/2001 -0400, Dan Sugalski wrote:
>>At 11:01 AM 4/25/2001 -0300, Branden wrote:
>>>2) Anyway, even resizing vtables we would need some more indirection to
>>>determine in which position of the vtable is which operator.
>>
>>No. Each ope
At 01:52 PM 25/04/2001 -0400, Dan Sugalski wrote:
>Seriously, I don't see why this should be a scary thing. So, the opcode
>table's extendable. So what? It'll make language X mode simpler, for some
>value of X, if that language can load in its own set of extended opcodes.
>Perhaps someone'll w
At 11:34 AM 25/04/2001 -0400, Dan Sugalski wrote:
>At 11:01 AM 4/25/2001 -0300, Branden wrote:
>>2) Anyway, even resizing vtables we would need some more indirection to
>>determine in which position of the vtable is which operator.
>
>No. Each operator goes in a fixed position in the vtable, and
At 04:12 PM 25/04/2001 +0200, Bart Lateur wrote:
>On Wed, 25 Apr 2001 11:01:07 -0300, Branden wrote:
> >If the idea is supporting arbitrary add-on operators...
>
>I think I second that. I would think of a fixed table for the built-in
>ones, and a linked list for the add-ons. It's not necessary tha
At 09:39 AM 25/04/2001 -0400, Dan Sugalski wrote:
>At 06:46 PM 4/24/2001 -0700, Larry Wall wrote:
>>I think we definitely have to be able to resize vtables at compile time,
>>which is a form of run time. It's vaguely possible we could restrict
>>multithreading during compile phase.
>
>We need to
On Wed, 25 Apr 2001 11:01:07 -0300, Branden wrote:
>If the idea is supporting arbitrary add-on operators, which I believe will
>be done seldom, for only some specific classes, wouldn't it be better to
>have a ``catch all'' entry for operators different than the built-in ones?
>
>Of course, add-
At 06:46 PM 4/24/2001 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: Resizing the vtable at runtime is a really dodgy thing. There are some
>: rather huge threading implications here--changing their size (as opposed to
>: using up a limited number of "uncommitted" spots we leave at the end) mea
On Tue, Apr 24, 2001 at 01:18:49PM +0100, Nick Ing-Simmons wrote:
> What _really_ want to do is a dynamically scoped peep-hole "optimize"
> (actually a rewrite) of the op tree - written in perl.
>
> But I can't do that
Yes, you can. Check out B::Generate.
--
Britain has football hooligans, Ger
Nick Ing-Simmons writes:
: Larry Wall <[EMAIL PROTECTED]> writes:
: >I think using overloading to write a parser is going to be a relic of
: >Perl 5's limitations, not Perl 6's.
:
: I am _NOT_ using overloading to write a parser.
: Parse::Yapp is just fine for writing parsers. I am trying to re-
Dan Sugalski writes:
: Resizing the vtable at runtime is a really dodgy thing. There are some
: rather huge threading implications here--changing their size (as opposed to
: using up a limited number of "uncommitted" spots we leave at the end) means
: potentially having to move all the vtables
Larry Wall <[EMAIL PROTECTED]> writes:
>Nick Ing-Simmons writes:
>: >You really have to talk about overloading boolean context
>: >in general.
>:
>: Only if you are going to execute the result in the normal perl realm.
>: Consider using the perl parser to build a parse tree - e.g. one to
>: read
At 07:11 PM 4/20/2001 -0500, Jarkko Hietaniemi wrote:
>On Fri, Apr 20, 2001 at 05:02:21PM -0700, Larry Wall wrote:
> > Jarkko Hietaniemi writes:
> > : What is someone wants to define matrices and have both cross product
> > : and dot product?
> >
> > At some point, there aren't enough operators, a
add vtable function of the
left-hand PMC. That's it. What goes in that vtable and how it gets there
(overloading, tying, type methods, Arcturan mind control rays...) is
irrelevant, really. Talking about tying, overloading, or whatever doesn't
really matter--the only difference ther
Nick Ing-Simmons writes:
: >You really have to talk about overloading boolean context
: >in general.
:
: Only if you are going to execute the result in the normal perl realm.
: Consider using the perl parser to build a parse tree - e.g. one to
: read perl5 and write perl 6. This works for all ex
At 05:21 PM 20/04/2001 -0400, Dan Sugalski wrote:
>At 06:08 PM 4/20/2001 -0300, Filipe Brandenburger wrote:
>>I'd rather be flexible on the low-level and have `default' or `catch-all'
>>functions that call the cmp-style function than have to `trick' the
>>language by modifying the parser to do w
At 05:58 PM 20/04/2001 -0400, Dan Sugalski wrote:
>At 06:49 PM 4/20/2001 -0300, Filipe Brandenburger wrote:
>>What would happen when $a = $b? Semantically, according to the tying and
>>overloadings, the bignumber on $b should be written to the file $a is
>>tied to, and when fetching the value of
At 05:32 PM 20/04/2001 -0400, Dan Sugalski wrote:
>At 06:20 PM 4/20/2001 -0300, Filipe Brandenburger wrote:
>>Please tell me if there really is an use for overloading && and || that
>>would not be better done with source filtering, then I will (maybe)
>>reconsider my opinion.
>
>@foo = @bar &&
Larry Wall <[EMAIL PROTECTED]> writes:
>: At 06:20 PM 4/20/2001 -0300, Filipe Brandenburger wrote:
>: >Please tell me if there really is an use for overloading && and || that
>: >would not be better done with source filtering, then I will (maybe)
>: >reconsider my opinion.
>
>I think it's a cate
Filipe Brandenburger <[EMAIL PROTECTED]> writes:
>
>The big problem with || and && is that they don't evaluate their second
>argument until it's needed, that's what allows us to do something like
>`$xxx || die'.
That is still a run-time thing though - so no real barrier to overloading it.
>I
On Fri, Apr 20, 2001 at 05:02:21PM -0700, Larry Wall wrote:
> Jarkko Hietaniemi writes:
> : What is someone wants to define matrices and have both cross product
> : and dot product?
>
> At some point, there aren't enough operators, and new ones have to
I thought we adopted Unicode for this very
Jarkko Hietaniemi writes:
: What is someone wants to define matrices and have both cross product
: and dot product?
At some point, there aren't enough operators, and new ones have to
be named somehow, or old ones usurped. In any event, new ops either
have to be declared with a lexical scope, or
: At 06:20 PM 4/20/2001 -0300, Filipe Brandenburger wrote:
: >Please tell me if there really is an use for overloading && and || that
: >would not be better done with source filtering, then I will (maybe)
: >reconsider my opinion.
I think it's a category error to talk about overloading && and |
At 06:49 PM 4/20/2001 -0300, Filipe Brandenburger wrote:
>What would happen when $a = $b? Semantically, according to the tying and
>overloadings, the bignumber on $b should be written to the file $a is tied
>to, and when fetching the value of $a, it should return a bignumber, with
>all the over
tml
Is it as powerful as Perl's tying/overloading model (when it works)?
I swear to look at it next week.
>If the http://dev.perl.org/rfc/9.pod rfc goes through, then
>the meaning of $ @ % are going to be changing a lot. It'd be
>nice if Perl6 classes could easily map met
At 06:20 PM 4/20/2001 -0300, Filipe Brandenburger wrote:
>Please tell me if there really is an use for overloading && and || that
>would not be better done with source filtering, then I will (maybe)
>reconsider my opinion.
@foo = @bar && @baz;
Dan
At 03:31 PM 4/20/2001 -0500, Garrett Goebel wrote:
> > > The equivalent of an AV should store an array of values rather
> > > than variables.
> >
> > I disagree.
> >
> > $a = 1;
> > @b = ($a);
> > $c = $b[0];
>
>oops I meant:
>
>Wouldn't you like to preserve the possibility of allowing $c
>get bot
At 06:08 PM 4/20/2001 -0300, Filipe Brandenburger wrote:
>At 03:27 PM 20/04/2001 -0400, Dan Sugalski wrote:
>>At 02:13 PM 4/20/2001 -0500, Jarkko Hietaniemi wrote:
>>> > o Comparison operations
>>> > "<", "<=", ">", ">=", "==", "!=", "<=>",
>>> > "lt", "le", "gt", "ge", "e
At 12:00 PM 20/04/2001 -0700, Nathan Wiger wrote:
>It looks like Branden took the vtable names from RFC 159, which is a
>modification of 'use overload' ops to object member functions.
Yes, that was one of my biggest inspirations.
>During
>our discussions of this on -objects, I remember Damian e
At 03:27 PM 20/04/2001 -0400, Dan Sugalski wrote:
>At 02:13 PM 4/20/2001 -0500, Jarkko Hietaniemi wrote:
>> > o Comparison operations
>> > "<", "<=", ">", ">=", "==", "!=", "<=>",
>> > "lt", "le", "gt", "ge", "eq", "ne", "cmp",
>
>I'm thinking that we're going to have one
At 12:31 PM 20/04/2001 -0500, Jarkko Hietaniemi wrote:
>In general the extensibility (and the size) of the vtable worries me.
>Should we have multilevel vtables? Arithmetic subvtable, bitop
>subvtable, et cetera?
Actually, I don't think that's necessary.
First of all, changing one subvtable i
> > The equivalent of an AV should store an array of values rather
> > than variables.
>
> I disagree.
>
> $a = 1;
> @b = ($a);
> $c = $b[0];
oops I meant:
Wouldn't you like to preserve the possibility of allowing $c
get both the variable and value vtables of $a?
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>
[...]
> Well, I think that's all I have to say on the subject. Now
> I'd like to hear from you. Do this all make sense? Is it
> useful? Is it worth for Perl 6? Is it too clumsy? Are there
> things I didn't mention here?
I hope our more enligh
On Fri, Apr 20, 2001 at 04:12:17PM -0400, Dan Sugalski wrote:
> At 02:34 PM 4/20/2001 -0500, Jarkko Hietaniemi wrote:
> > > >One additional datapoint to overload your brain with is to consider
> > > >the ambiguity of equality and comparison. Unicode normalization:
> > > >is A + grave equal to Agr
At 02:34 PM 4/20/2001 -0500, Jarkko Hietaniemi wrote:
> > >One additional datapoint to overload your brain with is to consider
> > >the ambiguity of equality and comparison. Unicode normalization:
> > >is A + grave equal to Agrave? Is Agrave less than Aacute? Unicode
> > >collation combined with
> I'm thinking that we're going to have one cmp-style vtable comparison
> function for strings and one for numbers. Anything else and people can go
> override the parser if they really need to.
Good. We don't need to burden the low-level interface with twelve
vtable methods when two will do fo
At 02:13 PM 4/20/2001 -0500, Jarkko Hietaniemi wrote:
> > I'm not sure the exact Perl 5 internal rep., but right now 'use
> > overload' already allows individual overloading of all the numeric and
> > string equality functions individually:
> >
> > o Comparison operations
> > "<", "<
> I'm not sure the exact Perl 5 internal rep., but right now 'use
> overload' already allows individual overloading of all the numeric and
> string equality functions individually:
>
> o Comparison operations
> "<", "<=", ">", ">=", "==", "!=", "<=>",
> "lt", "le", "gt", "
Jarkko Hietaniemi wrote:
>
> > // numeric comparisons
> > int (*NUMCMP) (SVAL *this, SVAL *value);
> > int (*NUMEQ) (SVAL *this, SVAL *value);
> > int (*NUMNE) (SVAL *this, SVAL *value);
> > int (*NUMLT) (SVAL *this, SVAL *value);
> >
On Fri, Apr 20, 2001 at 09:58:13AM -0700, [EMAIL PROTECTED] wrote:
>
>
> Hello,
>
> First of all, I'm sorry, this text is rather too long.
Wow. So it is. But based on high-speed glancing it looks rather good.
I found one spot that I want to comment right away.
[kilosnip]
> 1.2. The vtable
Hello,
First of all, I'm sorry, this text is rather too long.
I worked a bit too long on this, mainly because I wanted to give a big
picture of it, without omitting important details. The big picture,
because I wanted to show why would we bother having different ways of
handling for tying and
46 matches
Mail list logo
