David Mitchell wrote:
> Well, I was assuming that there would be *a* numeric class in scope
> - as defined be the innermost lexical 'use foo'.
And that numeric class would remove int and num from the scope?
> I assumed that Perl wouldn't be clever enough to know about all available
> numberic ty
At 02:34 PM 10/24/00 +0100, David Mitchell wrote:
>Ken Fox <[EMAIL PROTECTED]> wrote:
> > David Mitchell wrote:
> > > Now of course if we have the luxury of deciding that core perl 'knows'
> > > about complex numbers, then of the parser can be made to recognise ...
> >
> > The core doesn't need t
Ken Fox <[EMAIL PROTECTED]> wrote:
> David Mitchell wrote:
> > Now of course if we have the luxury of deciding that core perl 'knows'
> > about complex numbers, then of the parser can be made to recognise ...
>
> The core doesn't need to know -- that was my point. All the core needs
> is the bas
On Mon, 2 Oct 2000, Jarkko Hietaniemi wrote:
> > Assuming that the perl parser generated IV SVs rather than NVs for
> > the 2 constants 2,3, then my scheme would handle this fine; the IV
>
> It currently does so.
>
> > version of add() would be called, and an IV SB would result.
>
> "The IV ve
> One C++ problem I just found out is memory management. It seems
> that it's impossible to 'new' an object from an specified memory block.
> So it's impossible to put free'd objects in memory pool and re-allocate
> them next time.
It can't be done by the default new operator, but you can do it
Dan Sugalski wrote:
> At 03:23 PM 9/29/00 -0400, ye, wei wrote:
> >Dan Sugalski wrote:
> >
> > > At 02:29 PM 9/29/00 +0100, David Mitchell wrote:
> > > >Regarding the tentative list of vtable functions:
> > > >I'm rather worried about binary operators, eg 'is_equal', 'add' etc.
> > > >The danger
> > would need to know a fair bit about particular user-defined types that have
> > been loaded in, on order to make clever interpretations of literals.
>
> Precisely. Assume I want
>
> $a = 2 + 3i;
>
> to work...
Which I what I suggest we abandon attempts to make the parser do intellig
> would need to know a fair bit about particular user-defined types that have
> been loaded in, on order to make clever interpretations of literals.
Precisely. Assume I want
$a = 2 + 3i;
to work...
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we
> >the $c will be an NV of of 5.000, or thereabouts, een
> >while $a and $b are IVs.
>
> Note: integers have an exact representation in floating point. There is
...as long as they are [minint, maxint].
> no "thereabouts". It is exactly 5.000.
Yeah, bad example. Yours i
> > version of add() would be called, and an IV SB would result.
>
> "The IV version of add()"? Beware of combinatorial explosion:
> addII, addIU, addUI, addUU, addIN, addNI, addNN, addblahbah
Ah, but you've forgotten the point of my orginal posting (back in
prehistory ;-)
where given 2 mi
> For the record: I hate the current policy of defaulting to NVs for
> arithmetic ops. If I say '2' I do mean an IV of 2, not an NV of
> 2.000. Currently if I say
>
> $a = 2;
> $b = 3;
> $c = $a + $3;
>
> the $c will be an NV of of 5.000, or thereabouts, een
> whi
> $x = 2^1000;
>
> would evaluate 2^1000 at compile time, and if it didnt fit into an NV
> (or IV if 'use integer' is in effect), create a compile-time error.
For the record: I hate the current policy of defaulting to NVs for
arithmetic ops. If I say '2' I do mean an IV of 2, not an NV of
2.000
> > > Don't forget bigrats.
> >
> > I'm not too familiar with the concept of rational numbers in a computing
> > complex. What's your definition of a (big)rat? Fixed point??
>
> bigint1 / bigint2. Possibly represented as a triad of bigints,
> bigint1 + bigint2 / bigint3.
I'm tempted to suggest
At 02:29 PM 9/29/00 +0100, David Mitchell wrote:
>Regarding the tentative list of vtable functions:
>I'm rather worried about binary operators, eg 'is_equal', 'add' etc.
>The danger with these is that they may impose a single implementation
>of scalars upon us.
>
>As an example, suppose I wrote an
Regarding the tentative list of vtable functions:
I'm rather worried about binary operators, eg 'is_equal', 'add' etc.
The danger with these is that they may impose a single implementation
of scalars upon us.
As an example, suppose I wrote an alternative scalar implementation that
was optimised f
Nathan Torkington <[EMAIL PROTECTED]> writes:
>Dan Sugalski writes:
>> It's possible, for example, for a tied/overloaded/really-darned-strange
>> variable to look true but still be false. If you do:
>>
>>$foo = $bar || $baz;
>>
>> and both $bar and $baz are objects, the 'naive' way is to ma
At 03:56 PM 9/13/00 -0400, Ken Fox wrote:
>Nick Ing-Simmons wrote:
> > Ken Fox <[EMAIL PROTECTED]> writes:
> > >Dan Sugalski wrote:
> > >> For something like:
> > >>
> > >>@foo = @bar || @baz;
> > >>
> > >> I have no problem with the call sequence looking like (pseudo-codish
> here):
> > >>
>
Dan Sugalski writes:
> It's possible, for example, for a tied/overloaded/really-darned-strange
> variable to look true but still be false. If you do:
>
>$foo = $bar || $baz;
>
> and both $bar and $baz are objects, the 'naive' way is to make $foo be
> $bar. But it's distinctly possible that
At 03:02 PM 9/12/00 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > For something like:
> >
> >@foo = @bar || @baz;
> >
> > I have no problem with the call sequence looking like (pseudo-codish here):
> >
> > set_context(ARRAY, ASSIGN);
> > foo->store(bar->log_or(bar, baz));
>
>But log_o
Nick Ing-Simmons wrote:
> Ken Fox <[EMAIL PROTECTED]> writes:
> >Dan Sugalski wrote:
> >> For something like:
> >>
> >>@foo = @bar || @baz;
> >>
> >> I have no problem with the call sequence looking like (pseudo-codish here):
> >>
> >> set_context(ARRAY, ASSIGN);
> >> foo->store(bar->l
Ken Fox <[EMAIL PROTECTED]> writes:
>Dan Sugalski wrote:
>> For something like:
>>
>>@foo = @bar || @baz;
>>
>> I have no problem with the call sequence looking like (pseudo-codish here):
>>
>> set_context(ARRAY, ASSIGN);
>> foo->store(bar->log_or(bar, baz));
>
>But log_or must shor
Dan Sugalski wrote:
> For something like:
>
>@foo = @bar || @baz;
>
> I have no problem with the call sequence looking like (pseudo-codish here):
>
> set_context(ARRAY, ASSIGN);
> foo->store(bar->log_or(bar, baz));
But log_or must short circuit -- I think we have to preserve that b
At 07:58 PM 9/9/00 +, Nick Ing-Simmons wrote:
>Ken Fox <[EMAIL PROTECTED]> writes:
> >Short
> >circuiting should not be customizable by each type for example.
>
>We are already having that argument^Wdiscussion elsewhere ;-)
>
>But I agree variable vtables are not the place for that.
As do I,
Ken Fox <[EMAIL PROTECTED]> writes:
>Short
>circuiting should not be customizable by each type for example.
We are already having that argument^Wdiscussion elsewhere ;-)
But I agree variable vtables are not the place for that.
--
Nick Ing-Simmons
Dan Sugalski wrote:
> At 05:30 PM 8/31/00 -0400, Ken Fox wrote:
> > before_get_value
> > after_get_value
> > before_set_value
> > after_set_value
> >
> >There ought to be specializations of get_value and set_value
> >that call these hooks if they're defined -- no sense in making the
> >nor
Bryan C. Warnock wrote:
> I use direct, raw access in prototyping when dipping back into C for
> "heavy" data manipulations - bit stream analysis, signals processing, etc.
> Since I'm usually doing a lot of buffer manipulations, I don't want all
> the scalar overhead that comes into play.
> > >M
On Fri, 01 Sep 2000, Dan Sugalski wrote:
> I'm not sure. They're there mainly for guaranteed unfiltered access to the
> variable's guts, and I'm not sure what things will need that.
I use direct, raw access in prototyping when dipping back into C for
"heavy" data manipulations - bit stream analy
At 11:49 AM 9/1/00 -0500, David L. Nicol wrote:
>Dan Sugalski wrote:
>
> > We're shooting for speed here. Any common operation that could be affected
> > by the type of the variable should be represented so a custom function can
> > be called that does exactly what needs to be done.
> >
> >
At 10:23 AM 9/1/00 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: Type returns a magic cookie value of some sort (Not sure what sort yet),
>: name returns a string with the name of the type of the variable.
>
>Why can't the type object just stringify to the name of the type?
I'd figured that t
At 10:25 AM 9/1/00 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: Anyone got anything to add before I throw together the base vtable RFC?
>
>So how do you call a generic method?
Generic vtable method? You'd have to look up the vtable in the stash that
held it and vector in through there.
If
At 06:07 PM 9/1/00 +, Nick Ing-Simmons wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> >is_equal (true if this thing is equal to the parameter thing)
> >is_same (True if this thing is the same thing as the parameter thing)
>
>is_equal in what sense? (String, Number, ...)
I was thin
> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
NI> Dan Sugalski <[EMAIL PROTECTED]> writes:
>> is_equal (true if this thing is equal to the parameter thing)
>> is_same (True if this thing is the same thing as the parameter thing)
NI> is_equal in what sense? (String, Number, ...)
NI>
Dan Sugalski <[EMAIL PROTECTED]> writes:
>is_equal (true if this thing is equal to the parameter thing)
>is_same (True if this thing is the same thing as the parameter thing)
is_equal in what sense? (String, Number, ...)
and how is is_same different from just comparing addresses of the t
Dan Sugalski writes:
: Type returns a magic cookie value of some sort (Not sure what sort yet),
: name returns a string with the name of the type of the variable.
Why can't the type object just stringify to the name of the type?
>From a language level, I'm inclined to say that any bare identifi
Dan Sugalski writes:
: Anyone got anything to add before I throw together the base vtable RFC?
So how do you call a generic method?
Larry
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Type returns a magic cookie value of some sort (Not sure what sort yet),
So? What good is it? You might as well make it some sort of id. Then
perl could do the equivalent vs. identical determination without asking
the object to do it.
Dan Sugalski wrote:
> We're shooting for speed here. Any common operation that could be affected
> by the type of the variable should be represented so a custom function can
> be called that does exactly what needs to be done.
>
> Dan
so if I want to make
>>DS> get_bool
>>
>>Is this allowed to return a non-true/false result? Or is everything
>>true or false?
>
>Dunno yet. I'm thinking just a true/false value, but...
A tri-state bool would be really cool (i.e, true/false/undef). Although I
understand that this probably isn't where Perl 6 is goi
At 11:11 AM 9/1/00 -0400, Chaim Frenkel wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>DS> Okay, here's a list of functions I think should go into variable vtables.
>DS> Functions marked with a * will take an optional type offset so we can
>DS> handle asking for various permuta
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Okay, here's a list of functions I think should go into variable vtables.
DS> Functions marked with a * will take an optional type offset so we can
DS> handle asking for various permutations of the basic type.
DS> type
DS> nam
At 01:49 AM 9/1/00 -0400, Bradley M. Kuhn wrote:
>Dan Sugalski wrote:
> > > > get_value
> > > > set_value
>
> > The get/set value functions are for when something knows what the SV (or
> > whatever we call it) really is and can handle the raw data. For example,
> > if my code knew a SV he
At 01:44 AM 9/1/00 -0400, Bradley M. Kuhn wrote:
>Dan Sugalski wrote:
> > At 04:59 PM 8/31/00 -0400, Buddha Buck wrote:
> > >At 04:43 PM 8/31/00 -0400, Dan Sugalski wrote:
> > >>Okay, here's a list of functions I think should go into variable
> vtables.
> > >>Functions marked with a * will take a
At 10:46 PM 8/31/00 +, David L. Nicol wrote:
>Dan Sugalski wrote:
> >
> > Okay, here's a list of functions I think should go into variable vtables.
>
>All the math functions are in here. Can the entries that my type does
>not use be replaced with other functions that my type does use?
That's
David L . Nicol <[EMAIL PROTECTED]> writes:
>Dan Sugalski wrote:
>>
>> Okay, here's a list of functions I think should go into variable vtables.
>
>All the math functions are in here. Can the entries that my type does
>not use be replaced with other functions that my type does use?
NO !
--
N
David L . Nicol <[EMAIL PROTECTED]> writes:
>Dan Sugalski wrote:
>>
>> Okay, here's a list of functions I think should go into variable vtables.
>
>All the math functions are in here. Can the entries that my type does
>not use be replaced with other functions that my type does use?
NO !
--
N
Dan Sugalski wrote:
> > > get_value
> > > set_value
> The get/set value functions are for when something knows what the SV (or
> whatever we call it) really is and can handle the raw data. For example,
> if my code knew a SV held a complex number (which doesn't map well to the
> int/floa
Dan Sugalski wrote:
> At 04:59 PM 8/31/00 -0400, Buddha Buck wrote:
> >At 04:43 PM 8/31/00 -0400, Dan Sugalski wrote:
> >>Okay, here's a list of functions I think should go into variable vtables.
> >>Functions marked with a * will take an optional type offset so we can
> >>handle asking for vari
On Thu, 31 Aug 2000, Jarkko Hietaniemi wrote:
> How about
>
> to_string *
> from_string *
>
> as generalizations of formatted/pretty input/output and freeze/thaw
> (cf printf/Data::Dumper/Storable)?
Erm, I could see that, but freezing and printing are still different
operations, so I'm not sur
How about
to_string *
from_string *
as generalizations of formatted/pretty input/output and freeze/thaw
(cf printf/Data::Dumper/Storable)?
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Dan Sugalski wrote:
>
> Okay, here's a list of functions I think should go into variable vtables.
All the math functions are in here. Can the entries that my type does
not use be replaced with other functions that my type does use?
> Functions marked with a * will take an optional type offset
At 03:45 PM 8/31/00 -0600, Nathan Torkington wrote:
>Jarkko Hietaniemi writes:
> > > I'm not too worried about getting the vtbl right at the first because
> > > it will be pretty obvious how it should go once the code starts to form.
> >
> > Some planning isn't that painful :-)
>
>Yes. Especially
At 05:30 PM 8/31/00 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > get_value
> > set_value
>
>Wouldn't these go on the SV and not on the inner type? Maybe I'm
>thinking value when you're saying variable?
Nope. The get/set value functions are for when something knows what the SV
(or whate
At 03:12 PM 8/31/00 -0600, Tom Christiansen wrote:
> >> get_int *
> >> get_float *
>
> >Could you elaborate on these a lot? What's an 'int'? What's a 'float'?
> >Having lately been battling a lot with quad ints and doubles vs long
> doubles
> >I seriously want this interface not to suc
At 04:05 PM 8/31/00 -0500, Jarkko Hietaniemi wrote:
>I'm confused (I might have missed some discussions, being busy in other
>fronts) so please bear with my silly questions.
>
> > type
>
>The basic set-in-stone types are...?
int, float, string, ref, hash, array. All of which have multiple lev
At 04:59 PM 8/31/00 -0400, Buddha Buck wrote:
>At 04:43 PM 8/31/00 -0400, Dan Sugalski wrote:
>>Okay, here's a list of functions I think should go into variable vtables.
>>Functions marked with a * will take an optional type offset so we can
>>handle asking for various permutations of the basic
Jarkko Hietaniemi writes:
> > I'm not too worried about getting the vtbl right at the first because
> > it will be pretty obvious how it should go once the code starts to form.
>
> Some planning isn't that painful :-)
Yes. Especially given that vtables are an unbenchmarked change. It'd
be good
> Wouldn't these go on the SV and not on the inner type? Maybe I'm
> thinking value when you're saying variable? The following seem useful
> on variables too:
>
> before_get_value
> after_get_value
> before_set_value
> after_set_value
>
> There ought to be specializations of get_value an
Dan Sugalski wrote:
> get_value
> set_value
Wouldn't these go on the SV and not on the inner type? Maybe I'm
thinking value when you're saying variable? The following seem useful
on variables too:
before_get_value
after_get_value
before_set_value
after_set_value
There ought to b
>> get_int *
>> get_float *
>Could you elaborate on these a lot? What's an 'int'? What's a 'float'?
>Having lately been battling a lot with quad ints and doubles vs long doubles
>I seriously want this interface not to suck.
I was a tad concerned there, too. I'm hoping one can painles
I'm confused (I might have missed some discussions, being busy in other
fronts) so please bear with my silly questions.
> type
The basic set-in-stone types are...?
> name
Huh? A name for what? (How does this relate to a 'string'?)
> get_bool
Stored as...? char? int? Boolean or
At 04:43 PM 8/31/00 -0400, Dan Sugalski wrote:
>Okay, here's a list of functions I think should go into variable vtables.
>Functions marked with a * will take an optional type offset so we can
>handle asking for various permutations of the basic type.
Perhaps I'm missing something... Is this f
Okay, here's a list of functions I think should go into variable vtables.
Functions marked with a * will take an optional type offset so we can
handle asking for various permutations of the basic type.
type
name
get_bool
get_string *
get_int *
get_float *
get_value
62 matches
Mail list logo
