Re: pull put (Was: Angle quotes and pointy brackets)
Dan Brian writes: If there's a willingness to rename shift/unshift, why not consider going a bit further (and offend shell heritage) to note that pull/put aren't really linguistically opposed either (unlike push/pull). Why not rename pop to pull, and use something like put/take for shift/unshift? Having push and pull operate on opposite ends of an array strikes me as more confusing than even shift. When it comes to adding and removing elements, shouldn't there be semantic opposition for functions that operate on the same end? I don't think that's a good time. It kills the array-as-stack idiom, which, well, everybody uses all the time. I don't mind the linguistic nonopposition of pull/put. The main thing I don't like is the alliteration between push/pop. That makes for very difficult mnemonics. Obviously, the CS-literate can just remember that they're the nonstack ops, but many Perlers are Shellers and Adminers, without being CSers. I've actually been happy with shift/unshift. But what we'd really like to do is: given the user knows what push/pop do, what would they *guess* to mean shift (I tend to think that this is a very good technique for naming). And, well, I'm thinking pull. So it's a toss-up between shift/unshift and put/pull. Luke
Re: [perl #32829] [PATCH] dynamic evaluation of PAST
Bernhard Schmalhofer (via RT) wrote: Hi, this patch adds support for dynamic evaluation of 'Parrot abstract syntax tree As Simple Text'. This was done be implementing the C-function 'ast_compile_past'. Great, thanks. Simple examples for dynamic executable PAST are in t/pmc/eval.t. The toplevel node needs to be the new node 'PCC_Sub'. The node 'Py_Module' can't be used, because it sets the pragma 'P_MAIN', which puts an 'end' opcode at the end of the generated bytecode. Using 'Function' as toplevel node would make much more sense, but I don't know wether 'Function' is Python specific. I don't know yet, But if it is, it should read PyFunc* CU, Bernhard Thanks, applied. leo
MMD: more implications
Given a multi sub declaration a la S13:
multi sub *infix:- (MyInt $left, int $right) {mysub($left, $right)}
multi sub *infix:- (int $left, MyInt $right) {myrsub($right, $left)}
The first one would create a MMD function variant of
sub_p_p_ior Pleft.sub(Iright, Pdest)
or Pdest = Pleft.sub(Iright)
ok so far. The PMC type for the natural int is currently just zero.
But it could be less hackish, if we just reserve three distinct type
numbers for the namespace of these natural types.
The second one is harder. We don't have an opcode
sub_p_i_p
directly. But with the method call syntax the assembler could generate,
it would boild down to:
P_int_namespace.sub(Pright, Pdest)
where the P_int_namespace is the placeholder class for the MMD lookup of
the natural int. Sounds doable too.
But what about an arbitrary user multi sub, e.g.:
multi sub *foo (MyInt $a, MyInt $b, int $c)
multi sub *foo (MyInt $a, int $b, MyInt $c)
The assembler can create a prototyped call to a MMD foo function:
set I0, 1 # prototyped
set I1, 1 # 1 I arg
set I2, 0 # 0 S
set I3, 2 # 2 P args
set I4, 0 # 0 N
call_MMD_3 foo # ???
or a method call on the first arg. But whatever we do, the function
signature at the PASM level is the same for the first foo and the
second one. We have lost the order of arguments, which is essential to
find the appropriate MMD function or method.
Comments?
leo
Re: Angle quotes and pointy brackets
On Thursday, December 2, 2004, 10:08:31 AM, you (mailto:[EMAIL PROTECTED]) wrote: On Tue, 30 Nov 2004, Austin Hastings wrote: How about just having C system() return a clever object with .output and .err methods? interesting... Michele Prior art of this on Windows... http://msdn.microsoft.com/library/en-us/script56/html/wslrfExecMethod.asp (the respective properties on the returned WshScriptExec instance being .StdOut and .StdErr.) -- Richard mailto:[EMAIL PROTECTED]
Re: MMD: more implications
General thoughts on the proposal to replace VTABLES with methods: 1) Anything that is unary (i.e., contains exactly or one argument) is not affected by MMD. There is no need to replace any such methods. 2) While I don't see Python translators using a sin opcode, I can see the implementation of Math.sin doing a VTABLE_sin(INTERP,value). 3) My biggest problem with the runtime introducing methods is that language semantics vary. Here's a concrete example: both Ruby and Python have methods named index on string. Ruby returns Cnil if not found. Python throws Cvalue_error if not found. String.replace may be an even better example. Ruby and Python's methods by this name don't mean the same thing or even have the same signature. - - - Overall, for any non-trivial method, I think we are looking at a double dispatch: first to the language specific wrapper, and then to the common code which backs it. There are advantages and disadvantages to making the dispatch methods the same. Ultimately, if they are the same, the names should be picked in a way that minimizes the possibility of collisions. If they differ, no such possibility exists. - Sam Ruby
Premature pessimization
This term came up in a recent discussion[1]. But I'd like to give this term a second meaning. During design considerations we (including me of course too) tend to discard or pessimize ideas early, because they look inefficient. Recent examples are e.g. - spilling - lexical (re-)fetching - method calls We have even some opcodes that work around the estimated bad effect of the operation. E.g. for attribute access: classoffset Ix, Pobj, attr getattribute Pattr, Pobj, Ix instead a plain and clear, single opcode: gettatribute Pattr, Pobj, attr We are thinking that the former is more efficient because we can cache the expensive hash lookup in the index CIx and do just integer math to access other attributes. (This is BTW problematic anyay, as the side effect of a getattribute could be a change to the class structure). Anyway, a second example is the indexed access of lexicals additionally to the named access. Again a premature pessimization with opcode support. Another one is the newsub opcode, invented to be able to create the subroutine object (and possibly the return continuation) outside of a loop, where the function is called. All of these pessimized operations have one common part: one or several costy lookups with a constant key. One possible solution is inline caching. A cache is of course kind of an optimization. OTOH when we know that we don't have to pay any runtime penalty for certain operations, possible solutions are again thinkable that would otherwise just be discarded as they seem to be expensive. I'll comment on inline caching in a second mail. leo [1] Michael Walter in Re: [CVS ci] opcode cleanup 1 . minus 177 opcodes I'm fully behind Dan's answer - first fix broken stuff, then optimize. OTOH when compilers already are choking on the source it seems that this kind of pessimization isn't really premature ;)
Inline caching
A cache, well caches things and speeds something up, and can be
considered as an optimization. OTOH, knowing that things can be
reasoable fast, can open the mind for possible solutions that would
otherwise be silently discarded as known to be slow.
I'm not proposing the usage of inline caching for all possible things
now, I'd like to present the idea.
1) What is an inline cache
Inline means that the cache becomes part of the code. This scheme is
usable in Parrot for prederefed runcores (Switch, CGP) and the JIT. The
possibly costy lookup of some resource is done at runtime once and then
the result is kept in the cache. Subsequent execution of that opcode
just returns the result. Sometimes the opcode is replaced by a different
one e.g. one for calling a C (NCI Sub) method or a PASM method.
All the usage of inline caching contains some constant key.
2) Monomorphic inline cache (MIC)
a) Spilling
we have now, e.g.:
set Px, P31[2]# fetch spilled var #3
set P31[0], Iy, # store spilled var #0
The constant key is here the index in the spill array. The bytecode of
above is:
set_p_p_ki x, 31, 2
during predereferencing this can be replaced by
spill_fetch_p x, addr_of_elem_2_in_array_at_P31
This case doesn't even need an additional cache structure[¹]. The
address of the location can just be inlined im the opcode stream (as
long as the used spill array isn't one that moves during GC). The opcode
can already be in the bytecode, but it hasn't to be as long as it's
known that the access to P31 is a spill.
As with all caching there are potential operations that effect the
original data. A GC if a movable object is cached or running evaled
code. In this cases the cache is invalidated (possibly partly) by
restoring the original opcode that again does the lookup and caches the
result.
b) Lexical fetch and store
Thats' probably just the same as above.
3) Polymorphic inline cache (PIC)
I didn't really explain monomorphic above. So first, what is
polymorphic? We have e.g. a method call:
obj.foo()
which translates to bytecode
callmethodcc foo
with the object in P2. For any bytecode location in the source this
would translate to the inline cache version
callmethodcc cache
and the cache is as distinct PIC cache structure. The opcode actually
is something like:
obj = P2
cache = $1 # the PIC structure
S0 = cache-method # foo
if (obj-type == cache-type)
(cache-func)()
The object at that bytecode location could change (if e.g. an array of
objects is processed). So the first operation is to compare the object
type with the cached type. If types match the cached function pointer is
called. If not a lookup is done.
else {
cache-func = find_method(obj, meth)
cache-type = obj-type
...
The fast path should be used in 95% of the cases, states the literature.
A second if with a second (type, func) pair accounts for another ~4%.
For the mono-morphic case, the underlaying object doesn't change (or
there is none), so the type compare isn't needed.
More cachable opcodes:
- get, setattribute
- isa, does, can
- globals lookup
- dynamic subroutines especially multi sub
- array and hash lookups with constants
leo
[¹] modulo multi-threading issues
[perl #32868] [PATCH] target 'help' in 'parrot/docs/Makefile'
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #32868] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=32868 Hi, this patch adds a target 'help' to 'parrot/docs/Makefile'. A list of available targets should be printed. CU, Bernhard -- /* [EMAIL PROTECTED] */ GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail +++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++ docs_make_help_20041205.patch Description: Binary data
Re: MMD: more implications
Sam Ruby [EMAIL PROTECTED] wrote:
General thoughts on the proposal to replace VTABLES with methods:
1) Anything that is unary (i.e., contains exactly or one argument) is
not affected by MMD.
That's not quite true. We currently have just infix MMD dispatching on
left and right. That's just a specialized version. S13 has e.g.
multi method prefix:+ ...
multi method prefix:~ ...
when I translate that it boils down to:
obj.__get_number()
obj.__get_string()
(But there isn't much multi on such dispatch, that's right ;)
Anyway the current (2-dim) MMD system is really static. Overriding one
operator doesn't effect any class that inherits from it.
... There is no need to replace any such methods.
I haven't stated to get rid of these vtables. I've said that for
function dispatch these should be equivalent for plain PMCs and objects.
While we support above methods aready, we have an extra meta-class
(delegate) to dispatch correctly to the overloaded operator.
2) While I don't see Python translators using a sin opcode, I can see
the implementation of Math.sin doing a VTABLE_sin(INTERP,value).
Well, a vtable is a static construct. Having VTABLE_sin (and others)
forces all 100 (or whatever) PMCs and objects to have a vtable slot for
it.
3) My biggest problem with the runtime introducing methods is that
language semantics vary. Here's a concrete example: both Ruby and
Python have methods named index on string. Ruby returns Cnil if not
found. Python throws Cvalue_error if not found.
Fine. We have e.g. PyString isa String and RbString isa String.
METHOD index() {METHOD index() {
res = SUPER() res = SUPER()
if (res 0)if (res 0)
raise ... return RbNil
This is exactly what methods are for.
String.replace may be an even better example. Ruby and Python's
methods by this name don't mean the same thing or even have the same
signature.
Doesn't really matter.
Overall, for any non-trivial method, I think we are looking at a double
dispatch: first to the language specific wrapper
Mehods can call each other and parent methods.
... There are advantages and disadvantages to
making the dispatch methods the same.
Why?
... Ultimately, if they are the same,
the names should be picked in a way that minimizes the possibility of
collisions. If they differ, no such possibility exists.
Why? Px.foo() and Py.foo() can be totally different things, if the
classes of Px and Py differ.
- Sam Ruby
leo
Re: [perl #32868] [PATCH] target 'help' in 'parrot/docs/Makefile'
Thanks, applied. Bernhard Schmalhofer (via RT) wrote: # New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #32868] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=32868 Hi, this patch adds a target 'help' to 'parrot/docs/Makefile'. A list of available targets should be printed. CU, Bernhard
Re: Required whitespace issues.
Larry Wall wrote: On Sat, Dec 04, 2004 at 08:55:00PM -0600, Rod Adams wrote: : $x ==$foo; # $x == $foo; $x = =$foo; : @x ==$foo; # @x = =$foo; @x == $foo; : $x//=$foo; # $x // =$foo; $x //= $foo; : [EMAIL PROTECTED]; # $x ** [EMAIL PROTECTED]; $x **= @y; In each of those cases the longest-token rule comes into effect. That's not only consistent, but standard CompSci for the last 30 years or so. The only person who will get burned on those is someone who insists on *not* putting whitespace in front of unary = when it would be ambiguous. I have negative sympathy for such people. Well said! Although I by no means dispute that longest token rule is a long term standard in language design, I will claim that many programmers, including myself before this, are unaware of it. So I will now change my concerns to: The longest-token rule needs to be mentioned in S03, and explained in a future perlop.pod. -- Rod Adams
[perl #27304] [PATCH] move libnci.def out of root directory
Can we get a ruling on this? I tend to agree with the statement Random build files do not belong in the root directory. The patch has been un-ACK'd for nine months at the moment. [EMAIL PROTECTED] - Tue Mar 02 03:49:32 2004]: Steps: (1) move ./libnci.def to ./src/libnci.def (2) apply patch Patch updates ./config/gen/makefiles/root.in and ./MANIFEST with the new location. Why? Random build files do not belong in the root directory. Why src/? libnci.def is used to make a libnci.dll from src/nci_test.c, so src/ seemed an appropriate place to put it. Knocking out bit rot, Mitchell
Re: pull put
RA == Rod Adams [EMAIL PROTECTED] writes: RA Brent 'Dax' Royal-Gordon wrote: Smylers [EMAIL PROTECTED] wrote: Yes. Cunshift is a terrible name; when teaching Perl I feel embarrassed on introducing it. Cunshift's only virtue, IMHO, is that it's clearly the inverse of Cshift. But I think the spelling and aural relationship between Cpush, Cpop, Cpull, and Cput is clear enough to negate that. But then, I'm a little biased. RA Except that push and pull are logical opposites linguistically, but RA not in standard CS parlance. could be very confusing. RA There's a possibility of using Cenq and Cdeq for enqueue/dequeue, RA except that Cdeq == Cpop in standard implementations. RA So Cenq and Cshift? yeck. what about get/put for queue stuff? they don't conflict with push/pop/(un)shift so we can keep them. they would be synonyms for shift/push on arrays but do the right thing for queues and other unlimited things. and get/put are also an historical pair of computer terms that are well known (pl/i and others). and they are nice and short too so they make huffman feel good. :) so you could use get/put on arrays or queues but only them on queues. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: pull put (Was: Angle quotes and pointy brackets)
If there's a willingness to rename shift/unshift, why not consider going a bit further (and offend shell heritage) to note that pull/put aren't really linguistically opposed either (unlike push/pull). Why not rename pop to pull, and use something like put/take for shift/unshift? That goes way beyond offending shell heritage. That actively opposes sixty years of computer science terminology setting push and pop in opposition. I'm not objecting to pop, but pull in opposition to push, on the other side of the array.
Re: continuation enhanced arcs
Leopold Toetsch [EMAIL PROTECTED] writes: Matt Fowles [EMAIL PROTECTED] wrote: Thanks for the clear explanation. I did not realize that S registers could switch pointers, that does make things a little harder. I have a recommendation for a possible hybrid solution. Incur the cost of spilling I,S,N registers heavily. Restore the state of P register. My conclusion was that with the copying approach I,S,N registers are unusable. But you only need to copy when the frame you're restoring is a full continuation (and, actually, if copy on write works at a per register level, copy on write might be the way to go). If it's a return continuation you can simply use the stored state. I'd submit that, in the vast majority of cases you're not going to be dealing with full continuations, and on the occasions when you are the programmer using them will be aware of the cost and will be willing to pay it.
[perl #32877] parrot build broken in Tru64, cc/ld confusion
# New Ticket Created by Jarkko Hietaniemi # Please include the string: [perl #32877] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=32877 I am pretty certain that parrot was building fine in Tru64 back in 2004/11/07 15:12:42 when I submitted a patch (directly to CVS) for jit/alpha/jit_emit.h to get alpha JITing to compile at all. Since then something has broken building parrot in Tru64. What happens is that dynclasses/build.pl attempts something called a partial link for the various Python-related objects, and the attempt fails because it tries to invoke ld with parameters meant exclusively for the native cc (or the C++ compiler cxx): ld -std -D_INTRINSICS -fprm d -ieee -I/p/include -DLANGUAGE_C -pthread -g -DHAS_JIT -DALPHA-L/p/lib -shared -expect_unresolved * -O4 -msym -std -s -L/p/lib ../src/extend.o -o python_group.so lib-python_group.o pybuiltin.o pyobject.o pyboolean.o pyclass.o pycomplex.o pydict.o pyfloat.o pyfunc.o pygen.o pyint.o pylist.o pylong.o pymodule.o pynone.o pytype.o pystring.o pytuple.o ld: Badly formed hex number: -fprm ld: Usage: ld [options] file [...] partial link python_group.so failed (256) If ld in the above is replaced with cc, things work fine. I don't know where to start fixing this since the config/init/hints/dec_osf.pl hasn't change since April, and the config/gen/makefiles/dynclasses_pl.in (which is the source of dynclasses/build.pl, which is the one that issues the mistaken ld command) hasn't change since 2004/11/07 in any obvious ways. -- Jarkko Hietaniemi [EMAIL PROTECTED] http://www.iki.fi/jhi/ There is this special biologist word we use for 'stable'. It is 'dead'. -- Jack Cohen
Re: pull put (Was: Angle quotes and pointy brackets)
Dan Brian writes: Having push and pull operate on opposite ends of an array strikes me as more confusing than even shift. It makes good sense to me -- if we're trying to move a piano from you to me then either you can push or your end or I can pull on my end: we're operating on different ends of it, but the effect in both cases is moving in one direction. Now instead of a piano imagine one of those conveyor belts that you get at supermarket checkouts: you push your goods on one-end, and the cashier pulls them off the other. When the cashier pulls one item off that unbreaks the light beam to the sensor, which triggers the motor, and all the other items get pulled along too, moving one place along. Smylers
Re: specifying the key Type for a Hash
Larry Wall writes: But pretty much every time I've introduced synonyms into Perl I've come to regret it. But hey, if I introduce *different* synonyms this time, does that count as making a new mistake? No! Avoid synonyms. They're initially tempting, because then everybody gets to pick the one he/she wants to use, but then it turns out you need to learn all of them so as to read other people's code, and that's worse than not having them at all. 'MySQL' is riddled with them, and they're most inconvenient! Smylers
MakeMaker Test::More repository now on svn.schwern.org
The repositories for Test-Simple and ExtUtils-MakeMaker [1] have moved to svn.schwern.org. [2] Web DAV http://svn.schwern.org/svn/CPAN/ Anon SVNsvn://svn.schwern.org/CPAN/ WebSVN http://svn.schwern.org/websvn/ The web address might change to cut out the svn bit, I dunno. And it might jump to another server again, I dunno. And I'm not entirely happy with WebSVN... Everything is as stable as ever. [1] And as I work on more modules they'll get moved from CVS to there. [2] Which at the moment is just an alias to mungus.schwern.org. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ It's Crack Cocaine time!
Re: continuation enhanced arcs
Luke Palmer [EMAIL PROTECTED] writes: Piers Cawley writes: I'd submit that, in the vast majority of cases you're not going to be dealing with full continuations, and on the occasions when you are the programmer using them will be aware of the cost and will be willing to pay it. Yeah probably. Except the problem isn't the cost. The problem is the semantics. If you copy the registers, then when you invoke the continuation, their *values* restore to what they were when you made the continuation. These are not proper semantics, and would result in subtle, incorrect infinite loops. PMCs don't relocate, so the values you're restoring are simply the addresses of said PMCs. The Numeric registers are value registers anyway so no problem there (since there's no way of making a pointer to the contents of such a register AFAICT). I'm not sure about string registers. And anyway, copying is how it used to work, and work it did, albeit slowly.
Re: Parrot Strong typing
On Dec-01, Dan Sugalski wrote: C, for example, is weakly typed. That is, while you tell the system that a variable is one thing or another (an int, or a float), you're perfectly welcome to treat it as another type. This is *especially* true of values you get to via pointers. For example, this snippet (and yes, it's a bit more explicit than it needs to be. Cope, you pedants :): char foo[4] = abcd; printf(%i, *(int *)foo[0]); tells the C compiler that foo is a 4 character string with the value abcd, but in the next statement we get a pointer to the start of the string, tell the compiler No, really, this is a pointer to an int. Really! and then dereference it as if the string abcd really *was* an integer. If C were strongly typed you couldn't do that. A wholly off-topic comment about how to make use of this: When running gdb on a C (or better, STL-happy C++) program, it's nice to be able to set conditional breakpoints. b myfile.c:328 cond 1 somevar == 17 but gdb can often get confused or very slow if you try to do something similar with a char* value: cond 1 strcmp(mystring,badness) == 0 It goes crazy making a function call every time that breakpoint is reached. I can get gdb to segfault this way without too much trouble. So instead, use this trick: cond 1 *(int*)mystring == *(int*)badness and it'll go back to doing a simple integer comparison. And it's very fast about that. Note that because you're using a probably 32-bit integer, that isn't really looking at the whole string; it'll have exactly the same effect if you say cond 1 *(int*)mystring == *(int*)badn I often use this in combination with std::basic_string types in C++, since the templatized types and other implementation-dependent weirdnesses end up making things much harder than if you were using simple char*'s. So it would look something like: cond 1 *(int*)mystring.data() == *(int*)badn Or maybe it's slightly safer to do this, I dunno: cond 1 *(int*)mystring.c_str() == *(int*)badn Sorry for the diversion. Um... if I had to say something on-topic, I'd point out that Perl's type system isn't complete (not THAT strong), since there some corners in the language where you can sneak around it. pack(p), some system calls, and other things I can't think of. But maybe the very oddness of those things is evidence that Perl does indeed have a strong type system. (Strong in the technical, not comparative, sense.) Not that anyone seems to be able to agree on the exact definition of strong typing.
Re: Premature pessimization
Leopold Toetsch writes: This term came up in a recent discussion[1]. But I'd like to give this term a second meaning. Except what you're talking about here is premature *optimzation*. You're expecting certain forms of the opcodes to be slow (that's the pessimization part), but then you're acutally using opcodes that you think can be made faster. This is a classic Knuth example. If I were Dan, here's what I'd say (though perhaps I'd say it in somewhat a different tone :-): don't worry about it. Inline caching is just another optimization. We need to be feature complete. Leo, speed is never off your mind, so we can be fairly certain that we won't be making any decisions that are going to bite us speed-wise. Plus, at this point, we can change interfaces (when we go past feature complete into real-life benchmarked optimization). Yeah, the compilers will have to change, but really that's not a big issue. I've been writing compilers for parrot for a while, and stuff is always changing, and it usually means one or two lines of code for me if I designed well. And if you really feel like you need to optimize something, look into the lexicals-as-registers idea you had to fix continuation semantics. Then you can work under the guise of fixing something broken. Luke During design considerations we (including me of course too) tend to discard or pessimize ideas early, because they look inefficient. Recent examples are e.g. - spilling - lexical (re-)fetching - method calls We have even some opcodes that work around the estimated bad effect of the operation. E.g. for attribute access: classoffset Ix, Pobj, attr getattribute Pattr, Pobj, Ix instead a plain and clear, single opcode: gettatribute Pattr, Pobj, attr We are thinking that the former is more efficient because we can cache the expensive hash lookup in the index CIx and do just integer math to access other attributes. (This is BTW problematic anyay, as the side effect of a getattribute could be a change to the class structure). Anyway, a second example is the indexed access of lexicals additionally to the named access. Again a premature pessimization with opcode support. Another one is the newsub opcode, invented to be able to create the subroutine object (and possibly the return continuation) outside of a loop, where the function is called. All of these pessimized operations have one common part: one or several costy lookups with a constant key. One possible solution is inline caching. A cache is of course kind of an optimization. OTOH when we know that we don't have to pay any runtime penalty for certain operations, possible solutions are again thinkable that would otherwise just be discarded as they seem to be expensive. I'll comment on inline caching in a second mail. leo [1] Michael Walter in Re: [CVS ci] opcode cleanup 1 . minus 177 opcodes I'm fully behind Dan's answer - first fix broken stuff, then optimize. OTOH when compilers already are choking on the source it seems that this kind of pessimization isn't really premature ;)
Re: Premature pessimization
On Sun, 5 Dec 2004 11:46:24 -0700, Luke Palmer [EMAIL PROTECTED] wrote: Leopold Toetsch writes: This term came up in a recent discussion[1]. But I'd like to give this term a second meaning. Except what you're talking about here is premature *optimzation*. Yes, indeed. Cheers, Michael
Re: continuation enhanced arcs
Piers Cawley writes: I'd submit that, in the vast majority of cases you're not going to be dealing with full continuations, and on the occasions when you are the programmer using them will be aware of the cost and will be willing to pay it. Yeah probably. Except the problem isn't the cost. The problem is the semantics. If you copy the registers, then when you invoke the continuation, their *values* restore to what they were when you made the continuation. These are not proper semantics, and would result in subtle, incorrect infinite loops. Luke
Re: Premature pessimization
On Sun, 5 Dec 2004 11:46:24 -0700, Luke Palmer [EMAIL PROTECTED] wrote: Leopold Toetsch writes: This term came up in a recent discussion[1]. But I'd like to give this term a second meaning. Except what you're talking about here is premature *optimzation*. You're expecting certain forms of the opcodes to be slow (that's the pessimization part), but then you're acutally using opcodes that you think can be made faster. This is a classic Knuth example. So the sequence of using classoffset/getattribute is a _feature_ necessary for completeness, rather than a pessimization to compensate for the belief that not explicitly caching would be hopelessly slow? Ahh. I'm learning much. :) Ashley Winters
RE: Premature pessimization
can you unsubscribe me asap rgds venkat -Original Message- From: Ashley Winters [mailto:[EMAIL PROTECTED] Sent: Monday, December 06, 2004 7:19 AM To: Luke Palmer Cc: Leopold Toetsch; Perl 6 Internals Subject: Re: Premature pessimization On Sun, 5 Dec 2004 11:46:24 -0700, Luke Palmer [EMAIL PROTECTED] wrote: Leopold Toetsch writes: This term came up in a recent discussion[1]. But I'd like to give this term a second meaning. Except what you're talking about here is premature *optimzation*. You're expecting certain forms of the opcodes to be slow (that's the pessimization part), but then you're acutally using opcodes that you think can be made faster. This is a classic Knuth example. So the sequence of using classoffset/getattribute is a _feature_ necessary for completeness, rather than a pessimization to compensate for the belief that not explicitly caching would be hopelessly slow? Ahh. I'm learning much. :) Ashley Winters
Re: Phalanx update
On 2004-12-02, Andy Lester [EMAIL PROTECTED] wrote: I've reorganized all the trees in http://svn.perl.org/phalanx. A description of how things should be is at http://svn.perl.org/phalanx/structure.pod. I think I missed something. This clearly has something to do with SVN hosting and the Phalanx project, but what's the big picture here? Mark -- http://mark.stosberg.com/
Re: Phalanx update
On Mon, Dec 06, 2004 at 02:27:47AM +, Mark Stosberg ([EMAIL PROTECTED]) wrote: On 2004-12-02, Andy Lester [EMAIL PROTECTED] wrote: I've reorganized all the trees in http://svn.perl.org/phalanx. A description of how things should be is at http://svn.perl.org/phalanx/structure.pod. I think I missed something. This clearly has something to do with SVN hosting and the Phalanx project, but what's the big picture here? PMers who are Phalanxing modules can use svn.perl.org to host their code so that all can collaborate easily. xoxo, andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: pull put (Was: Angle quotes and pointy brackets)
It makes good sense to me -- if we're trying to move a piano from you to me then either you can push or your end or I can pull on my end: we're operating on different ends of it, but the effect in both cases is moving in one direction. As a mnemonic for remembering which side push/pull operate on, I agree. (A stalled car etc.) It would be nice if the corresponding functions could similarly be opposed without the potential confusion for beginners, but I realize that may not be possible, and your example is at least convincing that it's better than shift/unshift.
