where without type?
Consider:
my $foo of Num where { 0 = $^n 10 };
Is the following also valid?
my $foo where { 0 = $^n 10 };
Or does that have to be like this?
my $foo of Scalar where { 0 = $^n 10 };
And can $_ be used instead of $^n?
Juerd
Re: [perl #33963] read and readline opcodes don't mix
Matt Diephouse [EMAIL PROTECTED] wrote: $S0 = readline $P0 print $S0 $S1 = read $P0, 3 Mixing readline and read isn't really a good idea. Did you try to turn on/off buffering before changing read modes? See PIO.setbuf(). leo
Re: [perl #33962] readline returns one too many lines
Matt Diephouse [EMAIL PROTECTED] wrote: The readline opcode returns too many lines. Compare the following pir with `wc -l`. unless file goto END $S0 = readline file It needs (currently) a test for an empty string: unless $S0 goto END I didn't look at the code, if EOF is set correctly. leo
Re: [perl #33963] read and readline opcodes don't mix
On Fri, 28 Jan 2005 09:53:01 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: Matt Diephouse [EMAIL PROTECTED] wrote: $S0 = readline $P0 print $S0 $S1 = read $P0, 3 Mixing readline and read isn't really a good idea. Did you try to turn on/off buffering before changing read modes? See PIO.setbuf(). Regardless of whether or not it's a good idea, the documentation for read says it should work: Read up to N bytes from standard input stream If stream is linebuffered, will return at EOL, for files it will read MIN(MAX(avail, N), 65535) bytes. Warning: This is a quick hack. Unless I'm reading that incorrectly? -- matt diephouse http://matt.diephouse.com
Re: [perl #33962] readline returns one too many lines
On Fri, 28 Jan 2005 09:49:06 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: Matt Diephouse [EMAIL PROTECTED] wrote: The readline opcode returns too many lines. Compare the following pir with `wc -l`. unless file goto END $S0 = readline file It needs (currently) a test for an empty string: unless $S0 goto END I already use that workaround in some of my code, but that sorta defeats the purpose of testing the filehandle itself. The filehandle should become false after it returns the last line of the file - not the last line plus an empty string. -- matt diephouse http://matt.diephouse.com
Re: where without type?
Juerd writes:
Consider:
my $foo of Num where { 0 = $^n 10 };
Is the following also valid?
my $foo where { 0 = $^n 10 };
I don't see why not. The main place Cwhere will be useful is in
multimethods, and I see that as a reasonable shorthand:
multi sub foo(Bar $x, $y where { .data ~~ Bar });
Or does that have to be like this?
my $foo of Scalar where { 0 = $^n 10 };
And can $_ be used instead of $^n?
Of course it can. You know that.
Luke
Re: where without type?
Luke Palmer skribis 2005-01-28 9:31 (-0700): And can $_ be used instead of $^n? Of course it can. You know that. I do? Can't say I understand well when a topic is implicitly defined and when not. It's obvious for for-loops and given, but everything else is blurry to me. Juerd
lib/Make.pm obsolete?
Is there any reason to keep lib/Make.pm around? It was used by make.pl, but that was deleted more than a year ago. Grepping the parrot directory returns no occurrences of 'use Make;'. If it is deleted, #15988 (Make.pl might load the wrong Make.pm) can be closed. -- matt diephouse http://matt.diephouse.com
Re: where without type?
Juerd writes:
Luke Palmer skribis 2005-01-28 9:31 (-0700):
And can $_ be used instead of $^n?
Of course it can. You know that.
I do?
Can't say I understand well when a topic is implicitly defined and when
not. It's obvious for for-loops and given, but everything else is
blurry to me.
Okay, I'll explain then. If you use $_ inside a closure, then it is
assumed to mean an argument to that closure. If the closure isn't given
an argument (or the block is declared to have zero arguments at compile
time) then $_ defaults to the outer lexical $_, which fixes this
problem:
for @stuff {
if something() {
print; # prints the argument to if's block
}
}
I don't think it's the cleanest solution, but it works.
Luke
Re: Calling conventions, invocations, and suchlike things
At 5:04 PM -0500 1/18/05, Sam Ruby wrote: Dan Sugalski wrote: Hi folks. Welcome back! Parrot's got the interesting, and somewhat unfortunate, requirement of having to allow all subroutines behave as methods and all methods behave as subroutines. (This is a perl 5 thing, but we have to make it work) That is, an invokable PMC may be invoked as a method call and passed in an object, or as a plain subroutine and not have an object passed in. As far as perl 5 is concerned the object is the first parameter in the argument list, but for everyone else the object is a very distinct and separate thing. Python essentially has the same requirement, with a few twists. Specifically, methods come in be static, class, and regular flavors. But first, a simple example. Strings in python have a find method, so and can do the following: f = Parrot.find print f(r) Note that I referenced the method as an attribute, and then called it as a function. Mmm, syntax! :) Luckily it makes no difference to us at the parrot level. What that should translate to is something like: $P0 = find_method Parrot_string, find # Elided check for failed lookup and fallback to attribute fetch $P1 = make_bound_method(Parrot_string, $P0) $P1(r) Furthermore, the function remembers what object it is bound to. This is accomplished by VTABLE_find_method creating a new PyBoundMeth PMC which contains two references, one to the object, and one to the method. While a good idea, I think it's not the right way to handle this. Binding objects to methods to create invokable subs is going to be something we're going to need for a lot of the languages, so I think we'd be better served providing a general facility to do it rather than leaving it to each individual language designer to do it. Should save some work all around too. Static methods differ in that the object is not passed. How is this different from a subroutine, then? Class methods differ in that the object passed is actually the class of the object in question. I'm assuming this is different from just a method on the class somehow? Note: all this is determined by the callee. It is all transparent to the caller. This is the part I'm not so sure about. It looks like, rather than having two sides (caller and calle) we have three, caller, callee, and the code that fetches the invokable in the first place. I fully agree that the caller shouldn't know about this stuff, since it may well have been handed the invokable thing as part of a function call or pulled it out of a variable or something. I don't think the callee should have to know anything special here, though -- it doesn't seem at all unreasonable to have the callee *not* have to do anything special, nor play any magic games. (And I think I'd be a bit peeved if I was writing code which passed in object A as the object being invoked on, but the method decided it wanted to use object B instead) This is especially true in a mixed-language environment when you've got a class with methods written in different languages -- setting up any conventions that'll actually be followed seems like an exercise in futility. :) That leaves the code that actually fetches the invokable thing in the first place, and that seems like the right place for this to happen. The language the code is written in knows what should happen based on what it gets back when querying the object, so as long as we provide a standard means to do all the binding stuff, we shoul dbe fine. First, observe that I don't have any control over the exception that is raised when a method is not found (fix: raise the exception within find_method). Right. There's going to be one generic method-not-found exception -- there really has to be only one, otherwise we're going to run into all sorts of cross-language problems. Exception unification (and, more likely, aliasing) is going to be one of the tricky issues. My one minor request here is P2 be made available on entry to the invoked method. This would remove some special case logic for me requiring the use of interpinfo. I don't expect any guarantees that this is preserved or restored across sub calls. The one thing that leaving it in the interpreter structure and not explicitly passing it in gets us is we get notice if its actually extracted and used. Which is going to be fairly common, so I'm not sure what it buys us. I think we'll leave things as-is, but I'm not sure for how much longer. Not having objects handle their own method dispatch is less clear-cut, but I do have some reasons, so here they are. Just be aware that in order to preserve Python semantics, find_method will need to return a bound method. That can't happen. find_method has to return an unbound method, since there are just too many cases where that's what we need. If the method then needs to be bound then the fetching code can do the binding. This involves creating an object on the heap,
Re: Calling conventions, invocations, and suchlike things
Dan Sugalski wrote: At 5:04 PM -0500 1/18/05, Sam Ruby wrote: Dan Sugalski wrote: Hi folks. Welcome back! Parrot's got the interesting, and somewhat unfortunate, requirement of having to allow all subroutines behave as methods and all methods behave as subroutines. (This is a perl 5 thing, but we have to make it work) That is, an invokable PMC may be invoked as a method call and passed in an object, or as a plain subroutine and not have an object passed in. As far as perl 5 is concerned the object is the first parameter in the argument list, but for everyone else the object is a very distinct and separate thing. Python essentially has the same requirement, with a few twists. Specifically, methods come in be static, class, and regular flavors. But first, a simple example. Strings in python have a find method, so and can do the following: f = Parrot.find print f(r) Note that I referenced the method as an attribute, and then called it as a function. Mmm, syntax! :) Luckily it makes no difference to us at the parrot level. What that should translate to is something like: $P0 = find_method Parrot_string, find # Elided check for failed lookup and fallback to attribute fetch $P1 = make_bound_method(Parrot_string, $P0) $P1(r) This will be a recurring theme in my replies. Any thing which presumes a bit of knowledge at compile time will ultimately not work. Consider the following: class c: find = 7 def f(x): return x.find print f(c()) print f(Parrot)(r) Now, what should the code for function f look like? The only reasonable answer is something along the lines of: getattribute $P0, P5, 'find' This has to work. In both of the two calls to f(). Furthermore, the function remembers what object it is bound to. This is accomplished by VTABLE_find_method creating a new PyBoundMeth PMC which contains two references, one to the object, and one to the method. While a good idea, I think it's not the right way to handle this. Binding objects to methods to create invokable subs is going to be something we're going to need for a lot of the languages, so I think we'd be better served providing a general facility to do it rather than leaving it to each individual language designer to do it. Should save some work all around too. This would not be necessary, but the current implementation of the callmethodcc opcode unfortunately decouples the find_method (which is subject to the not at compile time restrictions alluded to above), and invoke. If these weren't decoupled (i.e., there was a VTABLE_find_method or equivalent entry), then this would not be necessary. Static methods differ in that the object is not passed. How is this different from a subroutine, then? From a callee-perspective: not at all. What is important to note is that from a caller-perspective, they will invoke such subroutines with the callmethcc opcode. Class methods differ in that the object passed is actually the class of the object in question. I'm assuming this is different from just a method on the class somehow? From a callee perspective, this appears to be a method on the instance. Note: all this is determined by the callee. It is all transparent to the caller. This is the part I'm not so sure about. It looks like, rather than having two sides (caller and calle) we have three, caller, callee, and the code that fetches the invokable in the first place. I fully agree that the caller shouldn't know about this stuff, since it may well have been handed the invokable thing as part of a function call or pulled it out of a variable or something. I don't think the callee should have to know anything special here, though -- it doesn't seem at all unreasonable to have the callee *not* have to do anything special, nor play any magic games. (And I think I'd be a bit peeved if I was writing code which passed in object A as the object being invoked on, but the method decided it wanted to use object B instead) This is especially true in a mixed-language environment when you've got a class with methods written in different languages -- setting up any conventions that'll actually be followed seems like an exercise in futility. :) Perhaps you might not find Python to your liking. That's OK. But the more general question is whether or not Parrot will implement the above as a policy, and thereby preclude langages like Python from being implemented on top of Parrot. That leaves the code that actually fetches the invokable thing in the first place, and that seems like the right place for this to happen. The language the code is written in knows what should happen based on what it gets back when querying the object, so as long as we provide a standard means to do all the binding stuff, we shoul dbe fine. I'm not sure what you mean by the code that actually fetches the invokable thing in this instance. If you mean an at compile time translation approach like you alluded above,
Re: Calling conventions, invocations, and suchlike things
Luke Palmer wrote: Sam Ruby writes: Mmm, syntax! :) Luckily it makes no difference to us at the parrot level. What that should translate to is something like: $P0 = find_method Parrot_string, find # Elided check for failed lookup and fallback to attribute fetch $P1 = make_bound_method(Parrot_string, $P0) $P1(r) This will be a recurring theme in my replies. Any thing which presumes a bit of knowledge at compile time will ultimately not work. Consider the following: class c: find = 7 def f(x): return x.find print f(c()) print f(Parrot)(r) Now, what should the code for function f look like? The only reasonable answer is something along the lines of: getattribute $P0, P5, 'find' I doubt that. All languages have different semantics, and we can't implement them all, because they are conflicting. You, as a compiler designer, have the opportunity to design things so that they work. And you definitely have to be clever if you're looking for language features that Parrot doesn't natively support. I disagree. As Dan once said, as long as we have a proper protocol that everyone can conform to, we should be OK. I don't care if Perl, Python, Ruby, TCL, and others each implement different semantics. I do care that we adopt a common protocol. The current set of VTABLE entries is a excellent first order approximation for the common protocol. My first tendency here is to echo all attributes as methods (like Perl 6 does), and then always call the method when you see a dot. ParrotString has a find method, and it knows how to curry itself. Instances of c also have a find method, and that method always returns 7. The distinction between attributes and methods is a bit subtle. Any object may implement the VTABLE_invoke method (or in Python terms, a __call__ method), so all attributes may already *BE* a method. But largely, I could change the current implementation of Python on Parrot to follow such a protocol in a matter of minutes. But my original comment (Any approach 'which presumes a bit of knowledge at compile time will ultimately not work.') still stands. Although I agree that we should come up with a general, bare-bones object model that allows all of our current target languages to operate smoothly. Parrot's current model makes far too many assumptions. But that doesn't mean that anything you're trying to do is impossible; it just means it's harder. I don't believe that Parrot should impose an object model. I return to Dan's as long as we have a proper protocol that everyone can conform to, we should be OK. - Sam Ruby
Re: Calling conventions, invocations, and suchlike things
Sam Ruby writes: Mmm, syntax! :) Luckily it makes no difference to us at the parrot level. What that should translate to is something like: $P0 = find_method Parrot_string, find # Elided check for failed lookup and fallback to attribute fetch $P1 = make_bound_method(Parrot_string, $P0) $P1(r) This will be a recurring theme in my replies. Any thing which presumes a bit of knowledge at compile time will ultimately not work. Consider the following: class c: find = 7 def f(x): return x.find print f(c()) print f(Parrot)(r) Now, what should the code for function f look like? The only reasonable answer is something along the lines of: getattribute $P0, P5, 'find' I doubt that. All languages have different semantics, and we can't implement them all, because they are conflicting. You, as a compiler designer, have the opportunity to design things so that they work. And you definitely have to be clever if you're looking for language features that Parrot doesn't natively support. My first tendency here is to echo all attributes as methods (like Perl 6 does), and then always call the method when you see a dot. ParrotString has a find method, and it knows how to curry itself. Instances of c also have a find method, and that method always returns 7. Although I agree that we should come up with a general, bare-bones object model that allows all of our current target languages to operate smoothly. Parrot's current model makes far too many assumptions. But that doesn't mean that anything you're trying to do is impossible; it just means it's harder. Luke
Re: Calling conventions, invocations, and suchlike things
Sam Ruby wrote:
Now, what should the code for function f look like? The only
reasonable answer is something along the lines of:
getattribute $P0, P5, 'find'
I doubt that. All languages have different semantics, and we can't
implement them all, because they are conflicting. You, as a compiler
designer, have the opportunity to design things so that they work. And
you definitely have to be clever if you're looking for language features
that Parrot doesn't natively support.
I disagree. As Dan once said, as long as we have a proper protocol
that everyone can conform to, we should be OK.
I don't care if Perl, Python, Ruby, TCL, and others each implement
different semantics. I do care that we adopt a common protocol.
The current set of VTABLE entries is a excellent first order
approximation for the common protocol.
In case that isn't perfectly clear, let me illustrate this with actual
source code:
inline op getattribute(out PMC, in PMC, in STR) :object_classes {
$1 = VTABLE_get_attr_str(interpreter, $2, $3);
goto NEXT();
}
Note that the opcode doesn't actually implement any semantics. It
merely delegates the request to the $2 PMC.
Languages which share semantics for this operation can chose to inherit
a common implementation. Those with unique semantics can override this
(or can find other languages with similar requirements and pool their
implementation).
It seems rather likely to me that this was the original intent to
providing a VTABLE_get_attr_str VTABLE entry in the first place.
This seems to me to be a rather good design pattern.
- Sam Ruby
