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
At 03:22 PM 20/04/2001 -0500, Garrett Goebel wrote:
>I hope our more enlightened subscribers can separate the
>chaff from the wheat. It provoked me to a lot of thought, if
>not enlightenment. Good ideas are in there, I hope they
>aren't ignored in favorite pastime of pointing out mistakes.
Than
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
21 matches
Mail list logo
