As I see it, there will be 3 types of access to bigint/nums.
1) there is the internal implementation of the PMC types associated
with them. This is where all the messy code gets hidden (assembler
optimations, register length-specific code etc).
2) PDD 2 requires that all PMC types return their
The C structure that represents a bigint is:
struct bigint {
void *num_buffer;
UV length;
IV exponent;
UV flags;
}
[snip]
The Cnum_buffer pointer points to the buffer holding the actual
number, Clength is the length of the buffer, Cexponent is the base
10
Following up from a thread a couple of weeks ago,
Dan wrote:
Dave wrote:
Hmmm, I can't quite how that trick works. How whould the following get
evaluated:
$opened || open(F, ...)
The second PMC would point to a lazy list, so it wouldn't be evaluated
unless its value gets fetched.
Do
Dan Sugalski wrote:
Grab one via a utility function. getPMC() or something of the sort.
newPMC() ? ;-)
I think we shouldn't rule out the possibility of having multiple
newPMC() style functions for grabbing PMCs used for different activities
(eg lexicals vs tmps vs
Based on the silence == assent prinicple, I think we have agreed:
1. we need "a relatively strict and standard way" to document code.
2. This is the time and place to discuss it.
3. The result of the discusssion should be a PDD.
4. Most commentary should appear within the src file itself, or
Regarding comments in code:
Chopping and misquoting wildly
Jarkko Hietaniemi said:
* I would define a relatively strict and standard way to do this so that
the documentation can be extracted out.
* lets avoid a markup-up flamewar
Simon Cozens said:
* I'd like to see Perl 6 written as a
Tolkien quotes are mandatory?
perl5's globals.c malloc.c perlio.c perly.c universal.c xsutils.c
definitely fail then.
Sounds like some urgent patches need submitting to p5p ;-)
Do we want to go with Tolkein quotes for perl 6 and, if so, who wants to
put together a list of good ones? It's been ages since I've read the books,
and I'm likely to pull quotes from other places anyway. (Usagi Yojimbo
strikes me as a good place to yank from, as does Zot!, but Pratchett
And what about us poor semi-literates who've never heard of Yojimbo ???
If we can't go with Tolkien, I'd vote for Pratchett, 'cause *everyone*'s
read him :-)
Adams rather than Pratchett, I'd think. :)
But Pratchet has 20+ books to his credit, so we need never run out of quotes
:-)
I originally starting writing this as a bit of a joke, then I thought
perhaps I should submit it as a serious suggestion. Anyone violently
against or in favour? Is this even an issue that should go in a PDD?
Does anyone care? Should I return to my box now?
Dave M.
Ken Fox [EMAIL PROTECTED] wrote:
David Mitchell wrote:
To get my head round PDD 2, I've just written the the outline
for the body of the add() method for a hypophetical integer PMC class:
[... lots of complex code ...]
I think this example is a good reason to consider only having one
After a week's delay where I've just been too busy,
I thought I'd resurrect the corpse of a thread I was involved in.
First off,
on Wed, 07 Feb 2001 14:37:33, Dan Sugalski [EMAIL PROTECTED] wrote:
At 07:05 PM 2/7/2001 +, David Mitchell wrote:
Dan, before I followup your reply to my
Some comments about the vtable PDD...
First a general comment. I think we really need to make it clear for
each method, which arg respresents the object that is having its method
called (ie which is $self/this so to speak). One way to make this clear
would be to insist that the first arg is
Please see my previous post on the subject. As I pointed there, implementing
|| and like that breaks short-circuits.
No, it doesn't. Just because you pass in two PMCs doesn't mean that they
both need to be evaluated. Though the PDD does need to be clearer about how
that happens.
Hmmm,
Nicholas Clark [EMAIL PROTECTED] mused:
On Wed, Feb 07, 2001 at 04:03:49PM +, David Mitchell wrote:
BTW, should the vtable include all the mutator operators too, ie
++, += and so on, on the grounds that an implementation may be able
do this more efficiently internally
++ and -- are already slightly messy in perl5
pp_preinc, pp_postinc, pp_predec and pp_postdec live in with all the ops.
They know how to increment and decrement integers that don't overflow,
and call routines in sv.c to increment and decrement anything else.
Actually, this
Dan,
I think there is a real problem with your vtable approach.
[ etc etc ]
I think there's an important misconception about tieing and overloading
going on hre which I will attempt to clear up. (Then Dan and co
can point out that I;'m I;m wrong and have just made matters worsse ;-)
First
I'm not either. They feel like they should be operators.
But I don't like the thought of going in and out of a lot of generic
routines for
$a = 3;
$a += 2;
when the integer scalar ought to know what the inside of another integer
scalar looks like, and that 2 + 3 doesn't overflow.
Dan, before I followup your reply to my list of nits about the PDD,
can I clarify one thing: destruction.
I am assuming that many PMCs will require destruction, eg calling
destroy() on a string PMC will cause the memory used by the string
data to be freed or whatever. Only very simple PMCs (such
2. Perl 5 doesn't separate well a `variable' from a `value', and this should
be done to achieve a more clear design.
Perl5 does in fact make a clear separation. 'values' are SV structures
(and AVs and HVs etc). Variables are names in stashes, PADs etc
that have a pointer to an SV or whatever.
Nick Ing-Simmons [EMAIL PROTECTED] wrote
BigFloat could well build on BigInt for its "mantissa" and have another
int-of-some-kind as its exponent. We don't need to pack it tightly
so we should probably avoid IEEE-like hidden MSB. The size of exponent
is one area where "known range of int" is
The current thread about bigints and overflows and stuff has given me
a thought:
A few of the bits in the flags word of an SV should be reserved as
part of the payload (as opposed to being generic SV flags), so a particular
SV type can make whatever internal use it likes of them. Ie the
payload
Daniel Chetlin [EMAIL PROTECTED] wrote:
What is it about automatic conversion to bigints (done well) that scares
you?
Well, consider the following perl5 code:
sub factorial {
my $n = shift;
my ($f,$i) = (1,0);
$f *= ++$i while $i $n;
$f;
}
Someone might be
Has anyone given thought to how an SV can contain both a numeric value
and string value in Perl6?
Given the arbitrary number of numeric and string types that the vatble
scheme of Perl6 support it will be unviable to to have special types
for all permuations (eg, utf8_nv, unicode32_iv,
It seems to me the following options are poossible:
1. We no longer save conversions, so
$i="3"; $j+=$i for (...);
does an aton() or similar each time round the loop
I fear this would be a performance hit. I'm told TCL pre version 8 was
like this - everything's a string and
Simon Cozens [EMAIL PROTECTED]
IMHO, the first thing we need to design and code is the API and runtime
library, since everything else builds on top of that, and we can design other
stuff in parallel with coding it. (A lot of it will be grunt work.)
Personally I feel that that string part of
Dan Sugalski [EMAIL PROTECTED] wrote:
At 06:05 PM 12/12/00 +, David Mitchell wrote:
Also, some of the standard perumations would also need to do some
re-invoking, eg
($int - $num) would invoke Int-sub[NUM](sv1,sv2,0), which itself would
just fall
through to Num-sub[INT](sv2,sv1,1
Nick Ing-Simmons [EMAIL PROTECTED] wrote:
What are string functions in your view?
m//
s///
join()
substr
index
lc, lcfirst, ...
| ~
++
vec
'.'
'.='
It rapidly gets out of hand.
Perhaps, but consider that somewhere within the perl internals there
have to be
Nick Ing-Simmons [EMAIL PROTECTED] wrote:
That is a Language and not an internals issue - Larry will tell us.
But I suspect the answer is that it should "work" without any special
stuff for simple perl5-ish types - because you need to be able to
translate 98% of 98% of perl5 programs.
On Thu, 07 Dec 2000, Dan Sugalski [EMAIL PROTECTED] mused:
My original suggestion was that scalar types provide a method that says
how 'big' it is (so complex bigreal real int etc),
and pp_add(), pp_sub() etc use these values to call the method associated
with the biggest operand,
Nicholas Clark [EMAIL PROTECTED] wrote:
On Tue, Dec 12, 2000 at 02:20:44PM +, David Mitchell wrote:
If we assume that ints and nums are perl builtins, and that some people
have implemented the following external types: byte (eg as implemented
as a specialised array type), bigreal
(whoops, correcting my own post!):
sva-refcount=0;
sva-refcount++; // these first 2 combined if we get the implemention right
svb-refcount=0;
svb-refcount++; // ditto
sva-refcount++;
...
if (--sva-refcount == 0) ... // branch not taken
if (--svb-refcount == 0) ... // branch taken,
if
Nicholas Clark [EMAIL PROTECTED] wrote:
On Thu, Dec 07, 2000 at 01:14:40PM +, David Mitchell wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
All the math is easy if the scalars are of known types. Addition and
multiplication are easy if only one of the scalars involved is of known
Nick Ing-Simmons [EMAIL PROTECTED] wrote:
Dave Storrs [EMAIL PROTECTED] writes:
On Tue, 21 Nov 2000, Jarkko Hietaniemi wrote:
Yet another bummer of the current SVs is that they poorly fit into
'foreign memory' situations where the buffer is managed by something
else than Perl. "No,
It could be argued that the way to implement "enhanced" strings, eg
strings with embedded attributes (html, rtf,) is for someone
to write a specific SV class to deal with that kind of string.
As has been pointed out, a difficulty with this is that standard
regexes must be able to operate on
Nicholas Clark [EMAIL PROTECTED] writes:
How does the regexp replacement engine cope with this? By implementing
all replacements as substr() type ops?
[or behaving as if it implements... whilst cheating and doing it direct for
scalars it understands?]
Or don't we need to work this out at
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
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
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
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
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
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
Here are a few comments on RFC35 (base format for perl variables).
[ NB - I've only just joined this list, and although I've rummaged
through the archives, I may have missed bits which make my comments
obsolete/absurd etc... :-) ]
1. void *variable_data;
I would suggest having a slightly
44 matches
Mail list logo
