This is probably akin to turning a supertanker around 180 degrees, but
I'll try anyway.
I've never liked Perl's use of the terminology 'num' to mean a floating-point
value. Is there any chance in Perl 6 of using something else, eg 'float'
or 'real'?
Its just that a 'number' doesnt have any conno
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 i
> The C structure that represents a bigint is:
>
>struct bigint {
> void *num_buffer;
> UV length;
> IV exponent;
> UV flags;
>}
>
[snip]
> The C pointer points to the buffer holding the actual
> number, C is the length of the buffer, C is the base
> 10 exponent for
Jarkko Hietaniemi <[EMAIL PROTECTED]> chipped in:
> On Fri, Feb 23, 2001 at 10:26:14AM -0500, Dan Sugalski wrote:
> > At 07:12 AM 2/23/2001 -0500, wiz wrote:
> > >Just curious, has anyone ever had any discussion regarding a
'security-aware'
> > >Perl model? Some issues have recently ended up on m
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 it's
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 guaranteed-to-have-refcoun
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 f
> > 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
:-
> 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 Pratchet
> 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 ;-)
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 li
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 exa
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:
chiefly to get a feel for how it needs to handle all the various
permutations, like whether the destination pmc is trashable etc.
Could you Wise Ones tell me whethe
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, b
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
> >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'
> 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 ;-)
Firs
> > > ++ 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.
> > >
>
Nicholas Clark <[EMAIL PROTECTED]> mused:
> On Wed, Feb 07, 2001 at 04:03:49PM +0000, 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
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?
> >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
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 alway
> 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.
Dan Sugalski <[EMAIL PROTECTED]> wrote
> Subject: Re: vtbl-based SVs and sv_setsv()
>
> At 06:42 PM 1/13/01 -0800, Benjamin Stuhl wrote:
> >How is setting one SV from another going to be implemented?
> >My (admittedly vague) recollection was that it would be
> >something like
> >
> >void sv_setsv
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 in
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 a
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Okay, I'm thinking the core will have four distinct perl variable types
> internally:
>
> * Scalar
> * Hash
> * Array
> * List
Are the lists (aka lazy arrays) you're proposing really a separate core
type, or are they just a variant of the array type -
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 b
> >1. We no longer save conversions, so
> > $i="3"; $j+=$i for (...);
> >does an aton() or similar each time round the loop
>
> Well just the 1st time - then it is a number...
Err, option (1) was explicity suggesting we *dont* save the result
of the conversion, so aton() *would* have to be c
> > 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 st
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, ascii_bitint
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> David Mitchell <[EMAIL PROTECTED]> writes:
> >Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> >> What are string functions in your view?
> >> m//
> >> s///
>
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> e.g.
>
>if (SvENCODING(sv_a) != SvENCODING(sv_b))
> {
> if (SvENCODING(sv_a)->is_superset_of(SvENCODING(sv_b))
> {
>sv_upgrade_to(sv_b,SvENCODING(sv_a));
> }
> elsif if (SvENCODING(sv_b)->is_superset_of(SvENCODIN
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
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 06:05 PM 12/12/00 +0000, 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
> >
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
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.
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 12, 2000 at 02:20:44PM +0000, 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
> >
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 oper
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 07, 2000 at 01:14:40PM +0000, David Mitchell wrote:
> > Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > > All the math is easy if the scalars are of known types. Addition and
> > > multiplication ar
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> print $foo[0];
> is
>foo->get_string[UTF_8](ARRAY, 0);
> while
>print $foo
> is
>foo->get_string[UTF_8](SCALAR);
Just to clarify:
does the get_string method in an AV's vtable do an indexing lookup,
grab the relevant SV pointer, then call
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > Dave M wrote:
> >That was probably me. (Which means it was probsbly a daft proposal,
> >and everyone rightly ignored it ;-)
> >The basic idea was that all numeric SV types must provide methods
> >that extract their vlaue as an integer or float of a size
(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
> There's evidence in the
> literature that switching from reference counting to a more sophisticated
> GC scheme can also save us 5-10% in CPU overhead. (Though that's not a
> guarantee--LISPlike languages likely have different GC performance
> characteristics than perl does)
[warning: vague
Chaim Frenkel <[EMAIL PROTECTED]> wrote:
> I would have wanted to limit the vtbl to self manipulation functions.
> Set, get, convert, etc. Cross object operations would/should be
> outside the realm of the object. (It seems like trying to lift yourself
> by the bootstraps.)
There is a certainly
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> It looks to me like add needs to be polymorphic and work out the best
> compromise for the type of scalar to create based on the integer/num/
> complex/oddball types of its two operands.
>
> [Oh. but I'm blinkered in this because I'm attempting to make
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 tha
Roland Giersig <[EMAIL PROTECTED]> wrote:
> Maybe:
>
> "Perl6 should excell at manipulating *formatted* text."
Quite possibly, although as a previous poster has pointed out,
fotmatted text != XML.
ie in the sense that HTML, RTF, TeX etc, have a natural sense of containing
a single piece of te
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 th
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
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
multiply(inte
> > 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
> > 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
> > > 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
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
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 ide
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
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 larger
61 matches
Mail list logo
