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
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 same sort
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 have to
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
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 to
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 is
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, whenever someone (and it seems
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
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
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 is a
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: IMCC gives access to all Parrot
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
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
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 just tried one
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 $i+1 23
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!
[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 Ceqv?, Ceq? and
Cequal?.
Indeed. It's also why it allows to specify, in AA accesses,
what equality-testing operator you want keys to
[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
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 shove
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 the
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 for,
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
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
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 1000
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't
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 should
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
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 type schema is at the parrot level
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 related
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 that
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!)
--
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!?
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
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.
But
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.
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 have
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 Back;
still
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 mailing see my point?
It does not work
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 sure
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
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! Dial
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 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.
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?)
We can also
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 incisive
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
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).
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 variable
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
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
*)
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 ought
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
__
Do
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
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.
Languages are only supposed to expose
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 from a python compiler (e.g.) and executing
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 from a python compiler (e.g.) and executing
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 first general purpose vm for dynamic languages
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 understand what the
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 for
[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, stating that at some point in
any
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
(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
Brent Dax wrote:
use Fcntl qw(:seek);
seek DATA, 0, SEEK_SET;
@code = DATA;
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
about this issue? ;-)
--
John Porter
A word spoken in the mind will reach its own level in the objective truth.
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., thank you for supplying the proportion.
But it's
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.
--
John Porter
A word spoken
-world programming.
--
John Porter
Science class should not end in tragedy.
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 accidentally wrote a closure?
--
John Porter
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
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.
?
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 the more general case.)
--
John Porter
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
= substr( $s, 10, 15 ),
@z = @a[5..8,13];
etc.
--
John Porter
David L. Nicol wrote:
No, that does not work:
Right; I misunderstood what was wanted.
--
John Porter
Sterin, Ilya wrote:
Don't really know which would be more helpful, since I first need to find a
scenerio where I would use this facility, then what result would I expect
once the shortest list runs out.
Let us ask the PDL folks.
In fact, I'm quite sure this has been done already.
--
John
of hashes or arrays:
for my @a ( @foo, @bar ) { ...
for my %h ( %foo, %bar ) { ...
--
John Porter
] : $_-[1]\n;
}
--
John Porter
, @argset2 ) {
quux;
But I'm not convinced of the utility of this over using
scalar references.
--
John Porter
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
for, what hash refs
stringify to.
Um, one pragma.
--
John Porter
[EMAIL PROTECTED] wrote:
...just made them a convenience for identifying type errors...
I.e. type-safe macros.
--
John Porter
Matt Youell wrote:
The terminology was new to me, however.
I made it up.
--
John Porter
, and *can't* have it
except under certain rather strict constraints, e.g. when all
players are playing by the Class::Struct rules, or some other
more elaborate alternative.
--
John Porter
to do this.
It actually is very applicable in programming Frame systems,
which are a kind of souped-up semantic network thing,
used a lot in knowledgebases.
--
John Porter
Michael G Schwern wrote:
my package Foo {
sub bar { ... }
}
Well... package is a magic perl5-inducing keyword in perl6, right?
Maybe namespace is the way to go.
--
John Porter
:
...
my $obj = Class::Object-new;
...
No, that's not an inner class. Man, you think Class::Object
is the answer to everything! (Not that it ain't cool...)
--
John Porter
by inheritance,
and (nested) namespace scoping. I think there's been plenty of
call for the former in Perl6; the latter would be pretty nice too.
--
John Porter
on.
--
John Porter
this could be conflated with normal labels.
--
John Porter
1 - 100 of 449 matches
Mail list logo
