Re: Translitteration and combining strings and array references
On Fri, Oct 14, 2005 at 05:17:48PM -0700, Larry Wall wrote: > form of tr/// should always use lists, with a helper function to > translate "a..z" to a list and also carp about the fact that it will > break under Unicode. :-) And EBCDIC. The dinosaurs are not extinct yet. I guess that they are trying to out-live Perl 4. Nicholas Clark
Re: Translitteration and combining strings and array references
[EMAIL PROTECTED] (Larry Wall) writes:
> : my %transtable;
> : for %intable.kv -> $k, $v {
> : # $k is stringified by the => operator.
>
> Interesting comment. I wonder if it's true.
That was my attempt to explain the observations I did. Clearly I put
the blame the wrong place.
> : my @ks = expand($k);
> : my @vs = $v.isa(Str) ?? expand($v) !! expand_arrayref($v);
>
> Nit: that probably wants to be an MMD dispatch eventually so we can handle
> things that aren't quite Str or Array.
Right, I'm going to fix that.
>
> : [EMAIL PROTECTED] = @vs;
> : }
> :
> : [~] map { %transtable{$_} // $_ } $self.split('');
> : }
[...]
> Also, if we go with the syntactic definition of named args we've
> been discussing lately on p6l, we'll need to put an extra set of
> parens around the pair list, or prefix with "<==" to force it into
> the list zone, or pass inside [...]. (And for syntactic named args,
> a => probably *should* be enforcing string context on the key.)
Ok, r7622 changed something about how the method gets called and that
broke most of the examples in S05. I'll probally turn my attention
somewhere else until I have a more stable understanding of what
happens.
--
Peter Makholm | I laugh in the face of danger. Then I hide until
[EMAIL PROTECTED] | it goes away
http://hacking.dk | -- Xander
'self' and .foo (was: Re: Re(vised): Proposal to make class method non-inheritable)
On Sat, Oct 15, 2005 at 09:49:30AM -0700, Larry Wall wrote: > On Sat, Oct 15, 2005 at 07:39:36PM +0300, wolverian wrote: > : IMHO just call it "self" (by default) and be done with it. :) > > Let it be so. Somewhat off-tangent: does this mean that .foo is always $_.foo? > Larry -- Ilmari Vacklin
Re: Standard library for perl6? (graphical primitives)
On Sat, 2005-10-15 at 12:45 -0500, Bryan Burgers wrote: > What I find exciting about parrot is that (it sounds like to me) > you'll be able to run a perl6 file anywhere that has parrot, much like > Java. I think what Markus is getting at is for there to be a way to > display graphics through parrot everywhere parrot runs as well. Yes, > different modules are extremely important, because the programmer > deserves a choice, but some modules run someplaces, others run other > places - it'd be a good thing to have the absolute bare essentials run > everywhere. I agree, but it's not an easy question: which bare essentials are those? How big is the screen on every device where Parrot runs? Is there hardware acceleration? Is there a text-mode console? Is there a framebuffer? How many colors? Is there a back buffer? What types of input devices are available? Does the platform have POSIX support? Does it have a MMU? Can it run a compiler from the program? Is there an existing graphics library on every platform we can use or will we have to write and maintain a superset of all graphics primitives we want to provide on every platform? Does the platform support tiling or overlapping windows? Does it manage resources automatically or leave that up to the programmer? -- c
Re: Standard library for perl6? (graphical primitives)
On 10/15/05, Luke Palmer <[EMAIL PROTECTED]> wrote: > On 10/14/05, Markus Laire <[EMAIL PROTECTED]> wrote: > > Perl does have CPAN, but the problem is that there are no standard > > modules, and so there can be several modules doing the same thing. > > And what is the problem with that? The problem may be that it doesn't work everywhere. What I find exciting about parrot is that (it sounds like to me) you'll be able to run a perl6 file anywhere that has parrot, much like Java. I think what Markus is getting at is for there to be a way to display graphics through parrot everywhere parrot runs as well. Yes, different modules are extremely important, because the programmer deserves a choice, but some modules run someplaces, others run other places - it'd be a good thing to have the absolute bare essentials run everywhere. Bryan
Re: Re(vised): Proposal to make class method non-inheritable
Larry,
On Oct 15, 2005, at 11:25 AM, Larry Wall wrote:
On Sat, Oct 15, 2005 at 10:34:34AM -0400, Stevan Little wrote:
: I think what bothers me most about this is that it seems there is no
: way to tell the difference between class methods and instance
: methods. That the distinction is only made when the body of the
: method does something which is is not supposed to do (method called
: with a class invocant attempts to access an instance variable, etc).
:
: This is one of the major problems that I have always had with Perl 5
: OO. That there is a very fuzzy fuzzy line between the
: responsibilities of a class and an instance.
But you haven't actually said why this is a problem. If you want to
know at compile time that a method must be called with an object that
has been instantiated, it seems to me that it's pretty easy to tell
99% of the time whether the method body has made reference to $?SELF
in some form or other. And if the compiler can determine that, why
should the user have to specify it?
I think it is a problem because they are two distinct areas of
responsibility. A class creates and manages instances, while an
object is the thing which the class creates. The object only manages
it's own data.
As for whether the compiler can tell the difference, I am not sure
you are correct here. Take this for instance:
class Foo {
method bar {
$?CLASS.baz();
}
}
What is &bar? A class method? or a instance method? Clearly $?CLASS
is valid inside instance methods, and surely you can call methods on
$?CLASS within instance methods. There is an ambiguity here.
One possible solution of course is that this method is both, that it
could basically be this (to use the old A12 syntax):
class Foo {
method bar (Class|Foo $f:) {
$?CLASS.baz();
}
}
I am fine with that personally.
My biggest concern is that we are able to fit the syntax into *a*
meta-model. As I said before, I don't have a problem scrapping the
current version and starting on v3.0, I enjoy writing and thinking
about these things, so you will get no resistance from me. However, I
want to be sure that I know what it needs to do, then I can determine
if I even need to re-write it or not.
: I can see the notion of "a class which is not yet instantiated",
this
: makes sense in many contexts. But I don't think that in order to
have
: this, we need to bring back this element of Perl 5 OO. I think we
can
: still have all the behaviors you have been describing, and still
keep
: classes and their instances as distinct entities.
Well sure, they're at least opposite ends of a continuum. But we
may usefully smudge the distinction in the middle unless you can show
actual damage from this.
I don't think there is actually damage, we just have methods which
can be called in either context. How to implement this is fairly
easy, so I am not worried about that. I am just not comfortable with
*all* methods being in this grey area.
And as you pointed out in your other message,
your notion of class is mostly hidden behind .meta in my scheme of
things anyway. And generally the compiler will know by inspection
whether the body is referring to the dynamic class through .meta, the
static class through $?CLASS, or the dynamic instance through $?SELF.
Yes, except in the case I show above, but then we can just use the
solution I show above.
(And yes, it bothers me that $?CLASS is static while $?SELF is
dynamic.
The latter is an abuse of the $? sigil, which ought to be reserved
for entities known to the compiler. Maybe we should rename $?SELF
to something that looks more dynamic. $*SELF is dynamic, but implies
global. Hmm, if $.foo() is really a self call, maybe we could make a
case for self being $$. Of course, there's never been any controversy
here about what to call "self", oh no... :-)
I don't even want to get into this debate, I am just the meta-monkey,
nothing more :)
Thanks,
Stevan
Re: Re(vised): Proposal to make class method non-inheritable
Larry, On Oct 15, 2005, at 11:25 AM, Larry Wall wrote: : >But we have to think a bit more about the notion of currying class : >objects into real objects, or something approaching real objects. : : This is an interesting thought, I will have to ponder it some, but it : has a nice smell. Of course I love indian food and functional : programming, so that may be personal bias :) Could turn out that $obj.assuming is just a generalization of &func.assuming. That'd be kinda cool. What would be in the other side of $obj.assuming? Assuming $obj is an instance already, what are we creating with it? Or perhaps you mean Object.assuming()? In which case it would produce some partially instantiated class. Please clarify :) Stevan
Re: Book RFC - Migrating to Perl 6
On Oct 15, 2005, at 9:57 AM, David Storrs wrote: I would suggest we avoid trying to link Perl6 with Web2.0 in people's minds, at least at first. One of the uphill battles that I'm really tired of fighting is convincing people that Perl is good for more than CGIs and quick-n-dirty system administration hacks. We don't need to throw fuel on that fire by "nicheing" ourselves right at the start. Well, I first learned Perl (Perl 4 at the time) so that I could use it for CGI, and my interest in Perl started to wane in part because I had moved on to other things. I've been doing a lot of work in an ancient language known as MUMPS for the last 10 years or so. It's a language providing, among other things, a rich set of string handling functions, patterns, hierarchical associative arrays, etc. Perl seemed attractive as a more modern (read: Algol-like) alternative to M/MUMPS. But I never ended up using it as much as I expected I would. I think what started me looking back at Perl was developing some UI prototypes in Java (Swing). Maybe I just don't "get it", but I found that the degree of coupling between presentation logic and business logic to be appalling. Despite my best efforts, adding a few fields to a simple patient lookup seemed to involve a lot more work than it ought to (I work on medical information systems for the U.S. Dept. of Veterans Affairs). M. J. Dominus' book "Higher Order Perl" caught my eye (maybe because I have long been interested in computability theory, and maybe because I had a good time learning LISP in college). I know that Perl isn't a functional language, but I was very impressed with what could be done with the language. (And now that I've learned about pugs, I wonder if maybe I shouldn't run off and learn Haskell!) Anyway, I've been thinking a lot lately about maintainability of large scale systems. about 5 years ago, I was given the task of parsing through millions of lines (literally) of source code and building what is essentially a dependency graph. That really made an impression on me. It just seems that no one ever should have to do anything like that. Okay, so maybe this is another niche, but it seems to me that complex systems (and maybe health care in particular) is a natural area for a language like Perl, and one well removed from CGI. === Gregory Woodhouse [EMAIL PROTECTED] "Einstein was a giant. He had his head in the clouds and his feet on the ground." --Richard P. Feynman
Re: Book RFC - Migrating to Perl 6
On Oct 15, 2005, at 7:39 AM, Rutger Vos wrote: Good idea. A fat new O'reilly tome will go some way to capturing mind share for perl6. Gathering ideas wiki-style is also very Web2.0. Perhaps perl6 could be marketed as such, what with the development style - "Perl6, the first Web2.0 programming language". I would suggest we avoid trying to link Perl6 with Web2.0 in people's minds, at least at first. One of the uphill battles that I'm really tired of fighting is convincing people that Perl is good for more than CGIs and quick-n-dirty system administration hacks. We don't need to throw fuel on that fire by "nicheing" ourselves right at the start. --Dks
Re: Re(vised): Proposal to make class method non-inheritable
On Sat, Oct 15, 2005 at 07:39:36PM +0300, wolverian wrote: : On Sat, Oct 15, 2005 at 08:25:15AM -0700, Larry Wall wrote: : > [snip] : > : > Of course, there's never been any controversy here about what to call : > "self", oh no... :-) : : IMHO just call it "self" (by default) and be done with it. :) Let it be so. Larry
Re: Re(vised): Proposal to make class method non-inheritable
On Sat, Oct 15, 2005 at 08:25:15AM -0700, Larry Wall wrote: > [snip] > > Of course, there's never been any controversy here about what to call > "self", oh no... :-) IMHO just call it "self" (by default) and be done with it. :) -- wolverian, contributing to the general disagreement
Re: Re(vised): Proposal to make class method non-inheritable
On Sat, Oct 15, 2005 at 10:34:34AM -0400, Stevan Little wrote: : I think what bothers me most about this is that it seems there is no : way to tell the difference between class methods and instance : methods. That the distinction is only made when the body of the : method does something which is is not supposed to do (method called : with a class invocant attempts to access an instance variable, etc). : : This is one of the major problems that I have always had with Perl 5 : OO. That there is a very fuzzy fuzzy line between the : responsibilities of a class and an instance. But you haven't actually said why this is a problem. If you want to know at compile time that a method must be called with an object that has been instantiated, it seems to me that it's pretty easy to tell 99% of the time whether the method body has made reference to $?SELF in some form or other. And if the compiler can determine that, why should the user have to specify it? : I can see the notion of "a class which is not yet instantiated", this : makes sense in many contexts. But I don't think that in order to have : this, we need to bring back this element of Perl 5 OO. I think we can : still have all the behaviors you have been describing, and still keep : classes and their instances as distinct entities. Well sure, they're at least opposite ends of a continuum. But we may usefully smudge the distinction in the middle unless you can show actual damage from this. And as you pointed out in your other message, your notion of class is mostly hidden behind .meta in my scheme of things anyway. And generally the compiler will know by inspection whether the body is referring to the dynamic class through .meta, the static class through $?CLASS, or the dynamic instance through $?SELF. (And yes, it bothers me that $?CLASS is static while $?SELF is dynamic. The latter is an abuse of the $? sigil, which ought to be reserved for entities known to the compiler. Maybe we should rename $?SELF to something that looks more dynamic. $*SELF is dynamic, but implies global. Hmm, if $.foo() is really a self call, maybe we could make a case for self being $$. Of course, there's never been any controversy here about what to call "self", oh no... :-) : >But we have to think a bit more about the notion of currying class : >objects into real objects, or something approaching real objects. : : This is an interesting thought, I will have to ponder it some, but it : has a nice smell. Of course I love indian food and functional : programming, so that may be personal bias :) Could turn out that $obj.assuming is just a generalization of &func.assuming. That'd be kinda cool. Larry
Re: Re(vised): Proposal to make class method non-inheritable
Larry,
On Oct 14, 2005, at 2:15 PM, Larry Wall wrote:
Look guys, I want it to just consistently be
method bark (Dog $d) {...}
regardless of how instantiated the dog is. Think of partially
instantiated subroutines via .assuming. A sub is a sub regardless of
how much it's been curried. So who cares if it's a complete Dog or
a partial Dog, or a completely generic Dog? Nobody cares until you
try to call a specific method that relies on some specific attribute.
If you call a sub with an incomplete definition, you should be
prepared
to handle the exception. If you call a method with an incomplete
object,
you should be prepared to handle the exception.
Of course, by that argument, $d should be considered defined even if
it's a completely uninstantiated class object. With subs the final
proof of actual well-definedness (not to be confused with .defined())
is whether it can be bound to a particular set of arguments. It's a
rather lazy definition of well-definedness. I'm proposing that
all objects follow the same model of not caring how well they're
defined until you actually try to use them for something. I don't
think I care any more about whether classes test as defined or not.
It's like reality--there are a lot of complex problems where the
simplest way to simulate them is via reality itself, and all other
simulations are guaranteed to be slower.
I think what bothers me most about this is that it seems there is no
way to tell the difference between class methods and instance
methods. That the distinction is only made when the body of the
method does something which is is not supposed to do (method called
with a class invocant attempts to access an instance variable, etc).
This is one of the major problems that I have always had with Perl 5
OO. That there is a very fuzzy fuzzy line between the
responsibilities of a class and an instance.
I can see the notion of "a class which is not yet instantiated", this
makes sense in many contexts. But I don't think that in order to have
this, we need to bring back this element of Perl 5 OO. I think we can
still have all the behaviors you have been describing, and still keep
classes and their instances as distinct entities.
But we have to think a bit more about the notion of currying class
objects into real objects, or something approaching real objects.
This is an interesting thought, I will have to ponder it some, but it
has a nice smell. Of course I love indian food and functional
programming, so that may be personal bias :)
Stevan
Re: Book RFC - Migrating to Perl 6
Good idea. A fat new O'reilly tome will go some way to capturing mind share for perl6. Gathering ideas wiki-style is also very Web2.0. Perhaps perl6 could be marketed as such, what with the development style - "Perl6, the first Web2.0 programming language". In any case, if the book comes out around the same time Perl 6.0.0 comes out there's still plenty of time ;-) On Fri, 14 Oct 2005 22:11:18 +0200 [EMAIL PROTECTED] wrote: > I'd like to start by saying "DON'T PANIC! I'm not going to write a > book on Perl 6" ;-) > > Luckily we have people with much more enlish-fu, > structured-thought-fu, and general get-it-done-fu... Now let's talk > a bit about them: > > Today Geoff Broadwell raised a book idea for discussion on #perl6. > > The result was this wiki page: > > http://pugs.kwiki.org/?MigratingToPerl6 > > Essentially Geoff's idea was that the book will come out around the > same time as Perl 6.0.0, and will be the guide for perl 5 > programmers looking to swallow the Perl 6 pill as easily as > possible. > > The wiki page illustrates how we think it will be structured, and > how we think it should be written. > > Please post feedback and criticism on the list, #perl6 or the wiki > page. > > -- > () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & > /\ kung foo master: : neeyah! >
Re: Standard library for perl6? (graphical primitives)
On 10/14/05, Markus Laire <[EMAIL PROTECTED]> wrote: > Perl does have CPAN, but the problem is that there are no standard > modules, and so there can be several modules doing the same thing. And what is the problem with that? For example, some of the modules for graphics you get to choose from are wxPerl, Tk, SDL. Each of these has its strengths and weaknesses, so you may have one project where Tk is the right thing (perhaps a graphical debugger), and another where SDL is the right thing (a game of some sort), etc. A standard library has to be able to do everything, which usually means that it won't be good at anything. That is, unless we put as much effort into designing it as we have into Perl 6, which is not going to happen. Plus, people have already done that, and put the results into modules like wxPerl, Tk and SDL. > Could it be possible to create a "Standard library" for perl6, which > would also include graphical primitives (putpixel, getpixel, > getcolordepth, putimage, getimage, copyrectangle)? With what underlying library? There are many ways to access the screen. If we stick to one way, we'll be as portable as QBasic. But more importantly, we're trying to stay away from that word "standard". When you wish for a standard library, you're wishing that something get done. In open source projects, the best way to ensure that something get done is to do it. So go write a graphics library, and then we'll see about making it standard. The other thing we've learned about "standard", is that we're making an early commitment, which is probably a crappy commitment. If you provide nothing, that is forcing the CPAN community to come up with one (probably more than one). And all of those will probably be better than one that we come up with: I don't see too many graphics efficianados around p6l. The other other thing we've learned about "standard" is that if there is a decent standard library, then vendors don't care about installing any modules. So the plan for perl 6 is to provide little or no standard library so that vendors will be forced to install a decent set of modules (maybe Bundle::Standard... oops, there's that word again). Luke
