I've decided it's time for me to take another break from this list.
Not that any of you care, but I think the reason is important.
Due to a silly misunderstanding -- one which could have been easily
avoided by a simple request for clarification -- our Illustrious
Summarizer decided to be grievous
Piers Cawley wrote:
>
> >> Juergen Boemmels <[EMAIL PROTECTED]> writes:
> >> > But how do I represent them at parrot-level.
>
> Thanks for that John. I always relish being patronized.
You're welcome, but that wasn't for you, that was for Juergen
and anyone else who might have been wondering the
Steve Fink wrote:
> Here is the new PMC I keep babbling about. Before I commit it, any
> comments? Like, does anybody think this should be named differently?
> It's really a dequeue (double-ended queue), ...
I for one think it ought to be called what it is - a dequeue.
--
John Douglas Porter
Piers Cawley wrote:
> Juergen Boemmels <[EMAIL PROTECTED]> writes:
> > But how do I represent them at parrot-level.
>
> { type => '*environment*' value => {scratchpad => aScratchPadPMC}
Etc.
The point being, we're building these things into parrot so that
HLLs can use them natively, rather than
> [EMAIL PROTECTED] ?
s/dev/code/, of course.
--
John Douglas Porter
Bryan C. Warnock wrote:
> make things easier for others to get more of a community buy-in, at the
> expense of effort by the Perl folks, but there's no guarantee that those
> people will come.
[EMAIL PROTECTED] ?
--
John Douglas Porter
Dan Sugalski wrote:
> John Porter wrote:
> > But what does Larry think?
>
> Hadn't particularly asked him. Does it really matter?
Not if you say it doesn't.
--
John Douglas Porter
Dan Sugalski wrote:
> John Porter wrote:
> > Some folks seem to think that sufficient reason exists now.
>
> That's fine. You don't have to convince some folks. You have to convince me.
Actually, uh, I was kinda hoping that some folks would convince you. :-)
Anyway,
Thanks, Steve. I agree 100% with everything you said!
Except:
> ... the best way to that
> goal is to use Perl6 as the driver, at least until something else
> shows up, because that's the only way to derive realistic requirements
> for what needs to be accomplished.
The incorrectness of that i
Dan Sugalski wrote:
> What's more likely is that Parrot will accumulate bits from
> other languages--rather than losing Perl we'll gain Ruby and Python.
> Maybe others too.
But that doesn't address the real issue, which is --
Are we really serious about enabling other languages to target this
m
Bryan C. Warnock wrote:
> IANADan, but he's aware of these issues, and is/has been thinking about
> them.
Fine. But what does Larry think?
> We're not going to fool anyone that this isn't a Pet Perl Project, and
> while other communities are eyeing us, it's not clear that the amount of
> work
Sean O'Rourke wrote:
> ... I don't see how giving the list a
> different name will have any real effect ...
?
It will have a huge psychological effect, at least outside our tight
little club. But if that's only as far as you can see...
--
John Douglas Porter
Dan Sugalski wrote:
> The intent ultimately
> is that you hand an AST, and potentially some rules, to IMCC and it
> creates bytecode for you from it.
That's different, then. Then the whole issue of syntax goes away.
Unless the data interchange format is textual; but even then, you'd
want a syn
Melvin Smith wrote:
> Good question. The problem is, there is no one but us to answer
> that question. Or who are we waiting for?
I'd like to think that Dan would just declare on the matter
and put it to rest. But what I *really* think is that Larry,
or at least Damian, might have something very
Sean O'Rourke wrote:
> However, if we already have a working register
> allocator and peephole optimizer, I see little reason to write another.
Maybe you're taking a very perl6-centric view. (I don't know.)
But as someone who's writing an Tcl-to-parrot compiler
(for (hypothetical) example), I mig
Brent Dax wrote:
> John Porter:
> # languages. Seems to me that to say that every feature of parrot
> # must be exposed in imcc is to imply that all upper-level
> # languages must go through imcc -- and that's something I
>
> Let me see if I can follow your logic: I
Leopold Toetsch wrote:
> > I don't understand why it is so hard to adopt. imcc is supposed to be
> > a step closer to higher level languages, which is why I went that way.
>
> No problem here, it is called _intermediate_ ..., which is a worthful
> step in code generation, but - as always - there
Angel Faus wrote:
> I am all for the creation of a new list for stuff such as imcc, and perl6
> compilers. ([EMAIL PROTECTED]?)
I wonder if maybe perl6-internals should have been named parrot, anyway.
By being less overtly perl-centric, and thus more HLL-neutral, we could
have gotten more direc
Dan Sugalski wrote:
> I expect a UINTVAL should be sufficient to hold the counter.
Why? Because you don't expect a perl process to run longer
than a couple hours? Or because rollover won't matter?
--
John Douglas Porter
Piers Cawley wrote:
> I'd also like to be able to generate parrot code from within parrot
> and immediately execute it...
Something like that will be needed for eval() anyway, right?
--
John Douglas Porter
Nicholas Clark wrote:
> but in the scope of use integer signed integers are used:
>
> $ perl -we '$a = 0xDEADBEEF; {use integer; $b = $a >> 4} printf "%08X\n%08X\n", $a,
>$b'
> DEADBEEF
> FDEADBEE
>
> [Actually, IIRC it's up to the C implementation what it does, but for both
> platforms I've ju
Aldo Calpini wrote:
> I have to disagree. the corresponding Perl script
> does not show this behaviour:
It all depends. :-)
$\ = "\n";
$#a = 100;
print scalar(@a);
$x = $a[1][0];
print scalar(@a);
101
10001
Perl has to autoviv if it has to drill down.
--
John Douglas Porter
Sean O'Rourke wrote:
> I read that as "expressions are evaluated once", not "PMC's are accessed
> once". So something like
>
> 2 < $i++ < 23
>
> will do the expected -- increment $i once, keeping the result in a PMC
> temporary.
I don't see that. $i++ increments the original PMC.
2 <
Dan Sugalski wrote:
> Yes. Hashes will take either strings or object IDs, depending on the
> hash. (The hash can choose)
Seems to me it would be mighty useful to have integer keys as well.
For large sparse arrays, e.g.
--
John Douglas Porter
[EMAIL PROTECTED] wrote:
> My opinion: rename the current PerlHash to Hash, and create
> a new PMC PerlHash that does PMC->PMC mappings.
How about two hash types: one that does shallow comparisons
and one that does deep comparisons.
Which one Perl6 should use would be an open question, I guess.
[EMAIL PROTECTED] wrote:
> Also, how deep should we go if we decide to have the hash algorithm
> work on the contents?
>
> One starts to understand why scheme has C, C and
> C.
Indeed. It's also why it allows to specify, in AA accesses,
what equality-testing operator you want keys to be compar
Aldo Calpini wrote:
> this is a little tutorial about submitting patches
> (should be added to a FAQ, or somewhere where it's handy
I think this deserves its own page somewhere on
dev.perl.org.
--
JohnDouglasPorter
__
Do You Yahoo!?
Yahoo! Heal
very recently I wrote:
> ... fine. Whatever.
People, if I'm coming across with a nasty or petulant tone,
I sincerely apologize. It's really not what I was going for.
jdp
__
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://aut
Andy Dougherty wrote:
> I think the purpose of the .dev files, as laid out in
> docs/pdds/pdd07_codinstd.pod, is a reasonable one.
> Here's an edited excerpt: . . .
(Thanks, Andy.)
Well, given that definition of the purpose, I must
persist in my opinion that the proper place for that
kind of d
Brent Dax wrote:
> Do you really want to see a ten-page discussion of hashing
> algorithms and why the current one was chosen in the middle
> of classes/perlhash.pmc?
I guess that wouldn't bother me as much as it might bother
some other people.
> *That's* the sort of thing the .dev files are f
Tanton Gibbs wrote:
> . . . That saves a person digging through
> the .c file to find what they are looking for.
> Perhaps we could automatically update the .dev
> file with the POD found in the .c file?
As someone else has already said, a better place
for the .dev information might be inside t
Melvin Smith wrote:
> Hmm, looking at the source directory, I'm starting to think
> maybe that isn't so good, it is pretty busy already.
>
> We have one vote for a /dev directory.
Actually, I think Dan did -- or at least was going to do --
something about this last night. Part of it was to sho
Melvin Smith wrote:
> I put it temporarily in the root dir, which I know is wrong.
> Where should .dev files go, anyway?
Actually, I think that's right.
..dev files live alongside their .c/.h siblings, no?
--
JohnDouglasPorter
__
Do You Yahoo!?
Nicholas Clark wrote:
> ... PerlIO::subfile (treats a section
> of a file as if it is a whole file - lets you read direct from a tar
> on an uncompressed file stored in a zip file)
Ah -- just like Virtual File Systems (VFS) from Tcl-land.
Good idea!
('COURSE it's a good idea!)
--
JohnDouglas
David M. Lloyd wrote:
> No, the point is that all this talk about type-space mm dispatch
> depends on there *being* type space. Since there is currently
> no inheritance to speak of then there really is no typespace so
> all of this talk is moot,
I agree; but you did express a concern earlier t
John Porter wrote:
> The point is that this type schema is at the parrot level,
> and is not the concern of a user-level language like perl
Of course this is not really true; perl scalars, arrays, and
hashes (etc.?) are implemented as PMCs under the hood, so
in that sense they are rela
David M. Lloyd wrote:
> John Porter wrote:
> > The MM dispatch problem is pretty much solidly in
> > the realm of pmc inheritance,
>
> There _is_ no pmc inheritance right now.
> There's just a set of default functions.
Call it what you want.
The point is that this
> But what about setting size on multdimensional PMC's
> would it also be:
> set P0,5,5,5
> assembler.pl would try to call
> set_p_ic_ic_ic
> This will break things when having N dimensions..
I don't see how it could possible be workable
to have all the indices listed out in the instruct
Scott Walters wrote:
> * PMC's be accepted in place of or in addition to KEY *'s
> in variants taking multidim subscripts.
In particular, a PMC containing a vector (aka tuple, aka array)
of indices, one per dimension.
As in so many other cases, the array object and the key vector
object shoul
In his P6 Summary for 2002-07-14, in section
"Perl 6 grammar, take 5", Piers says:
someone pointed out that [the grammar] had a problem
with code like
{ some_function_returning_a_hash() }
Should it give a closure? Or a hash ref?
Larry hasn't commented so far.
I couldn'
Damien Neil wrote:
> I'm not familiar with "predictive seeks",
> can you give a quick explanation?
It's very much like predictive loading of the instruction cache
in a cpu. It makes a heuristic guess that since you just read
1000 bytes in order, you're probably going to want to read the
next 10
Sean O'Rourke wrote:
> ... all it buys you is a few bits of precision when your ints
> and floats are both 64-bit, and slower comparisons all the time.
> IMHO it's a wash, so I did it this way.
I would point out that integers have infinite precision.
More than a few bits' difference, I'd say.
B
Sean O'Rourke wrote:
> NOTE: this may be part of the monster-patch to fix the over-agressive
> string GC (814), but it's much more palatable in this form.
> PerlInt's
> cmp() method was backwards, and would truncate floats on the other
> side of the comparison.
> This patch always uses floating
"David M. Lloyd" wrote:
> Do we really want *two* inheritance trees per object
> in Perl 6? One language-level and one PMC-level?
Well, parrot != perl6, so I don't see a problem.
The MM dispatch problem is pretty much solidly in
the realm of pmc inheritance, and that's something
we have control
Brent Dax wrote:
> If people want that scheme, speak now or forever hold your peace.
Sounds reasonable to me. (FWIW)
> > _Parrot
> > _parrot
> > __Parrot
> > __parrot
>
> The last four are reserved by various C and C++ standards.
Damn, I forgot about that. I'm a C coder from Way Ba
Brent Dax wrote:
> Ashley Winters:
> > c. parrot_sprintf
>
> Lowercase is always the hallmark of struct names, i.e.
> parrot_string_t.
Ehhh... you yourself said something about plat_ and misc_
as (theoretical) alternatives.
Anyway, it's a silly rule. Upper-case (and lower-case) are
going to h
Brent Dax wrote:
> > 2. What does having a Parrot_ prefix signify, considering
> > both the opcodes and the embed api use it?
>
> It signifies one of the following:
> -This function is externally visible.
> -This function belongs to Parrot at large, and not any particular
> subsystem (e.g. Par
Ask Bjoern Hansen wrote:
> [EMAIL PROTECTED] (John Porter) writes:
>
> > Yeah, look at the so-called Parrot FAQ. Someone needs to
> > get serious and make a real FAQ for parrot developers.
>
> I'm sure noone would mind if you start one!
Does no one on this maili
Melvin Smith wrote:
> What parts particularly bug you? Maybe we can address a few.
Well, basically, AFAICT, virtually none of the parrot code
is adequately documented. So, pick a random entry point. :-)
But this is why I'm not suggesting that someone drop what
they're doing and going in and do
Melvin Smith wrote:
> Guys, look at the facts. We have a very small number of
> internals hackers here, and only one who actually gets
> paid for it. . . . We are not an army.
"I'm so busy building this tower single-handedly,
I don't have time to teach anyone else how to cut
stone or mix mortar
> >Which IRC network, which channel?
>
> I use irc.pobox.com, you can also try irc.rhizomatic.net
> Channel is #parrot
Problem I have with irc (besides the fact that I don't, can't
and won't use it) is that all the good stuff that flows by
isn't getting captured and archived anywhere. I'm su
I have to say that I am extremely disappointed at the
paucity of internal documentation.
One of the goals of the p6 rewrite is to make the code
more accessible for maintainers who will come along later.
This cannot happen without good, substantial internal
documentation.
And I don't wanna hear
Dave Mitchell wrote:
> IIRC, all metrics of the form (x^n + y^n)^(1/n), n=1,2,...Inf
> are strongly equivalent, ie they give rise to the *same* ordering.
> (In the limit as n -> Inf, the metric is max(x,y).)
I'm sorry, YDNRC.
Consider the distance from the origin to the points (0,6) and (3,4).
Dan Sugalski wrote:
> Piers "Fermat" Cawley wrote:
> > Oh yes, and I recently wiped it (p5 port included) by accident.
> > And didn't have a backup. Ah well...
>
> That's just a bit of self-preservation on the part of the universe,
> I expect... ;-P
Then the universe hasn't evolved to the point
Nicholas Clark wrote:
> I was thinking that the metric (x*x + y*y) would be fast to
> calculate, as that's all we need for ordering.
Point is, it's rather *more* than we need for ordering.
x + y will suffice.
> And I live in London, where we don't have a regular grid of
> streets, so our taxis
Andy Dougherty wrote:
> Assuming x and y are coordinates in a 2-d space, and that both are
> integers >= 0, why not just use what is affectionately called the
> "taxicab" metric: x+y? It is just as "valid" and even quicker to
> compute than the Euclidean metric sqrt(x^2 + y^2).
Yes! Very inci
Dan Sugalski wrote:
> That trades space for speed,
Ain't it always the way. ! :-)
> In general that's potentially unbounded, but for the specific
> case of PMC vtable methods it's a fixed number.
> It gets more interesting for general methods and subs,
> but we can deal with that a bit later.
Dan Sugalski wrote:
> Nicholas Clark:
> > Unless I'm being thick, x" < y" whenever x < y for positive x
> > and y (ie you don't need to take the square root of the
> > hypotenuse to work out which hypotenuse is shorter. And all
> > we're actually interested in which one is shorter, aren't we?)
>
Dan Sugalski wrote:
> lookup is O(n) since we precompute the dispatch table.
Oh. So the cost of computing the table is amortized over all the
mm calls that go to the table for resolution. Could be Bad,
for the typical small Perl program.
Then there's the issue of the size of the table.
Consid
Brent Dax wrote:
> Nicholas Clark wrote:
> > Unless I'm being thick, x² < y² whenever x < y for positive x
> > and y (ie you don't need to take the square root of the
> > hypotenuse to work out which hypotenuse is shorter. And all
> > we're actually interested in which one is shorter, aren't w
"Andreas J. Koenig" wrote:
> ... trimming CC list always would probably be an overreaction.
Sounds like you have good reasons.
Oh well, some people win, some people lose.
:-/
--
John Douglas Porter
__
Do You Yahoo!?
Sign up for SBC Yahoo! Dia
Dan Sugalski wrote:
> John Porter wrote:
> > but what about non-PMC variables?
>
> Generally speaking, there aren't any. Everything else (in this case
> the buffer/string things) is for internal use only. Languages aren't
> supposed to expose strings directly.
Would I be out of line to request that people edit their email
headers so that replies only go to the list?
I'm tired of getting two (or more) copies of everything on
any thread I've posted in.
Thanks,
John Douglas Porter
__
Do You Yahoo!?
Sign u
Dan Sugalski wrote:
> I'm not sure that the place to enforce read-onlyness is at the
> string/buffer level. Doing it at the PMC level is more likely the
> right place to do it.
Yes; but what about non-PMC variables?
--
John Douglas Porter
__
Dan Sugalski wrote:
> What we're
> doing is assuming we don't know and letting the variables decide
> whether they'll care. Perl's will, though other languages can decide
> differently.
Letting the variables decide?
So, we take a poll of all the arguments, and ask each one
which they think ou
Dan Sugalski wrote:
> These 'add-on' bytecode interpreters don't get any special
> consideration in the core. That means they *can* have:
>
> *) A custom bytecode loader to translate their bytecode format
>to ours, or something we can use
> *) As many custom PMC classes as they want
> *) D
Florian Haeglsperger wrote:
> But isn't this partly addressed with COW?
> . . .
> Thus I don't see a very big performance win in introducing mutable
> strings.
Good point.
But some people maintain that there could be a need for truly
"constant" strings, that should never be modified, and any
a
umm... has anyone else noticed that pdd02 in the distribution (0.4)
is spouged, and that pdd03 is completely missing?
--
John Douglas Porter
__
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
"Clark C . Evans" wrote:
> So, I propose that Parrot supports both of these attitudes
> of reasoning by using a flag. Initially, all strings
> are 'mutable'.
I concur with Clark. What he's proposing is (it seems to me)
nothing more than a "read-only" flag, and that's as
immutable as a variab
Garrett Goebel wrote:
> John Porter wrote:
> > Not to beat on Dan (or anyone else), but for the sake of those
> [...]
>
> Please don't beat on Dan... ;)
I'm not!
> Parrot isn't Perl. I.e., your Perl-vision blinders are on a tad
> tight. It's the fi
Dan Sugalski wrote:
> John Porter wrote:
> >I assume (but I'm open to correction) that it is *not* to simulate
> >the vm of other language environments, so as to execute faithfully
> >bytecode produced in those environments. (That is, taking object
> >code f
Dan Sugalski wrote:
> John Porter wrote:
> > I assume (but I'm open to correction) that it is *not* to simulate
> > the vm of other language environments, so as to execute faithfully
> > bytecode produced in those environments. (That is, taking object
> > code f
> Dan wrote:
> > 1) Dig through the perl source and find out all the opcodes.
> > (pp.c and friends) Document the opcodes and what they do.
> >
> > 2) The same as #1, only for Python
> > . . .
> >
> > Once we get these, the next task is to write an opcode library
> > for them...
I want to unde
Dan wrote:
> Okay, here are some tasks for the interested. They're all related
> (I expect you'll see the pattern), but independent anyway.
>
> 1) Dig through the perl source and find out all the opcodes.
> (pp.c and friends) Document the opcodes and what they do.
>
> 2) The same as #1, only fo
http://www.complang.tuwien.ac.at/anton/vmgen/
(Sorry if this has been mentioned before...)
--
John Douglas Porter
__
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
[restricted to -internals, since that's the only one I'm on]
[EMAIL PROTECTED] wrote:
> Oh yes. John Porter suggested that 'maybe Damian should write
> [the grammar]?'. Which leads me to postulate an analog to Godwin's
> Law, tailored to the perl 6 process,
For some reason I feel really, really bad saying this --
in fact, I'm warming up the flog right now -- but, um,
maybe Damian should write it?
__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
(I don't have the original msg in my mbox, so I'm jumping in here...)
The following is from the Tcl bytecode compiler [1] FAQ:
Why doesn't Tcl use the Java bytecodes?
I [2] had originally hoped to use Java bytecodes because they have a
mature design and because Java is widely available. I cho
2/3 of the way down.
(Hm, do you think I care about this issue? ;-)
--
John Porter
A word spoken in the mind will reach its own level in the objective truth.
Brent Dax wrote:
> > use Fcntl qw(:seek);
> > seek DATA, 0, SEEK_SET;
> > @code = ;
>
> IMHO, that's too hackish--just reading that doesn't make what you're
> doing obvious.
It also can only get the main program, not any of the modules it loads.
--
John Porter
Michael G Schwern wrote:
> On Mon, Aug 27, 2001 at 10:58:00AM -0400, John Porter wrote:
> > You can, with C< goto &$foo; >.
> > Problem is, it's *slower* (in p5 anyway) than the plain sub call.
>
> By only 10%. Let's keep things in proportion here.
O.k
Ken Fox wrote:
> The only thing I'd like to change is to make &foo a tail call instead
> of a normal function call. But I guess that would *really* confuse
> people.
You can, with C< goto &$foo; >.
Problem is, it's *slower* (in p5 anyway) than the plain sub call
in terms
of real-world programming.
--
John Porter
Science class should not end in tragedy.
atical nonsense)
> So instead, I'd like
>
> "my outer $x" to be shorthand for
I guess you missed where I suggested that putting "my" on that
declaration is also counter-sensical, not to mention redundant.
"my" implies a brand-spanking-new lexical variable attached
to this very scope. The semantics of "outer" (or "closed"...)
can be defined to imply a lexical variable.
--
John Porter
Dave Mitchell wrote:
> ie by default lexicals are only in scope in their own sub, not within
> nested subs - and you have to explicitly 'import' them to use them.
No. People who write closures know what they're doing.
When's the last time someone "accidental
David L. Nicol wrote:
> eval ${code}o;
Another brilliant idea from David Nicol!
However, I'm not keen on the syntax.
I'd rather see a different keyword. I'm thinking "eval1",
but I'm not very creative. :-/
--
John Porter
Science class should not end in tragedy.
Bart Lateur wrote:
> This has a vague smell of Fortran.
Nothing vague about it. It is exactly analogous to Fortran's three-way if.
--
John Porter
hat to understant?
> What you're asking has no counterpart in boolean logic, and
> as such would make no sense in any computer language.
Screw boolean. It's just a three-way switch, exactly as if/else
is a two-way switch. (As has been noted, switch() would handle this
and
s been done already.
--
John Porter
David L. Nicol wrote:
> No, that does not work:
Right; I misunderstood what was wanted.
--
John Porter
$y => substr( $s, 10, 15 ),
@z => @a[5..8,13];
etc.
--
John Porter
all it
> 'transform' for transformation of any structure to other structure..
This sort of thing should certainly not be in the kernel.
--
John Porter
is:
for ( \@foo, \@bar ) {
print "$_->[0] : $_->[1]\n";
}
--
John Porter
orm of "for" which can iterate
over a list of hashes or arrays:
for my @a ( @foo, @bar ) { ...
for my %h ( %foo, %bar ) { ...
--
John Porter
le source will use the
> temp variable there is still a need for an explicit scalar like $_.
> Unless there is something I am missing from this discussion.
No. with() must be consistent with other perl constructs.
If implemented, it will use $_. Plain and simple.
--
John Porter
( @argset1, @argset2 ) {
&quux;
But I'm not convinced of the utility of this over using
scalar references.
--
John Porter
} ) {
$_->cells(1,1) = "Title";
$_->language() = "English";
}
(presuming lvalue-methods, of course...)
--
John Porter
Uri Guttman wrote:
> one related point is that this symbol table will be accessible via
> caller() so you could access/install lexical symbols in a parent block
> on the call stack. scary!
Quite. Does anyone have a pointer to tchrist's rant on Tcl's upvar?
--
John Porter
[EMAIL PROTECTED] wrote:
> ...just made them a convenience for identifying type errors...
I.e. type-safe macros.
--
John Porter
n.
> This would be a nice thing to have a pragmata for, what hash refs
> stringify to.
Um, one pragma.
--
John Porter
1 - 100 of 570 matches
Mail list logo
