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
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
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
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
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
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
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
(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
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
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
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
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 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
> >
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.
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
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
> >
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
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///
>
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
> > 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
> >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
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
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 -
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
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
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
> Perhaps you meant that Perl 6 is going to have homogeneous arrays, in
> which case an array of ints would keep 32 bits (per value) of int data in
> the array and auto-generate the extra flags and stuff when a value is
> extracted from the array. That's possible, but it's a special case of small
Jeanna FOx <[EMAIL PROTECTED]> wrote:
> Everybody seems to be missing the fact that jwz bitching about Java's
> "32 bit non-object ints" means that at least he thinks they could be
> salvaged. What would he think of Perl's "224 bit non-object ints"?!
> Don't get smug because Perl can iterate over
"Branden" <[EMAIL PROTECTED]> wrote:
> Well, mandatory locking is something we should definetly NOT have in Perl6.
> Most of perl's code today is not threaded, and I believe much of it will
> continue to be this way. The pseudo-fork thread behaviour that is being
> proposed also makes this ok. Eve
"Branden" <[EMAIL PROTECTED]> wrote:
> The thing with mandatory locks per variable, is that as long as you only
> want to access _that_ variable, it's ok, but if you want to make several
> uses of several variables and want to do it all at once, you've got a
> problem.
[ big snip ]
Sorry, I misu
James Mastros <[EMAIL PROTECTED]> writes:
> Why can't we change the meaning of time() slightly without changing to a
> different function name? Yes, it will silently break some existing code,
> but that's OK -- remember, 90% with traslation, 75% without. being in that
> middle 15% isn't a bad th
> 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, 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
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?
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
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
> >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
> 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.
> > >
>
> >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'
James Mastros <[EMAIL PROTECTED]> wrote:
> The idea is [for Larry] to declare "no, it isn't". Otherwise, you have to
> do refcounting (or somthing like it) for DESTROY to get called at the right
> time if the class (or any superclass) has an AUTOLOAD, which is expensive.
I'm coming in halfway th
James Mastros <[EMAIL PROTECTED]> wrote:
> [snip about DESTORY predictablity not being neccessary]
> You're probably right about that, Branden. Quite nice, but not neccessary.
Hmm, I'd have to say that predictability is very, *very* nice,
and we shouldnt ditch it unless we *really* have to.
[ l
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
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
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
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.
===
"Bryan C. Warnock" <[EMAIL PROTECTED]> wrote:
> To date, I've received a whopping zero comments on PDD 0, the defining
> document for the PDD process.
>
> That means one of five things:
> http:[EMAIL PROTECTED]/msg01126.html
Sounded fine to me, but since I'm not one of the Powers, I didnt co
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
> 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 ;-)
> > 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
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
"Bryan C. Warnock" <[EMAIL PROTECTED]> wrote:
> Well, there's also Meta stuff for discussion that we should probably
> document as well. As much as I disliked RFC, I also disliked PDD, as it
> 'sounds' internal. But do we create a new category for every new area we
> attempt to document, or d
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
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
Adam Turoff <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 21, 2001 at 07:44:51PM +0000, David Mitchell wrote:
> >
> > Also, if we go down the 'have a competition to see who can write the best
> > PDD on subject X' path, can we replace the 'TBD' in unnumb
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
> 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
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
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
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
> > > 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
> 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
> > 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
> > 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
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
68 matches
Mail list logo
