(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
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
[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,
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
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
> 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 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
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
"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
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
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
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
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:
> 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
__
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:
> 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.
"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
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
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
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:
> 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.
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
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
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
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).
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
> >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
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
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
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
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
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:
> 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
"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
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
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
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
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'
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
> 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
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
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:
> 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
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
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!?
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
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
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
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
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
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
[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
[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.
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
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 <
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
> 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,
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
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
> [EMAIL PROTECTED] ?
s/dev/code/, of course.
--
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
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.
>
> 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
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
e, he doesn't have access to a C
> > compiler.
Hate to say it... well, no, I don't really.
Wouldn't Tcl be the best example to follow here?
--
John Porter
Aus tiefem Traum bin ich erwacht.
includes a new regex module is no different from that crap including
> any other kind of 'not part of the core library' module.
>
> ...
> I disagree. Perl isn't about standing in the way of anything.
'Fraid I have to agree with Tim on this one.
--
John Porter
t; of all the schemes ...
O.k., not that! :-)
--
John Porter
I note that the sample RFC on the web site is for "Safe Signal
Handling", and it references a (currently) fictitious other
RFC, "Event Loop". Is someone working on submitting real RFCs
for these two topics?
--
John Porter
string) which the foreign code is welcome
> to override if it wishes.
I wonder if this idea was (or could yet be) informed by CORBA IDL,
or perhaps some other IDL, such as Xerox ILU?
--
John Porter
e but a 'matrix' table ! only 1/2 ;-)
Yep. Multimethods. Urghh.
--
John Porter
David L. Nicol wrote:
> John Porter wrote:
> >
> > "All flow control will implemented as longjumps."
>
> # language description has a lot to do.
How does that validate the attitude, "Only GOTO considered harmless"???
--
John Porter
02.htm
http://www.byte.com/art/9504/sec11/art3.htm#fouracid
There are probably better references out there; these are the
first few that I found.
--
John Porter
perl5 is silly.
Perl6 should be a well-designed, consistent, integrated opus.
If it goes against the grain of perl6's design to have system-specific
system calls built in, then they shouldn't be built in, regardless of
how it was in perl5.
--
John Porter
We're building the house of the future together.
Larry Wall wrote:
> Dan Sugalski writes:
> : Or, more succinctly, we're not going to screw with perl without a *darned*
> : good reason.
>
> Er, perl is already screwed--it's Perl we're trying to preserve and grow.
Man; leave it to Larry to say the right thing, i
Perl will ship with fork. But maybe in a loadable library, eh?
--
John Porter
We're building the house of the future together.
Tom Christiansen wrote:
>
> Why don't we just say that Perl isn't for
> systems work anymore, and remove everything that diddles $!,
> or $?, or anything that might call anything from the C library.
As in "remove mountains", yes.
--
John Porter
Steve Fink wrote:
>
> "cond" for conditional?
I was thinking along that line, too. But coopting "conditional" in any way
is probably an ungood idea.
Probly "trans" is good; it has multiple useful mnemonic values: transactional,
transfer, transparent...
--
cture to start, but they won't have to stay that way.
Yah, I did exactly this in Tie::Multidim... and it is *hairy*. And slow.
--
John Porter
We're building the house of the future together.
ion-catching
be done at the same level as the transactional scope.
eval {
$foo = 1;
trans {
local $foo = 2;
die;
}
};
As a trivial case, perhaps exceptions are not being caught at all.
--
John Porter
We're building the house of the future together.
\n"; # should print 0
Personally, I'd rather see transaction-enabling requested on
a per-variable basis.
--
John Porter
We're building the house of the future together.
Ken Fox wrote:
> Perl is more like lisp with a good syntax -- in other
> words about as far from C as you can get.
I agree 100%.
--
John Porter
don't know, never used one) --
and this alone makes it hard to translate into machine code,
even going through C. And this is true even if our target is
something like the JVM, which is still essentially a low-level
machine, not unlike silicon.
--
John Porter
We're building the house of the future together.
Uri Guttman wrote:
>
> the best fit is the TIL (threaded inline code) model we have
> discussed.
Yes!
--
John Porter
k that if it could be done at all,
it would only be in extension (formerly XS) code.
--
John Porter
We're building the house of the future together.
Simon Cozens wrote:
>
> (The deadline for collecting ideas passed two weeks ago. Why is this all
> still going on?)
Because there are still many worthy ideas which have not surfaced yet.
Which is the higher priority?
--
John Porter
We're building the house of the future together.
should not confuse OOD with OOP.
--
John Porter
Jetzt schalten wir das Radio an. Aus dem Lautsprecher klingt es dann...
1 - 100 of 123 matches
Mail list logo
