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 types
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 basic
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 to know -- that
Ken Fox [EMAIL PROTECTED] wrote:
use complex;
my $c = 2__3; # 2 + 3i
That's really gross. 2 + 3i is just add(integer(2), complex(0,3)) with
compile-time constant folding eliminating the add(). I would even go so
far as to say that 3i is just syntactic sugar for
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 basic constant folding rules _it_already_has_
"ye, wei" wrote:
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.
Stuff like that isn't the problem with using C++.
At 01:34 PM 10/17/00 -0400, Ken Fox wrote:
I think the general idea is that the advantages of C++ don't move us
far enough out of our comfortable local minimum to make it worthwhile.
Yup, that pretty much covers it. C++ also has an awful lot of stuff in it
that, while interesting, is too likely
Further to my earlier ramblings and worries about binary operators
and overloading etc
Here is a proposal for the numerical part of the SV API that
provides a framework for arbitrary precision arithmetic, while still
allowing standard ints and floats to be handled efficiently.
Some of the
Here is a proposal for the numerical part of the SV API that
provides a framework for arbitrary precision arithmetic, while still
allowing standard ints and floats to be handled efficiently.
[some quick very high-level comments]
Don't forget bigrats.
1) binary operators should in general
Jarkko Hietaniemi [EMAIL PROTECTED] wrote:
[some quick very high-level comments]
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??
2) in general we want the result of a binop to be
On Mon, Oct 02, 2000 at 12:47:18PM +0100, David Mitchell wrote:
Jarkko Hietaniemi [EMAIL PROTECTED] wrote:
[some quick very high-level comments]
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
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 that
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
while $a and
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 version of add()"? Beware of combinatorial explosion:
addII,
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
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 intellignet
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 with these is that they may impose a single implementation
of scalars upon us
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 make $foo be
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-log_or(bar, baz));
But
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 $bar
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):
set_context(ARRAY,
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, up to a
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
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 what
"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 name
What are
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 going, most
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 up
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
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
"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 and how is
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 thinking if
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 the
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.
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
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 for
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 painlessly
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 be
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 and
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 to
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 type.
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 suck.
I was a
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 whatever we
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 given that
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
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:
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/float/char
46 matches
Mail list logo
