Re: Premature pessimization

[Sam Ruby]

Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
Leopold Toetsch wrote:
"correct". I've discovered and analysed the problem with continuations.
I've made a proposal to fix that. No one has said that it's technically
wrong or couldn't work. It seems you are liking the idea, but Dan
doesn't. Now what?

I would suggest focusing on one issue at a time and starting with
writing a test case.

But, overall, it is clear that you are frustrated.
... a bit by the lack of progress that can be achieved to e.g. fix
broken continuation behavior. But not much ;)
My philosophy is simple: things without test cases tend not not get 
fixed, and when fixed, tend not to stay fixed.

... It show when you
give responses like "Doesn't really matter" when people like me ask
questions about your proposals.  That, in turn, makes people like me
frustrated.
Well, you worried about different classes having identical method names,
but the methods do different things. I asked why this is a problem. I
gave an example. Here is one more:
  obj."__set_integer_native"(10)
does 2 totally different things for arrays (set array size) or for
scalars (assign value 10).
I am worried about Parrot trying to establish common public names for 
common functions.  Many of the examples you gave did not include the 
prerequisite double underscores.  For example: "sub", "imag", "eof". 
These names are not likely to have a commmon behavior across all languages.

Re: VTABLES... I disagree with you on this one.  Prematurely mapping an
operation to a string is a premature pessimization.
Except that we are doing that already. Please read through
classes/delegate.c. The problem is that this scheme doesn't work for
MMD of real objects.
I don't know enough to have an informed opinion yet on MMD.  But 
__set_integer_native is not a MMD operation.  It already is efficiently 
dispatched to the correct method.  What do we benefit from the premature 
pessimisation of mapping this to a string?

... Add to that the
fact that such names can conflict with usages by languages of this
runtime.
Parrots method names (two leading underscores + vtable name) are
reserved. And again, when two distinct clases use the same method name
this is no conflict at all. Issues with classes in an inheritance chain
are easily avoided by following that convention.
Again, my point is that the examples need to follow that convention. 
Without exception.

... Overall, the design of the opcodes and PMC layout should focus
on trying to retain as much information as possible.
Nothing get lost. Visible opcodes don't change. An example
 .sub m
  $P0 = newclass "Foo"
  $I0 = find_type "Foo"
  .local pmc obj
  obj = new $I0
  obj = 5
 .end
running that snippet gives:
Can't find method '__set_integer_native' for object 'Foo'.
The vtable method set_integer_native clearly maps to a real method that
can be either inherited or be provided by the user. This doesn't work
for MMD functions.
Again, set_integer_native is not an MMD function?
Re: continuations... frankly, I'm hoping that a solution emerges that
doesn't involve significant reduction in functionallity.  I might be
misunderstanding you, but it sounds to me like you are proposing
ditching lexical pads.
No. I'm not ditching lexical pads at all. They are of course needed. The
top pad is in the registers. Outer pads are looked up as usual.
I guess I don't understand.  I guess it is time for a test case.  ;-)
How would the following work if the top pad is in registers?
  var = 1
  def g():
    global var
    var = 2
  print "before", var
  g()
  print "after", var
Such behavior is the default for perl5:
  my $var = 1;
  sub g {
    $var = 2;
  }
  print "before $var\n";
  g();
  print "after $var\n";
- Sam Ruby