Re: STDOUT = WWW
On 8 July 2011 12:28, Rajeev Prasad rp.ne...@yahoo.com wrote: will apps made for one distribution of Rakudo work with another? Yes, provided that the versions of Rakudo used are sufficiently compatible (one might have newer features that you used that another one hasn't updated to include yet, for example), and that the required modules are available. I don't imagine that we'll get into a situation where you install one particular distribution and then can't install the modules bundled with a different one. the time for web targeted distro is approaching fast. as soon as we know the most secure/stable and extendable WEB services model(mashups/REST/XML/WSDL...) is identified/spec-ed, there will be a need (requirement) for perl compiler(or any other SSLanguage) to support it out of the box. - i think so. Web programming is one of the big applications for Perl historically. It would be silly to neglect that for Perl 6, and there are people looking at writing the necessary modules to provide the support. I wouldn't be at all surprised to see at least a basic CGI module in Rakudo Star. I wouldn't expect something like Catalyst though - that's a bit big to bundle in, but would instead be installed separately. I would also not expect to find this functionality put into the core language at any point - Perl 6 is deliberately intended to be powerful and flexible so that you can write good modules to do anything you need to do without having to have core language support for everything. That way, everybody gets what they need, whether they're doing CGI programming or writing a compiler or using image recognition to count the number of sweets in a jar. You mention too many choices of modules confusing new users - yes, that is a problem, but I personally prefer to have the ability to choose the most suitable module for my task, rather than being stuck with something that somebody has declared is the right way to do it, but actually fits my use case quite badly and causes me a lot of frustration as a result. What is needed is a way to make the appropriate modules easy to find, easy to get and easy to use, in a way that can make system administrators happy (because I know CPAN drives them nuts). rgds, Rajeev From: Carl Mäsak cma...@gmail.com To: perl6-language@perl.org perl6-language@perl.org Sent: Friday, July 8, 2011 6:05 AM Subject: Re: STDOUT = WWW Rakudo (the compiler) will be packaged in various distributions. The one distribution we have so far is Rakudo Star. There's sometimes been talk on conferences and on IRC about putting together a Net/Web-targeted distribution of Rakudo, one with all the appropriate modules pre-packaged. The idea is sound; its time may or may not have arrived. // Carl On Fri, Jul 8, 2011 at 12:59 PM, Rajeev Prasad rp.ne...@yahoo.com wrote: perl generates the WWW page and dynamic form for WWW user, using data stored in RDBMS. WWW user fills form on browser form runs a perl script on server perl script saves input data in RDBMS perl script logs into many other heterogeneous systems using advertised web-services, ssh, telnet etc.. perl script fetches data, operate on it. and saves it in RDBMS output it back to WWW user with proper presentation this is going to be the most used scenario (of perl6) in future[in other words STDOUT=WWW, and STDIN = WWW/RDBMS/remote sys(RPC)], therefore my request is to have some basic (tested fast/secure) functionality built into the base language(interpreter itself), so that i do not have to use any modules for such activity. Of-course, there can be choice of modules of all of above and much more, but for 80% population, basic setup is enough, which means high popularity, and user-base. Too many choices in modules to do the same thing over and over again confuses new developers and slows down development. Also multiple modules doing the same thing, will overlap activities with other unrelated modules too. (But), you can not control how many modules will be written for a particular task (say for e.g. generating HTML templates). Therefore old timers and exceptional knowers of language should clearly rate modules and incorporate minimal functionality (as much as possible) into the base interpreter itself. Another wish is, base interpreter should have no diff whether used to serve documents via console/non HTTP protocol or HTTP protocol. all the best to perl6 community. thank you. rajeev
Re: threads?
Damian, I use threads in C++ a lot in my day to day job. We use an in-house library which isn't much more than a thread class which you inherit from and give a Run method to, and a load of locks of various (sometimes ill-defined) kinds. Let me say: it's not good. Threads with semaphores and mutexes and all that are just horrible, horrible things. It's probably not helped at all by how C++ itself has no awareness at all of the threading, so there are no hints in the code that something runs in a particular thread, you can't put lock preconditions on functions or data structures or anything like that... I'm not sure what a better model is, but what I'd like to see is something which: - can enforce that certain bits of data are only accessed if you have certain locks, at compile time - can enforce that certain bits of code can only be run when you have certain locks, at compile time - can know that you shouldn't take lock B before lock A if you want to avoid a deadlock - uses a completely different model that nobody's probably thought of yet where none of this matters because all those three things are utterly foul I always liked Software Transactional Memory, which works very nicely in Haskell - but not for all solutions. Whatever concurrency model Perl 6 might support, it's probably going to need more than one of them. Since the language is so extensible, it may be that the core should only implement the very basic primitives, and then there are libraries which provide the rest - some of which might ship alongside the compiler. I don't know, but I do not want people to end up having to count semaphores and verify locking integrity by eye because it's really, truly horrible. I did read a bit about Go's mechanism, and it did look interesting. Some systems are very well-modelled as completely independent processes (which might be threads) throwing messages at each other... Actually something that's very nice as a mental model for server-type systems is a core routine which responds to a trigger (say, a new connection) by spawning a new thread to handle it, which is the only thing which handles it, and maybe uses something like channels to interact with any global data store that's required. For that though you need cheap thread creation or easy thread pool stuff, and you need to have a global data model which isn't going to completely bottleneck your performance. I'm totally rambling now, but I do get the distinct impression from all my experience that safe concurrency is very difficult to do quickly in the general case. Of course, the safest concurrency boils down to sequencing everything and running it all on one core... On 12 October 2010 16:25, philippe.beauch...@bell.ca wrote: Although anecdotal, I've heard good things about Go's channel mechanism as a simple lightweight concurrency model and a good alternative to typical threading. Channels are first-class in the language and leverage simple goroutine semantics to invoke concurrency. --- Phil -Original Message- From: thoughtstr...@gmail.com [mailto:thoughtstr...@gmail.com] On Behalf Of Damian Conway Sent: October 12, 2010 10:23 AM To: perl6-language@perl.org Subject: Re: threads? Leon Timmermans wrote: For the love of $DEITY, let's please not repeat ithreads! $AMEN! Backwards compatibility is not the major design criterion for Perl 6, so there's no need to recapitulate our own phylogeny here. The problem is: while most people can agree on what have proved to be unsatisfactory threading models, not many people can seem to agree on what would constititute a satisfactory threading model (or, possibly, models). What we really need is some anecdotal evidence from folks who are actually using threading in real-world situations (in *any* languages). What has worked in practice? What has worked well? What was painful? What was error-prone? And for which kinds of tasks? And we also need to stand back a little further and ask: is threading the right approach at all? Do threads work in *any* language? Are there better metaphors? Perhaps we need to think more Perlishly and reframe the entire question. Not: What threading model do we need?, but: What kinds of non-sequential programming tasks do we want to make easy...and how would we like to be able to specify those tasks? As someone who doesn't (need to) use threading to solve the kinds of problems I work on, I'm well aware that I'm not the right person to help in this design work. We need those poor souls who already suffer under threads to share their tales of constant misery (and their occasional moments of triumph) so we can identify successful patterns of use and steal^Wborg^Wborrow the very best available solutions. Damian On 12 October 2010 16:25, philippe.beauch...@bell.ca wrote: Although anecdotal, I've heard good things about Go's channel mechanism as a simple lightweight concurrency model and a good alternative to typical
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Mon, Apr 12, 2010 at 1:22 PM, Shawn H Corey shawnhco...@gmail.com wrote: Darren Duncan wrote: See http://perlcabal.org/syn/S02.html#Names for your answers. Thanks for the link but nowhere in it does it state tha Perl 6 names are case sensitive. The best the do is this, which implies it is but doesn't state it. Other all-caps names are semi-reserved. We may add more of them in the future, so you can protect yourself from future collisions by using mixed case on your top-level packages. (We promise not to break any existing top-level CPAN package, of course. Except maybe ACME, and then only for coyotes.) So, I'll ask again: Where in the official documentation does it state that Perl 6 names are case sensitive? I think it's more important to ask where it says that they aren't. 1) Perl 5 is case sensitive, and the original Apocalypses ran on the basis of 'if it's not mentioned it's the same as Perl 5' 2) The spec assigns no meaning to identifier characters, it just allows you to use a certain set of them. They mean nothing to the language, therefore it has no concept of case to be insensitive about 3) Most popular programming languages are also case-sensitive Maybe it should be explicitly mentioned somewhere, but I think it's a reasonable default assumption. Programmers know that case-insensitivity is a special form of string comparison which involves lots of extra work, so tend to assume (at least in my experience) that it's not going to happen unless they actually ask for it.
Re: Documentaion Details (was: underscores vs hyphens)
On Mon, Apr 12, 2010 at 8:04 PM, Shawn H Corey shawnhco...@gmail.com wrote: Matthew Walton wrote: On Mon, Apr 12, 2010 at 1:22 PM, Shawn H Corey shawnhco...@gmail.com wrote: So, I'll ask again: Where in the official documentation does it state that Perl 6 names are case sensitive? I think it's more important to ask where it says that they aren't. 1) Perl 5 is case sensitive, and the original Apocalypses ran on the basis of 'if it's not mentioned it's the same as Perl 5' 2) The spec assigns no meaning to identifier characters, it just allows you to use a certain set of them. They mean nothing to the language, therefore it has no concept of case to be insensitive about 3) Most popular programming languages are also case-sensitive Maybe it should be explicitly mentioned somewhere, but I think it's a reasonable default assumption. Programmers know that case-insensitivity is a special form of string comparison which involves lots of extra work, so tend to assume (at least in my experience) that it's not going to happen unless they actually ask for it. You're looking at it from the point of view of experienced programmers. What if the person is a high-school student learning Perl 6 as their first programming language? (And yes, I take the point of view that any computer language that a high-school student can not learn is useless.) If a high-school student assumes case-insensitive identifiers and codes accordingly, the compiler's soon going to tell them they're doing something wrong. Besides, their book will probably mention it (see below). It's fine to assume that anyone who reads the Apocalypses is a very experienced programmer but when it comes to the official documentation, such things should be explicitly stated. By now, the documentation should be reaching its final stages. Yes, it's a finicky little detail but programming is all about getting the finicky little details right. The spec, in parts, is in its final stages (in other parts, it very much isn't). The spec is not user documentation. Most of that hasn't been written yet.
Re: perl6 compiler
Rakudo in its normal operation will compile the program, then run it immediately. You can, however, get it to save the compiled code for later use i fyou wish. On Sun, Mar 14, 2010 at 4:09 PM, dell wendell_hatc...@comcast.net wrote: Hello, I had just began looking at the perl6 raduko compiler and have a question. Is perl6 actually compiled then ran similar to java or is the script ran and then compiled at run time? -Wendell
Re: Functional-style pattern matching
I think the closest things we've got to pattern matching come from a combination of multiple dispatch, where clauses and signature unpacking. I don't know much about the latter, but a where clause can discriminate multiple dispatch variants based on parameter values rather than just the type, so you can say: multi doSomething(@a where { .elems == 0 }) { # empty arrays only } multi doSomething(@a where { .elems = 3 .[2] == 4 }) { # arrays with a third element numerically equal to 4 } multi doSomething(@a) { # anything else } Which is pretty powerful, really. This is a contrived example of what I'm referring to: sub traverse([Leaf $a]) { # do something } sub traverse([Tree $left, Tree $right]) { traverse($left); traverse($right); } my $t = Tree(...); traverse($t); You could do most of this with multidispatch and where clauses. It doesn't quite work because of the unpacking which pattern matching does, and also because Perl 6 data structures don't get built in the same way that Haskell ones do, and you've used a Haskell-like syntax for Leaf and Tree and so forth. Now, while it might be nice to say let me write a signature which accepts a Tree object which has a left and right subtree, and binds them to $left and $right respectively, arguably a where clause can check that the subtrees exist, and your tree class should have good accessors for the subtrees which make unpacking them a little pointless. This is where Perl 6 is not the same as functional languages, since it's got an imperative OO element as well. multi traverse(Tree $t where { all(.left, .right).defined }) { ... } Perhaps.
Re: Counting characters
On Wed, Jan 27, 2010 at 1:19 PM, Carl Mäsak cma...@gmail.com wrote: Mark (), Carl (): S05 describes tr/// in terms of the .trans function, a handsome but very different beast. Specifically, it doesn't seem to have a scalar context, with which one could count things. What does trans return in numeric (+) context? As spec'd, it returns the numification of the string resulting from the substitution, I guess. // Carl $str.comb(/C|G/).join('').chars might do it. It's maybe not quite as elegant... Matt
Re: error installing Perl6
On Thu, Nov 12, 2009 at 2:30 PM, Richard Hainsworth rich...@rusrating.ru wrote: Can't exec svn: No such file or directory at build/gen_parrot.pl line 47. You need to install Subversion in order to allow the build script to obtain Parrot.
Re: unusual invocants
On Tue, Oct 20, 2009 at 2:32 PM, Mark J. Reed markjr...@gmail.com wrote: On Mon, Oct 19, 2009 at 11:47 PM, Jon Lang datawea...@gmail.com wrote: Because a method is part of a role, and ought to abide by the same terms by which the role abides. If Logging doesn't do Numeric, it shouldn't have any methods in it that won't work unless it does. 100% agreed. So what the OP wants to do is declare a method that is available on all those invocants - and only those invocatnts - which do all of roles X, Y, and Z. Granted, you can declare a new role XandYandZ that does X, Y, and Z, and define the method there, but that won't work on $foo unless you declare explicitly '$foo does XandYandZ' . The goal is to have the method show up no matter how $foo comes to do all three roles. This is an interesting idea. Currently, it doesn't work because there's no place for such a method to live, so perhaps there could be a way to declare a method space for arbitrary combinations of roles, a sort of meta-role. It's an odd duck, but it does sort of fall out of the multiple-dispatch semantics, which already let you base implementation chioce on arbitrary combinations of roles... Well, if you could put a where clause on your invocant you could do that... method m($invocant where { $_ ~~ X and $_ ~~ Y and $_ ~~ Z }: Int $a, Int $b) { ... } The STD.pm bot in #perl6 thinks where clauses on invocants are allowed, but Rakudo currently seems to completely ignore them. I'm not sure what the proper behaviour should be. Matthew
Re: unusual invocants
On Tue, Oct 20, 2009 at 5:35 PM, David Green david.gr...@telus.net wrote: I would expect $foo where {$_ ~~ X} and X $foo simply to be different ways of writing the same thing, but whatever works! Yes, but the where clause lets you test against multiple types at once. They don't participate in multiple dispatch in the same way though. Whether it should be possible to attach a where clause to an invocant appears to be unresolved.
Re: Freezing role methods
On Thu, Oct 15, 2009 at 10:07 AM, Ovid publiustemp-perl6langua...@yahoo.com wrote: Reading the paper I linked to could help to clarify the issue. In short, there are times under my current understanding of roles where you *can't* resolve the conflicts. Two roles, each providing and dependent upon a method x(), such that if either tries to use the other's x(), the code will fail. Thus, you cannot choose one x() over the other. frozen traits suggests that the composing class determine which x() it wants and statically binding the other x() to its role, thus guaranteeing that no role can get the wrong x(), but still allowing classes full control over their composition. I need to read the other responses more closely to understand their reasoning. So far, they seem wrong to me, but that's probably because I'm not reading them closely enough. What if there are genuinely situations when you cannot combine two roles into the same class? Do all combinations have to be possible? As TSa said, a role depending on one of its own public methods is asking for trouble when it gets combined with something else with a conflicting method, so perhaps what we should really be thinking about is how to write well-behaved roles.
Re: Cobra Ioke Programming Languages
On Thu, Sep 17, 2009 at 4:41 AM, yary not@gmail.com wrote: Perl is being actively developed for the Parrot VM. LLVM is another interesting option and if someone or some group would like to take it on, it would be a welcome alternate implementation. What parts in particular of Cobra and ioke look useful to you? Looking at Cobra's intro slide- * Cobra is a new language (sub 1.0) Not sure if Perl6 qualifies as a new language. It's built off of an old language, and is backwards compatible with it. And, perl5 is adopting pieces of perl6. On the other hand there's enough in Perl6 that's new it's easy to make the case that it is a new case. Yes, Perl 6 does - it is not backwards compatible with Perl 5. It's based very heavily on it, but I think it does qualify as 'new' to most purposes. New, but at least partially familiar. I don't see anything in either language's summary that Perl 6 can't already do or which couldn't be implemented with it. One thing you have to keep in mind is that when we have the full-blown macro and introspection systems available in a Perl 6 implementation, a great deal of power to add new language features is then in our hands. At that point we could quite probably manage syntax-level support for unit tests, etc. - although I've never been entirely convinced about the absolute necessity of such things. We do have pre- and post-conditions, in PRE and POST blocks - see Synopsis 4 under 'closure traits'. Signature-level where blocks help with DBC-style programming as well. Okay so we don't run on JVM or .NET right now, but there are people who've come to #perl6 and expressed an interest in doing it. Not an easy project, but maybe some amazing people will do it one day.
Re: How can i contribute for perl 6 ?
On Thu, Sep 17, 2009 at 4:13 AM, Saravanan T mail2sarava...@gmail.com wrote: Thanks everyone for sharing the links... Thought of working in porting Data::Dumper functionality in perl 6 .Seems like already there is .perl function which does the same.. and a monker mberends said there is a bug in circular references .. So i am thinking to get deep into the problem. Was expecting perl6 -d functionality to debug ? How do you guys normally debug a perl6 program? Lots of print and say statements, in my case - the old-fashioned way. We don't have a debugger for Rakudo at this point.
Re: Cobra Ioke Programming Languages
On Thu, Sep 17, 2009 at 6:58 PM, yary not@gmail.com wrote: Matthew Walton wrote Yes, Perl 6 does - it is not backwards compatible with Perl 5. That so? I thought Perl6 was supposed to recognize and execute perl5 code. That statement itself implies that perl6 and perl5 are different languages, and I'm not too interested in arguing over semantics. I am curious about P6 executing P5 modules/libraries- that was in the original plans and I think it's still included in the specs- though not sure. That's not Perl 6, so much as there being plans for a Perl 6 implementation to also be able to load Perl 5 libraries and code. Rakudo (and all other Parrot languages) is currently gaining this ability through the Blizkost project, which embeds the Perl 5 interpreter to do the heavy work. A system which understands Perl 6 the language is not going to be happy with most Perl 5 programmes you might choose to feed it - it would have to detect that and feed it to a Perl 5 interpreter instead. There will be such systems, but I tend to think of them as multilingual. On Thu, Sep 17, 2009 at 6:06 AM, Juan Madrigal jua...@mac.com wrote: Hopefully Catalyst will be re-written for Perl6. I think that's a ways away. Right now there is a built-from-scratch wiki in perl6, November, that is pushing perl6's web code-base. P6 will either get Catalyst, or something better. Web development with Perl needs to be easier PHP and Ruby make it easy. I would prefer to just use Perl without having to hunt down CPAN modules for features that are built in to other languages. Mail, Sessions/Authentication, Database Connectivity etc... are native. Maybe the best modules should be included or a standard set developed for the web including Catalyst? EmbPerl is another option. Some people are already writing web apps in Perl6 and discussing their experience, all getting incorporated into the discussion and P6 language / library design. If you have the time to install Rakudo, and join the November effort, then you'll have a direct influence on the future of web development in Perl as well! You're never going to get web features built into the language itself - they will be modules, because Perl 6 is not a language specifically intended for web development (although it's likely to be rather good at it once the libraries are in place). Ruby doesn't do much web in the core language either - Ruby on Rails is all extra (very clever) libraries, rather like Catalyst, although Catalyst tends to expose a bit more of the plumbing. Carl Mäsak is working on a project called Web.pm which is the core Perl 6 web programming experience. It's an outgrowth of the November wiki project, and if you're interested in web programming I recommend you take a look at it as it may well be the basis of all the fancy web frameworks we might want to build in the future.
Fwd: More flexible POD
Woops - forgot to reply all (I'm on an irritating mixture of lists which set reply-to and don't, and I never remember which is which). Sorry! -- Forwarded message -- From: Matthew Walton matt...@matthew-walton.co.uk Date: Tue, Aug 11, 2009 at 7:10 AM Subject: Re: More flexible POD To: Jon Lang datawea...@gmail.com I'm not sure what it should be, but I do believe that there should be a solution which allows elegant mixing of code and Pod. I want to document my APIs by attaching the documentation to the methods in question, otherwise the documentation won't get updated when the code does (and if the code at work is anything to go by, won't get updated at all anyway, but you can at least make it as easy as possible for the people who do remember). Attaching blocks of documentation to bits of code is something that Javadoc's syntax gets very right. The trouble is, if we just allow arbitrary whitespace before the start of a Pod block: class A { =head2 foo() Frobnicates the widget. =end method foo() { ... } } (modulo accurate Pod directives - I'm a bit hazy on how it works now, I keep thinking I should be able to say '=method', but maybe that's a matter for the Pod extractor). Do we run the risk of causing problems if somebody does this: my ($several, $lengthily-named, $variables) = something-which-produces-a-list(); and the parser thinks 'hang on a sec, that's Pod'. This is particularly bad for programmers who don't put spaces around their binary operators (hah! We could enforce it!) and may cause confuzzlement. I don't think footnote-like references in the code would help programmers keep the documentation up to date or help them in reading it to comprehend the code when they come to maintain it, which I think are the two key reasons to put your documentation right there in the code. If you did do it though, you'd have to use named references (probably valid Perl 6 identifiers), because numbers are just a nightmare. Matthew
Re: Rukudo-Star = Rakudo-lite?
Then you could be like TeX and have releases numbered with ever-increasing parts of an irrational number. On Mon, Aug 10, 2009 at 12:37 PM, Mark J. Reedmarkjr...@gmail.com wrote: Wrong reply button... -- Forwarded message -- From: Mark J. Reed markjr...@gmail.com Date: Mon, 10 Aug 2009 07:36:52 -0400 Subject: Re: Rukudo-Star = Rakudo-lite? To: Gabor Szabo szab...@gmail.com That has the same problem as lots of other themes - it puts a hard limit on the number of releases before the One True Rakudo. Maybe you could call it Zeno's Camel (project motto: halfway done!) and have releases numbered 0.5, 0.75, 0.875, 0.9375,... :) On 8/10/09, Gabor Szabo szab...@gmail.com wrote: On Mon, Aug 10, 2009 at 2:02 AM, Patrick R. Michaudpmich...@pobox.com wrote: On Sun, Aug 09, 2009 at 04:35:42PM -0600, David Green wrote: On 2009-Aug-9, at 3:57 pm, Tim Bunce wrote: Perhaps it's worth asking what we might call the release after that one. Rakudo not-quite-so-lite? Rakudo ** (aka Rakudo Exponentiation)? Though I think Patrick is optimistic that development will proceed exponentially enough that a single interim release will be enough to hold us over until Christmas. I'm not sure I'm quite THAT optimistic. :-) We may end up with multiple interim releases in the Rakudo Star series before we reach Christmas. (And yes, they may even be *+1, *+2, etc.) In some ways I'm starting to think of Star (or whatever designation we end up using) as a label for a series of interim releases in the same sense that NASA used Gemini as the label for the program came between Mercury and Apollo. In other words, Star may really end up being a designation for a program of planned releases with certain major objectives that cumulatively lead up to the ultimate goal of a full Perl 6 release. The precise details are still a little ill-formed in my head at the moment, but as they come together (and are expressed in planning documents) I'll be blogging or writing about them appropriately. my bikeshed would go along the lines of @rakudo[*-100] @rakudo[*-99] ... Gabor -- Sent from my mobile device Mark J. Reed markjr...@gmail.com -- Sent from my mobile device Mark J. Reed markjr...@gmail.com
Mixing in to method objects
As I understand it, in Perl 6 a method of a class, as indeed all similar things like a sub or a regex, is represented by an object. If it's an object, I should be able to mix a role into it, right? Something like: role Fancy { has $.something is rw; } sub a { } a does Fancy; a.something = 56; say a.something; a(); And so forth. Now, Rakudo's got a whole load of bugs I'm tripping over trying to do things like this, but I thought I'd check to see if it's supposed to be possible, and if it isn't, why not. Also syntactically, is there or should there be a way to do it which doesn't involve having to haul out the a afterwards - so can the 'does' or maybe a 'but' be attached to the definition itself? As for why I want to do this, I've got something in mind which would be potentially much nicer if some methods can carry a load of extra data around with them - which seems like an excellent use for a mixin, especially as I could then smartmatch against it in order to pick out the relevant methods from the .^methods list. Matthew
Re: Why pass by reference?
Complex or not in that sense, it complicates things in allowing the value to be changed by another path. I think that is something we want to avoid doing, not present as a feature. Much of my original post concerns the actual meaning, not whether it is considered simple. Since then, I see that it is useful for plural containers. We don't want to copy them! But for items, why do we not even _have_ pass by value? The compiler must assume the worst and can't optimize as well. 'is copy' is pass-by-value... remember everything in Perl 6 is a reference, of sorts. Pass-by-value of the reference is covered by 'is ref'. A more useful variant of that being 'is rw', which gives you an extra assurance with its lvalue checking that the user's not giving you something that's going to explode when you try to modify it. Pass-by-value of the thing the reference points to is covered by 'is copy', which is the semantics people would generally expect when they hear 'pass-by-value'. Pass-by-reference-but-don't-accidentally-change-what-it-points-to is covered by the default case or 'is readonly'. This seems to me to be the ideal - we don't copy huge values around when the user doesn't need them, but we also don't have hugely dangerous mutable parameters by default (they should be extremely explicit for the user of an API). Most of the time, there won't be another path where the value could change. Under a threaded model allowing shared variables, sure it could be changed by another thread, but hopefully you're under lock there. If a user of your API contrives to make it change while you're running, that's their own foot they've just shot, because they can look at the signature and know the semantics of the parameter passing being used and know that if they change the value externally before you return Bad Things Could Happen. Matthew
Re: Why pass by reference?
Complex or not in that sense, it complicates things in allowing the value to be changed by another path. I think that is something we want to avoid doing, not present as a feature. Much of my original post concerns the actual meaning, not whether it is considered simple. Since then, I see that it is useful for plural containers. We don't want to copy them! But for items, why do we not even _have_ pass by value? The compiler must assume the worst and can't optimize as well. 'is copy' is pass-by-value... remember everything in Perl 6 is a reference, of sorts. Pass-by-value of the reference is covered by 'is ref'. A more useful variant of that being 'is rw', which gives you an extra assurance with its lvalue checking that the user's not giving you something that's going to explode when you try to modify it. Pass-by-value of the thing the reference points to is covered by 'is copy', which is the semantics people would generally expect when they hear 'pass-by-value'. Pass-by-reference-but-don't-accidentally-change-what-it-points-to is covered by the default case or 'is readonly'. This seems to me to be the ideal - we don't copy huge values around when the user doesn't need them, but we also don't have hugely dangerous mutable parameters by default (they should be extremely explicit for the user of an API). Most of the time, there won't be another path where the value could change. Under a threaded model allowing shared variables, sure it could be changed by another thread, but hopefully you're under lock there. If a user of your API contrives to make it change while you're running, that's their own foot they've just shot, because they can look at the signature and know the semantics of the parameter passing being used and know that if they change the value externally before you return Bad Things Could Happen. Matthew
Re: Multi-d array transforms (was Re: Array rotate)
On Sat, Jun 13, 2009 at 1:08 AM, Larry Wallla...@wall.org wrote: Nevertheless, for any major methods borrowed from Perl 6, I'm not inclined to change them that drastically. Much more likely to define them as sugar for the more general list operators: .push means .=append .unshift means .=prepend .splice means .=impend :-) or some such. That makes sense to me. I'd very much like it if the fundamental methods on most data types were non-mutating - string manipulation, list munging etc. Along with having lazy lists, that gives us a good dose of tricks from the functional world we can do, and with .= and (hopefully) some clever bits in the compiler which can handle it effectively (as in performance-wise), it's no hassle to convert any non-mutator to a mutator. Syntactic sugar for really common mutating cases, as in other methods which do 'the same thing but mutated' is of course fine (particularly when they have sensible/familiar names, which implies to my mind that the operation makes sense). Although some things may be able to be implemented far more efficiently if they know that they're being called with infix:.= and not with infix:.. method munge($self is ro:) { } # infix:. case method mung($self is rw:) { } # infix:.= case ? Marginally inspired by C++ const methods. Of course, a potential problem here is that they might want different return types as well - but maybe our multis are fine with that, and maybe this is just some crazy dream caused by waking up too early on a Saturday morning and thinking about Perl before breakfast. Matthew
Re: Sequential bias in S04 (and Perl6 in general)
Springing out of the ashes (and a job where I have to write Java) for my first post in years: On Fri, 04 Jan 2008 13:13:11 -0800, Dave Whipp [EMAIL PROTECTED] wrote: I agree that adding a parallel forall (and similar statements) via a pragma will be easy if the appropriate underlying machinery is there, so maybe I can live with the bias in S04 -- perhaps rename it to Sequential Blocks and Statements. Anywhere that we guarantee sequential behavior, we pretty much rule out concurrency. But if we maximize the number of places where we are explicitly unordered then we also maximize the number of places where implicit concurrency can be added later. From that perspective, it's unfortunate a Cfor loop always iterates arrays in the order of their indices. I wouldn't agree with that at all. I think of arrays as ordered constructs, so I'd want the default iteration over my array to happen in the order of the indices. I wouldn't have a problem with having the ability for Cfor to iterate over a bag or some other inherently unordered, unsorted container in arbitrary possibly-parallel order though. Possibly by default, if the compiler can be satisfied that the closure's not got any unpleasant side effects to interfere with parallel execution. I think you're leaning too far towards concurrency in attempting to address the perceived bias. A lot of the time, the compiler's not going to be able to prove that it's safe to autothread a given closure because it might have side effects. If we were talking about Haskell or some other language which is ordinarily pure, things would be different. Under these circumstances, I would much rather have to explicitly say that I want parallel execution - provided that the ability to do it is there and it's easy to get at and behaves in a sensible manner (naturally this lets you parallelise things the compiler isn't sure are safe to parallelise due to possible side effects. That's fine, since you know which side effects are okay to do that to in your program). Matthew
Re: Sequential bias in S04 (and Perl6 in general)
On Fri, 2008-01-11 at 10:34 -0800, Dave Whipp wrote: Matthew Walton wrote: I wouldn't agree with that at all. I think of arrays as ordered constructs, so I'd want the default iteration over my array to happen in the order of the indices. I guess that depends on whether you think of the array as a list or as a ram. I know that a group at microsoft added a ParallelArray datatype (ftp://ftp.research.microsoft.com/pub/tr/TR-2005-184.pdf) to C# as a way to distinguish the intent (they speed up data-parallel code by compiling it down to your GPU/graphics card). Perl6, being an operator-oriented language, associates the distinction with the operators rather than with the datatype. This is probably a better approach, but it does mean that you need an operator whenever you want to treat the array as data-parallel. (BTW, data-parallel arrays differ from bags in that they have an ordered index that is preserved across unordered operations) Good point, a parallel operation over a list would let you preserve ordering but still benefit from concurrency with operations where iterating in order is irrelevant. Which, come to think of it, covers quite a lot of cases. Of course, it's not necessarily true that you know that something is safe -- often you think it's safe but then you get an intermittent failure at runtime,. I would love to be able to tell the compiler I think this is safe and have it tell me you're wrong as a compile-time error (this is one of the things that an explicit type system is good for). But perhaps Perl is too dynamic a language for that. Well, I was thinking with 'knowing' that something was safe that you'd figured out that it was free of side effects by studying the behaviour of everything you use within the relevant routines... ...in the real world, you need the compiler to be able to do some of that for you I guess. And Perl 6's optionally explicit type system might be able to express that sort of thing. signature.asc Description: This is a digitally signed message part
Re: ^method ?
On 15/05/05 22:48 +0100, Matthew Walton wrote: I don't think that is what Rob is saying at all. It wasn't aimed entirely at Rob. I have a bad habit on mailing lists of vaguely replying to the entire thread without remembering who said what and being too lazy to check. My read: .method($foo); always means: $_.method($foo); and $self.method($foo); always means $?SELF.method($foo); The former is consistent with the rest of Perl 6, and the latter is consistent with most of Perl 5 OO code in the wild. My only stance is that, given there is no clearly sexy solution, at least I can take `$self` home to meet my Mom. Perhaps. However, I'm uncomfortable with the idea of $self being automatically assigned, because so far Perl 6 seems to have managed to avoid automatically providing anything in what I've been thinking of as the 'normal' or 'user' namespace. $?SELF looks 'special'. Admittedly it might be nicer if it was $?self, because it still looks 'special'. It's the same kind of thing that makes me wonder why $a and $b in sort was ever considered a good idea. But then perhaps I'm just odd... choosing a name for the invocant yourself if you don't want $?SELF or $_ to be it (although they will be anyway of course) seems to me to be the height of programming sexiness. I like being able to name things myself. The ./method() thing proposed in another thread is pretty cool too, by the way, and largely renders this thread moot. So perhaps I should have replied to that...
Re: ^method ?
. On 15 May 2005, at 16:17, Rob Kinyon wrote: Right now, P6 has $?SELF and I'm saying that instead of using $?SELF, we should use $self wherever $?SELF would be used. $_ is still the topic and would be the default invocant if you have .method($foo). What I'm saying is that you can have method ( Int foo ) { $self.otherMethod( foo ); } and it will DWIM. Just like Java, C++, and Javascript. (Yes, I'm using JS as part of my argument.) If you have method ( Int foo ) { .otherMethod( foo ); } That would be method ( Int foo ) { $_.otherMethod( foo ); } Just like expected. My ill-considered and probably not very understandable thoughts: - As has been said with great eloquence earlier, virtually everywhere in Perl 6 so far when you leave something out the default is taken to be $_ - As has also been said, elsewhere, internal consistency is a great feature of a language people are trying to learn Given these two points, in my mind anything other than making .method($foo); mean $_.method($foo); is utterly absurd. If it means $_.method($foo) outside a method definition and $?SELF.method($foo) inside one then I think it's a reasonable expectation for people learning Perl 6 to throw up their hands and start complaining loudly (and possibly going back to their previous language of choice). It also seems to make sense to me that the invocant of a method is the default topic for the method body - that is, after all, what that code has been invoked in order to do something to/with. Is it really a serious hardship to do what you have to do everywhere else in Perl 6 if you want to preserve the topic, and give it a name of your own choosing? method m($self: $foo) { $self.do_something(); } is hardly difficult to deal with in my opinion. Neither is method m($foo) { my $self := $_; $self.do_something(); } for that matter. Remembering not to clobber the topic when you want to keep it will be second-nature to Perl 6 people very shortly after they start, I'm sure, as it's always seemed to me that it's going to use a lot more things which allow you to do a lot of topic manipulation instead of having to think up silly variable names all the time (given {} will be particularly handy for my code, thank you very much for that!) Thus I don't think that given {} and other such things inside the method body are going to be something people will particularly find problematic with regard to clobbering their invocant, as there is an easy and clear syntactic way to give it an alias, and normal variable binding can rescue it at any point up to the point where you assign something else to $_ (assuming I've understood binding correctly, of course). And indeed afterwards, if you use $?SELF. Which, to be honest, I'm not particularly keen on in terms of appearance or ease of typing, but I don't think we're going to need it except in 'emergencies' - $_ and the invocant naming syntax will provide plenty of opportunity for people to refer to $? SELF by a saner and more appropriate name for their given situation. In the long run I can see making sure .method() defaults to $_ everywhere will save me a fair bit of typing - my methods (in C++ and in Perl 5) are usually made up either of coordinating calls to other methods of the same object, which will be nice and simple due to being able to omit the $_ or $?SELF or other name I might have given the invocant; or made up of a bunch of operations largely concerning other objects, in which case the whole thing goes out of the window because you're barely talking to the invocant at all. In that case, changing the topic at various points is probably going to be an advantage, depending on the code structure of course. That may lead to the potential issue of calling the same thing by two different names ($_ and $?SELF or $self or $this or $me or whatever) in the same method, but that's more a question of style than anything else - the careful programmer will make sure it's understandable what's going on, while the careless programmer will make a mess no matter what the language lets them do. So that's what I think anyway. Not that anybody should listen to me of course, but I really can't see the logic in some of the suggestions being thrown about here, so I thought it was prudent to try and head them off before my favourite unfinished language gets spoiled.
Re: [pugs]weird thing with say ++$
On Thu, Apr 21, 2005 at 11:45:27AM +0200, Paul Johnson wrote: It certainly makes more sense to me that the answer would be 2 2. But however it ends up, so long as we know what the answer will be, we can utilize it effectively in our programs. The trick with this construct usually in C is that the C standard doesn't specify the order of evaluation of function arguments, so you can never be sure if you'll get the same result if you compile it other than on your development system (different compilers may evaluate them in a different order). The Pugs example given in the original post seems to me to be fairly sane, as it shows left-to-right evaluation. The Perl 5 example, as far as I can tell, shows left-to-right for the first case and right-to-left for the second case, which is just odd... please correct me if I'm wrong, but that seems the only way those answers could have been arrived at. So really, what needs to be said is how Perl 6 is supposed to evaluate the arguments to function calls, then we can know if the current behaviour in Pugs is correct.
Re: should we change [^a-z] to -[a..z] instead of -[a-z]?
delurk even sillier question: if [a.z] matches a, . and z and [a...] matches all characters from a including (for some definition of 'all') how will be range \x21 .. \x2e written? [!..\.]? (i.e. . escaped?) /delurk I was assuming from Larry's mail that [a...] would parse as either: 1) a character class containing the range from 'a' to '.' (what that means is a bit mind-bending for a friday afternoon) 2) a character class containing 'a' then a range from '.' to... oh, an error Which way might be ambiguous, but could of course be defined in the grammar. It hadn't occurred to me that ... for the range to infinity would be allowed or useful here. I suppose it could just mean 'up to the end of the available codepoints'. I do love the idea of [a..f] type ranges though. It's just what the three dots mean that's got me confused.
Re: Junctive puzzles.
Matt Fowles wrote: This is Just Wrong, IMO. How confusing is it going to be to find that calling is_prime($x) modifies the value of $x despite it being a very simple test operation which appears to have no side effects? As far as I can see it, in the example, it's perfectly logical for is_prime($x), is_even($x) and $x 2 to all be true, because an any() junction was used. If an all() junction was used it would be quite a different matter of course, but I would see is_prime() called on an any() junction as returning true the moment it finds a value inside that junction which is prime. It doesn't need to change $x at all. In a way, you're sort of asking 'has $x got something that has the characteristics of a prime number?' and of course, $x has - several of them, in fact (but the count is not important). Soemtimes, although frequently I will check for preconditions at the begining of a function. After I finished checking for them, I expect to be able to do stuff assuming them without anyworry of exceptions or anything else. In these cases I am using conditionals to filter input, which I imagine is a fairly common case... Yes, it is fairly common, but I don't think it's common enough to attach unexpected side-effects to innocent-seeming functions. If I want to modify a junction to contain only values which satisfy a given precondition, I'll be wanting to use something which states that explicitly. Which reminds me that I'm not very aware of anything which can decompose a junction once it's been created, which would be fairly necessary for doing that sort of thing. If you can turn junctions into lists then precondition filtering isn't bad at all. Something like my $filtered = any($junction.list().grep({ satisfies_precondition })); Of course, I just invented that out of nothing so I may be way off base. I haven't found anything in any Apocalypse or Synopsis which says if you can do things like this, but if Perl itself can pick junctions apart, we should be able to as well. My approach to this comes somewhat from my basis in liking Haskell a lot and thus wanting to keep unusual side-effects to a minimum. However, if junctions collapse and modify themselves as was in your example, what happens when you don't want to have them collapse? Do you have to explicitly make copies?
Re: Perl 6 Summary for 2005-01-31 through 2004-02-8
Michele Dondi wrote: On Tue, 8 Feb 2005, Matt Fowles wrote: pipe dreams Juerd wondered if he could mix = and == in a sane way. The answer appears to be no. Once you bring in == you should stick with it. Huh?!? It doesn't seem to me that the answer is 'no'. In fact C == is supposed to be yet another operator, albeit somewhat a special one. If I got it right the answer is actually 'yes': what Larry suggested is that it would be _stylistically_ better to stick with it once it is used in the first place. It was also a matter of precedence, as = binds more tightly than == so extra brackets would be required, leading to == being neater if you only use it in conjunction with other ==. Which I rather liked.
Re: Pop a Hash?
Rod Adams wrote: Does ($k, $v) == pop %hash; or ($k, $v) == %hash.pop; make sense to anyone except me? Makes sense to me. Although I would be more inclined to think of pop as returning a pair - but does a pair in list context turn into a list of key, value? If so then the above makes lots of sense. Since we now have an explicit concept of pairs, one could consider a hash to be nothing but an unordered (but well indexed) list of pairs. So, C pop %hash would be a lot like C each , except, of course, that it deletes the pair at the same time. The only thing people might not be too pleased about is that the order is entirely at the whim of the internal implementation of hashes. I suppose you could say %hash.sort.pop(), but that would probably re-sort every time and that's clearly not desirable. Working on a sorted copy is also not particularly pleasant as memory could be a considerable problem. If we do that, I'd also want to be able to push %x, %y; which would mean something like: %x{%y.keys} == %y{%y.keys}; but be much easier to read. Yes, I'd like that. I find myself wanting to do things like that quite a lot in Perl 5.
Re: Junctive puzzles.
Matt Fowles wrote: All~ On Tue, 08 Feb 2005 17:51:24 +0100, Miroslav Silovic [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Well, we see the same kind of thing with standard interval arithmetic: (-1, 1) * (-1, 1) = (-1, 1) (-1, 1) ** 2 = [0, 1) The reason that junctions behave this way is because they don't collapse. You'll note the same semantics don't arise in Quantum::Entanglement (when you set the try to be true option). But you can force a collapse like this: my $x = 4 $j; if $j 2 { say never executed } By which I mean: my $x = 4 $j; if $x 2 { say never executed } Uh, I'm not sure this does what I think you wanted to say it does. ;) $x is a boolean, unless returns a magical object... in which case, the magical part of $x ought to be a reference to the original $j, no? I'm wonding if we should allow a method that returns a junction that is allowed to collapse the original: if 4 $j.collapse and $j.collapse 2 { say never executed; } But that's probably not a good idea, just by looking at the implementation complexity of Quantum::Entanglement. People will just have to learn that junctions don't obey ordering laws. Well, I suspect that junctions will have to be references and just collapse every time. Observe: my $x = any(1, 2, 3, 4, 5); print SHOULD NOT RUN if (is_prime($x) is_even($x) $x 2); This only works if $x collapses. Same for matching junctioned strings: my $a = any (a b c); print Boo! if $a ~ /a/ and $a ~ /b/ and $a ~ /c/; (perhaps I meant to use ~~, I don't quite remember :) ) Either way, autocollapsing juntions is a Good Thing IMHO, and the only remaining confusion (to go back to my initial post) is that the only case that doesn't work is when you instance a junction twice as a pair of same literals: print SUCCESS, unfortunately if (is_prime(any(1, 2, 3, 4, 5)) is_even(any(1, 2, 3, 4, 5)) any(1, 2, 3, 4, 5) 2); Hope I'm making sense. Been a hard day at work. ;) What if junctions collapsed into junctions of the valid options under some circumstances, so my $x = any(1,2,3,4,5,6,7); if(is_prime($x) # $x = any(2,3,5,7) and is_even($x) # $x = any(2) and $x 2) # $x = any() This is Just Wrong, IMO. How confusing is it going to be to find that calling is_prime($x) modifies the value of $x despite it being a very simple test operation which appears to have no side effects? As far as I can see it, in the example, it's perfectly logical for is_prime($x), is_even($x) and $x 2 to all be true, because an any() junction was used. If an all() junction was used it would be quite a different matter of course, but I would see is_prime() called on an any() junction as returning true the moment it finds a value inside that junction which is prime. It doesn't need to change $x at all. In a way, you're sort of asking 'has $x got something that has the characteristics of a prime number?' and of course, $x has - several of them, in fact (but the count is not important).
Re: CLI signature?
Juerd wrote: This probably goes against everything a shell based platform wants, but would it be possible to give the program a sub-like signature? I ask this after another painful session of forgetting how things work, reading Getopt::Long's documentation. signature ( Rule $pattern, bool +$help:short('h'), Int +$verbose :short('v'), Str [EMAIL PROTECTED] = - ); With GNU-like parsing, this'd make @*ARGS = foo|bar --verbose 2 first second third ; @*ARGS = foo|bar -vv first second third ; result in the lexical variables $pattern = rx/foo|bar/; $help= false; $verbose = 2; @files = first second third ; and @*ARGS = foo -- -v --verbose --help forth fifth sixth ; in $pattern = rx/foo/; $help= false; $verbose = undef; @files = -v --verbose --help forth fifth sixth ; and @*ARGS = pattern in $pattern = rx/pattern/; $help= false; $verbose = undef; @files = ('-'); Probably a macro can handle this, but does (will) Perl parse a signature-like argument list and hand the macro something it can use, or would this require source-filter like trickery? Would this actually be any better than the interface provided by Getopt::Long? I suspect that it's possible, and I also suspect that Getopt::Long can be written in a much friendlier manner for Perl 6 (not that I have any particular complaints about how it handles things now, but it can certainly be better). I do feel that command-line option parsing should not be built into the language though - let modules take care of it, then we'll never have to worry about pushing some built-in mechanism aside when we want to do something peculiar. What you want may well be possible with a module though - or something similar to it.
Re: Making control variables local in a loop statement
Austin Hastings wrote: David Storrs wrote: On Thu, Jan 13, 2005 at 07:35:19PM -0500, Joe Gottman wrote: In Perl5, given code like for (my $n = 0; $n 10; ++$n) {.} the control variable $n will be local to the for loop. In the equivalent Perl6 code loop my $n = 0; $n 10; ++$n {.} $n will not be local to the loop but will instead persist until the end of enclosing block. Actually, I consider this a good thing. There are lots of times when I would LIKE my loop variable to persist and, in order to get that, I need to do the following: my $n; for ($n=0; $n10; ++$n) {...} ...do stuff with $n... It's a minor ugliness, but it itches at me. Under the new Perl6 rules, I can easily have it either way. {for (my $n=0; $n10; ++$n) {...}} # Local to loop for (my $n=0; $n10; ++$n) {...}# Persistent --Dks But there's no clean way to make some of them temporary and some persistent. This seems like a legitimate place for saying what you intend, viz: for (my $n is longlasting = 0, $m = 1; ...) {...} Albeit that's a lame example of how to do it. What's not clean about { loop my $n = 0; $n 10; $n++ { ... } } ? Works fine for me, shows the scope boundaries very clearly indeed, just the kind of thing a lot of languages are missing, IMO. Of course, this example's really bad because it's much better written for 0..9 { ... } In which case I assume that it only clobbers the topic inside the block, not outside it, as it's somewhat like for 0..9 - $_ { ... } To write it explicitly. Or am I barking up the wrong tree completely?
Re: iterators and functions (and lists)
Michele Dondi wrote: On Sun, 5 Dec 2004, Matthew Walton wrote: At least we had the sense to call them subroutines instead of functions. Of course, that also upset the mathematicians, who wanted to call them functions anyway. Go figure. That might be because the mathematicians haven't heard of a variant of a function which is allowed to have side effects yet. More or less BS for, from the point of view of a mathematitian (i.e. from the point of view of Mathematics), you still have true functions, they're either not just the *same* function each time, or the same function with some arguments/parameters set to different values (that in the implementation are passed implicitly rather than explicitly), which are fundamentally the same thing after all (up to an isomorphism, that is). I wasn't intending to be taken seriously with that comment. I hope everyone realised that...
Re: Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
Austin Hastings wrote: I'll guess that you're pointing at .:send_one($_); Which supposedly uses topic to resolve .:send_one into $this.send_one. If that works, then I'm happy -- I like being able to control topic and $_ differently. But if Cfor changes topic, then what? OUTER::.:send_one($_); Yuck. I believe it needs to be method send ($self: [EMAIL PROTECTED]) { $self.:send_one(BEGIN); for @data { $self.:send_one($_); } $self.:send_one(END); } While that works (I think it works anyway), its debatable if it's nice or not. The first and last calls to .:send_one shouldn't need the $self, but I put it there because if you use the $self inside the for in a method that short, it's nice and clear to have it outside it as well. I suspect the original example expands the for loop into the equivalent of: for @data - $item { $item.:send_one($item); } And it doesn't take a $larry to figure out that this isn't going to make the compiler very happy, as it's most likely a violation of class access control, I would have thought. So Luke, am I right?
Re: iterators and functions (and lists)
Larry Wall wrote: On Sun, Dec 05, 2004 at 12:05:46AM +, Matthew Walton wrote: : I'm sorry, but from a C++ background, overriding postcircumfix:( ) : feels far more natural to me than setting 'is default' on some method. That only works for disambiguation if you know which .() to call in the first place. It seems likely that that .() maps straight to MMD and doesn't look for a singly dispatched .() at all. But maybe I'm just not understanding this. No, that makes sense. What you're talking about already sounds suspiciously like Aspect Oriented Programming. I wouldn't know, I've never looked into it. Perhaps I should... Any foo() can return a list. That list can be a Lazy list. So the ordinary return can say: return 0...; to return an infinite list, or even return 0..., 0...; to return a surreal list. Either of those may be bound to an array as its generator of missing values. Assignment sort of implies copying, but I'm just saying that the copier could also be smart at least about infinities or indefinities (ohh, a cool new word), even if it flattens everything else. That would be good. It would be nice to be able to copy infinite lists without having to flatten them first. An object can play the Undef role. Or maybe undef can play Ref role. In any event, since a string is an object, the answer is Yes, but an unthrown Exception object that can stringify would be better... I'll take either for now. I suspect an unthrown Exception will turn out to be the better solution, as it sounds much more useful. Except that I'm not quite sure how you'd notice it - I assume unthrown Exceptions would be expected to return false in Boolean context? Next thing you'll be telling me is that all this partially evaluated code shouldn't have any side effects. :-) Well of course it shouldn't. Confining all actions which have side effects to the IO monad makes it much easier to reason about programs and their behaviour. Although I suspect anybody who tries to reason about something written in idiomatic Perl deserves the headache they're going to get. That doesn't mean I don't find Perl to be immensely fun to work with though. I believe Perl 6 will be even more immensely fun.
Re: Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
Luke Palmer wrote: The remaining problem is what to do about unary dot. Repeated here for the, er, benefit? of p6l: class Duple { has $.left; has $.right; method perform (oper) { oper($.left); oper($.right); } } Let's change that into a Tuple class: class Tuple { has @.elems; method perform (oper) { for @.elems { .perform($_); } } } Can you find the mistake? Well it's not using oper on the elems anymore. method perform (oper) { for @.elems { oper($_); } } But I don't think that was the mistake you were talking about. And I don't see what it has to do with unary dot either, because you don't need to use unary dot to implement that method. Unless each member of @.elems is a Duple, in which case the class isn't one I'd call Tuple. Sorry, nitpicking level seems to be set to 9 at the moment. What did you mean?
Re: while Idiom (Was: Arglist I/O)
Elyse M. Grasso wrote: But you need to process the file while you haven't reached the end yet, or until you reach the end. And I can't think of an occasion where I knew going in what the length of the file I was processing was going to be. I suppose foreach might make sense if you sucked in the whole file at once and then processed the individual lines, but I've seldom been in situations where I could assume it was safe to do that. (Data expands to fill the space available, plus 10 %... and the production data file is always bigger than they told you it would be.) The same goes for database queries: you loop while the query is returning data or until it stops returning data. Foreach implies to me that you want to do the same thing, or something very similar, to each of the things you are processing. But in handling the lines of a file or the records returned by a query you may in fact want to throw many of them away, or handle various subgroups of data in different ways. That doesn't make any difference as far as I'm concerned. foreach (or for in Perl 6) implies to me that you have a list of things and you're going to look at each of them in turn. Whether you do the same thing to them or not is to my mind irrelevant, you're stepping over a list item by item. for is, to me, ideally suited for anything where you're looking at a sequence of things one at a time - reading lines from a file fits that perfectly. Perhaps the reason the indeterminate length of a file doesn't bother me is because I'm a Haskell programmer, where everything is lazy and recursing over lists is about the only way to get any kind of looping at all. Iterating over something of indeterminate length really doesn't bother me :-) Something like the C++y while(!in.eof()) { ... } Is attractive in its way, but I'd rather have something more convenient, and I think doing a for over a conceptual list (as in it's not really a list, but it's behaving kind of like one in this context) of lines in the file is infinitely better. One can also view the results of a database query as a list of rows returned which you then look at one at a time. In fact, I find that far more natural than fetching until there are none left. Of course, you're still really doing that behind the scenes.
Re: iterators and functions (and lists)
Larry Wall wrote: : of course, that analogy isn't going to work for true functions, which : returns the same all the time, for some given set of arguments. Oh, well, we pissed off the mathematicians long ago. :-) At least we had the sense to call them subroutines instead of functions. Of course, that also upset the mathematicians, who wanted to call them functions anyway. Go figure. That might be because the mathematicians haven't heard of a variant of a function which is allowed to have side effects yet. Thank goodness the functional programming people have, otherwise Haskell would be pretty useless. : $fh(:chomp) Yes, but in general I think an autochomper layer should be applied to the handle/iterator at open/construction time, not at evaluation time. That seems like a sensible approach. I see it as unlikely that I'm going to want to read a file in a mixture of chomped and not-chomped modes, so I'm going to want to set chomping on the filehandle. However that's done. And if I *do* ever want to do mixed-chomping on a read, I should just open the file in non-chomped mode and chomp manually when I know I want to do it, because Perl won't be able to figure it out for me except in some really really weird circumstances I don't really want to be thinkinga bout. : # what about making foo( :bar ) the same as : # foo.assuming( :bar) ? ah, that not gonna work.. but I : # think that feature definitely wants something more short : # than .assuming; maybe even some special syntactic honey. : # because it's fun(ny|ctional) We made it long on purpose for readability. You can always use a macro to obfuscate it. What we're *not* going to do is autocurry missing parameters like Haskell. That just screws up all the compiler's expectations on return types. If I forget to supply an argument, I want an error, not a function pointer. I can add in the .assuming myself when I decide I need it. All autocurrying does is sweep the dirt under the carpet for someone else to deal with. Yes, not really a Perlish thing is it? Haskell programmers cope with it because the entire type system explodes if you return a function instead of a value somewhere (by leaving out one or more arguments), but Perl's unlikely to do that with quite the same level of reliability, I would think. While I'm pleased that Perl allows me to pass functions around with almost the same ease as I get in Haskell, because Perl isn't a pure functional language, the thought of making it behave like that is quite scary. : class Foo { : has $.counter; : # multi postcircumfix:( ) makes me sick :( Not sure it needs to be multi. Generally a reference tells you exactly who you're dispatching to. : method bar is default { : $.counter++; : } : } : : # emulating 10... : $a = new Foo :counter(10); : say $a.bar; : say $a(); Probably want to handle list context as well. I'm sorry, but from a C++ background, overriding postcircumfix:( ) feels far more natural to me than setting 'is default' on some method. What if you do 'is default' on two methods? Compile-time error? What if you're opening up someone else's class and want to override the existing default (okay, so you shouldn't be doing that in an OOP world, but what if you are? What if you're like me and like Perl's delightful mishmash of paradigms while simultaneously liking other languages for their purity? What if I actually talk about something relevant?) : # other thingies: : : sub foo { ... }; : @array = @foo # all the results of foo, lazily. Don't see the need for that when @array := foo() does laziness implicitly already. Maybe even @array = foo() maintains laziness if it sees an infinite iterator in the return value of foo(). Or maybe it blows up and tells you to use := to avoid trying to make a copy. That's probably cleaner. This is going to take me a while to get my head round... Does this particular foo() return an iterator? Or is it something which is iterated? Have I missed a bit of a synopsis or apocalypse which would make all this clear to me or are we still in handwaving mode? Exceptions should not be used for something so mundane as running out fo values. Amen to that! One reason I ran screaming from Java was having to catch ArrayOutOfBoundsException all the time. And all those exceptions which the compiler forces you to catch. They're handy, but there is a limit. I prefer return values which can indicate if they're valid or not. undef is excellent for that :-) A string pretending to be undef can be even better. Can we still do that? I seem to recall it being in something at some point along the way. If that's necessary to keep the Lazy from blocking when it runs out of values. Just like an ordinary array, a Lazy has to be aware of when it is out of values, and when it should call into some meta-Lazy for more iterator values. And I suppose that meta-Lazy could in turn have a meta-meta-Lazy, which could have a
Re: Angle quotes and pointy brackets
Larry Wall wrote: I thought so. : I don't think I've ever used a hash slice in my life. Is there something : wrong with me? No, a lot of people are naturally monoindexous. I like that word. : * The :w splitting happens after interpolation. So : : « foo $bar @baz » : : can end up with lots of words, while : : « foo $bar @baz » : : is guaranteed to end up with three words. : : See the comment about 'fabulouser' above and add another 'and : fabulouser' to the end. I neglected to mention that the smart quoter should also recognize pair notation and handle it. I've been trying to get my brain round that, but I can't quite figure out what you mean. Pair notation is, as I understand it, when you get key = value to construct a pair. Assuming that's me remembering correctly, then where does the smart quoter have to deal with pair notation? Are you considering allowing something like: « key1 = flop key2 = floop » Which would be hash(key1 = flop, key2 = floop); or am I completely off my rocker? I hope I am, because that's kind of ugly. The only other thing I can think of is if you're just talking about *implementing* infix:=, in which case just ignore the above because of course the autoquoter needs to recognise its left-hand-side. As an aside, is it possible for us to define our own autoquoting operators? I assume it will be, but I'm feeling insecure and need reassurance. I neglected to mention that we also naturally get both of: circumfix:« » circumfix:« » in addition to circumfix:{'',''} circumfix:{'«','»'} Have to be careful with circumfix:«{ }» though, since {...} interpolates these days. Yes, that would be fun... almost worth throwing out a compiler warning for that, especially if we've still got use warnings. Something like Warning: «{ }» creates empty list or even Warning: circumfix:«{ }» creates empty operator that one could be an error in fact. or if you're feeling really nasty Syntax error Because I'm sure it should be wrong to create empty circumfix operators. Or am I too prescriptive? My inner Haskell programmer is showing through.
Re: Angle quotes and pointy brackets
Juerd wrote: Matthew Walton skribis 2004-12-01 9:55 (+): Yes, that would be fun... almost worth throwing out a compiler warning for that, especially if we've still got use warnings. Something like Warning: «{ }» creates empty list It should generate a warning similar to the warning of interpolating an undefined value, but with s/undefined variable/empty list/. Yes, that would make sense. Because I'm sure it should be wrong to create empty circumfix operators. You have to admit that zero width circumfix operators would be VERY NEAT. Well that depends... are you intending to write programs, or drive the world insane?
Re: Angle quotes and pointy brackets
Larry Wall wrote: I rather like it too. I'm glad someone else is thinking along the same lines. The basic problem with «...» is that most of its uses were turning out to be more useful that the corresponding In fact, I was thinking about all this on the way home from Seattle yesterday (a 15-hour drive), and I think I'm ready to propose a Great Angle Bracket Renaming. Well... this is interesting. I'm wondering, should I recycle my copy of Perl 6 and Parrot Essentials, or keep it as an historical document for future generations to look at and marvel over? Just kidding, I'm surprising myself by liking this. Let's see if I've understood it. Here's the proposal. First the bad news: * We accept that the C operator requires whitespace around it, and be prepared to be burned in effigy occasionally. Personally, I always use whitespace around such operators, so it's no hassle for me for it to be required. Might encourage some more readable code (definition of 'readable' unfortunately still undecided across the programming community). * We steal angles away from iterators. Will they miss them? In a way it's nice to have syntax-level support for iteration, but it's no massive hardship to do without. Now the ugly news: * Hyper operators stay the same, »op«. That's not ugly. Now with those out of the way, the good news: * All other uses of «...» and ... swap, pretty much. Now, that has certain interesting outcomes. * We get ... as the qw// shorthand where a term is expected. So my @list = foo bar baz; is the equivalent of my @list = ('foo', 'bar', 'baz'); ? * Most uses of qw// involve strings and lists, so there's little visual interference with numeric comparison operators. Very true. * People can probably get used to reading things like: $varkey1key2[3]key3 $varkey1key2[4]key3 * Though they will certainly carp. They always do. * Since we already stole angles from iterators, «$fh» is not how you make iterators iterate. Instead we use $fh.fetch (or whatever) in scalar context, and $fh.fetch or @$fh or $fh[] or *$fh in list context. That's doable. I take it that if I do for (@$fh) { ... } then $fh iterates lazily rather than exploding into an enormous list to be processed and chewing up all the RAM. * That frees up «...» for Something Else. * That something else is the requested variant of qw// that allows interpolation and quoting of arguments in a shell-like manner. Mmmm so I can write my $foo = 'foo'; my $bar = 'bar'; my $baz = 'baz'; my @list = «$foo $bar $baz»; and get the same @list I got earlier? Mighty cool. * That means that, roughly, we have this proportion: '...' : ... :: ... : «...» Elegance, always good. * Therefore, just as you can use ... in place of '...' where you you think it's more readable, you may still use «...» in place of ... where that helps readability. $var«key1»«key2»[3]«key3» $var«key1»«key2»[4]«key3» Fabulouser and fabulouser. * Both the «...» and ... forms work as slices when used as hash subscripts. I don't think I've ever used a hash slice in my life. Is there something wrong with me? * The Texas quotes ... are only needed when you *have* to interpolate. Does foo bar baz mean «foo bar baz» or ('foo', 'bar', 'baz') ? * The :w splitting happens after interpolation. So « foo $bar @baz » can end up with lots of words, while « foo $bar @baz » is guaranteed to end up with three words. See the comment about 'fabulouser' above and add another 'and fabulouser' to the end. * Multimethed references could be distinghuised either way: bark«Tree» barkDog Good, so those of us who wish to use as much Unicode as possible can do so without having to rewrite the grammar. Excellent ;-) * Match vars become $foo instead of $«foo». * A rule like ident now captures, while «ws» or ws doesn't. I think I really like that last outcome. Capturing should be the default. And the low profile of «ws» makes it look like an oh by the way. Unfortunately the ASCII equivalent doesn't have quite such a low profile, but I think I can live with that, since I can handle «» on all my Perl-coding systems. And the alternatives are still there for those who can't. In many ways this seems clearer than the old way. I like it.
Re: Angle quotes and pointy brackets
James Mastros wrote: Larry Wall wrote: On Fri, Nov 26, 2004 at 07:32:58AM +0300, Alexey Trofimenko wrote: : ah, I forget, how could I do qx'echo $VAR' in Perl6? something like : qx:noparse 'echo $VAR' ? I think we need two more adverbs that add the special features of qx and qw, so that you could write that: q:x/echo $VAR/ where ordinary qx/$cmd/ is short for qq:x/$cmd/ I think I'd like that much better if we consider execution and word-splitting to be the primary operations, and interpolation and noninterpolation the adverbial modifiers then the other way around, making that qx:q/echo $VAR/ or qx:qq/$cmd/. OTOH, I expect backticks to be rare enough that I wouldn't mind writing use Spawn 'spawn'; spawn :capture :wait ($cmd); spawn :capture :wait ('echo $VAR'); Much more clear, saves ` for other things, and allows for easy specification of the many adverbs of spawn (weather it returns the return status, the PID/FH set object, or output, if it waits right there, or runs in the background (and makes the return value lazy), if it replaces the current process (exec)... I'd quite like that. Although I think spawn should be a builtin rather than in a module, if it was in the core, and we were getting rid of backticks. Although I'm masochistic enough that I don't mind the idea of always having to do execution with qx//, qx:q// or qx:qq// (running with other suggestions, I'd guess that would be non-interpolating execution, then the same again more explicitly, then interpolating execution) but I do like the idea of spawn. Kind of removes the idea of pulling in the output of other programs as a fundamental part of the language though, for that it's nice to have an executing, capturing quote. Perhaps an adverb to qx that makes it behave like system() - I don't think it'd be a good idea to provide one that makes it behave like exec(), although perhaps other people do. qx:r/$cmd/ qx:s/$cmd/ # both of these give back return codes? Which one! But then qx:r:qq// might be messy. Or even qx:exitcode:interpolate// Ouch. This isn't very coherent, I'm just thinking out loud based on what other people have said that I like. But there are some things that would be completely ambiguous: %hashfoobar Bracketing operator. %hashfoobaz() Very long bracket operator, which quite likely has a syntax error directly after it. But might not have... there's a chance that could slip through, and I don't like that for some reason. : or maybe even we could see consistant to go after + + and alike, and : make old and written as + and + (and then lt and gt suddenly could : become ~ and ~ :) I think people would rise up and slay us if we did that. We're already getting sufficiently risen up and slain over Perl 6. Could be worse. They could rise from the grave and eat us! Who says they won't? Well, yes, but sometimes the weights change over time, so it doesn't hurt (much) to reevaluate occasionally. But in this case, I think I still prefer to attach the exotic characters to the exotic behaviors, and leave the angles with their customary uses. ...of which they have plenty already. Backtick has exactly one, and not an often-used one at that... I'm fine with axing it. Of course, there are a lot more people in the world then just me. I'm fine with it too. I use it a fair bit but I think it's important to have a very clear mark where you're going to an external program
Re: Lexing requires execution (was Re: Will _anything_ be able to truly parse and understand perl?)
Randal L. Schwartz wrote: Luke == Luke Palmer [EMAIL PROTECTED] writes: Luke But you don't really need to parse to syntax highlight, either. You Luke just need to tokenize. Unfortunately, to tokenize, you also have to know the state of the parse. As long as / is both divide and begin regex, you're toasted. So you're saying that in Perl 6 it will be entirely impossible to determine if / appears as the division operator or as the beginning of a regex from a purely syntactic examination of the source code? I'm finding that very, very hard to believe. Regexps aren't valid where /-the-operator is, after all. Please correct me if I'm wrong, but I've got the impression that Perl 6 is tokenisable without requiring BEGIN blocks to be run - provided no grammars which the tokeniser doesn't already know about are used, of course, that one will never be avoidable.
Re: Lexing requires execution (was Re: Will _anything_ be able to truly parse and understand perl?)
Randal L. Schwartz wrote: Matthew == Matthew Walton [EMAIL PROTECTED] writes: Matthew So you're saying that in Perl 6 it will be entirely impossible to Matthew determine if / appears as the division operator or as the beginning of Matthew a regex from a purely syntactic examination of the source code? Yes. Matthew I'm finding that very, very hard to believe. Regexps aren't valid Matthew where /-the-operator is, after all. And that's precisely why Perl can work as it does. If an operator is expected, / is divide. If a term is expected, / is the beginning of a regex. This has been true since Perl1 (maybe 0). There are a few other characters that also work similarly, but / is the most frequent and most troublesome. And it got worse for Perl5, because of user-defined prototypes, which as far as I can tell, are still present in Perl6. Perl 6 has formal parameters for subs, methods etc. I don't see any mention of Perl 5-style prototypes in S6, and I honestly can't see how they could possibly fit with formal parameters. Hopefully Larry or someone can clarify whether they still exist or not. If they don't still exist, this eases the problem somewhat, but not entirely I understand. Being able to call subs and methods without parentheses around the argument lists causes problems; a quick scan of the updated Synopses failed to reveal the rules for that in Perl 6. Your impression is wrong. In the presence of user-defined prototypes, you *must* execute the code that might alter a prototype in order to determine whether / is a divide (and therefore standalone token) or the beginning of a regex (and therefore must locate the end of the regex to properly be a token). Since Perl 5 style prototypes don't appear to exist anymore, this may be easier. I don't believe that the addition of the // operator compounds the problem anymore, because hopefully by that point it was possible to determine that you've seen an operator. The Perlmonks article throws up a lot of very nasty cases. Not knowing the entire current language definition by heart, I can't say this with absolutely certainty, but I retain the belief that Perl 6 is at least *easier* to deal with than Perl 5. It is also possible that telling the difference between /-as-divide and /-as-regex becomes much easier if lookahead is employed in the tokeniser. Unfortunately, that makes the tokeniser much more complicated, and it's just a vague and random idea.
Re: Lexing requires execution (was Re: Will _anything_ be able to truly parse and understand perl?)
Randal L. Schwartz wrote: Matthew == Matthew Walton [EMAIL PROTECTED] writes: Matthew Perl 6 has formal parameters for subs, methods etc. I don't see any Matthew mention of Perl 5-style prototypes in S6, and I honestly can't see how Matthew they could possibly fit with formal parameters. Hopefully Larry or Matthew someone can clarify whether they still exist or not. As long as you can have a user-defined null-prototyped subroutine (one that doesn't need parens following), you have the problem. See the sin/time examples in the monk article, and then consider user-defined functions that have no args (like time) and those that do (like sin). Matthew The Perlmonks article throws up a lot of very nasty cases. Not knowing Matthew the entire current language definition by heart, I can't say this with Matthew absolutely certainty, but I retain the belief that Perl 6 is at least Matthew *easier* to deal with than Perl 5. I believe you have a false belief. I don't know anything in the new prototypes-which-became-full-formal-arguments that made it any *easier* to recognize the ending of a subroutine argument list without knowing its precise definition. In Perl6: sub no_args () { ... } sub list_args ([EMAIL PROTECTED]) { ... } no_args / # this is a divide list_args / # this is the start of a regex See, it's still there. :) I believe I did mention that being able to call functions without parens is a problem. Matthew It is also possible that telling the difference between /-as-divide Matthew and /-as-regex becomes much easier if lookahead is employed in the Matthew tokeniser. No, not possible at all. The entire rest of the program may be valid either way. You *must* know by the time you're done with /, or /-and-more. The rest of the code cannot be a hint. Again, see my article. I read the article. I believe I mentioned that as well. But I will have to concede that it is impossible to correctly determine the structure of an arbitrary Perl 6 program without having to hand the definitions of all functions used and also any grammars and macros used. Sometimes you will be able to do it, sometimes you won't, but you can't operate on the assumption that you can. It's quite a disappointment in some ways, but we've lived with it in Perl 5, and I'm sure we can live with it in Perl 6. And I still think Perl 6 will have fewer cases in which it's completely impossible for not-Perl to parse it. Unfortunately, fewer still implies some, and some is still a problem.
Re: S13: Deep operators
Luke Palmer wrote: Also, would things blow up if I specified the return types for operator overloads, such as multi sub *infix:+ (EvilNumber $lhs, EvilNumber $rhs) returns EvilNumber is deep { ... } In that case I don't see why it would blow up. If you said, say: multi sub *infix:* (Vector $lhs, Vector $rhs) returns Num is deep { ... } Then you might get into trouble if you did $u += $v Or even $u *= $v :-) Yes, I can see that would be a problem. Care obviously required with the types of operator methods as in other languages. Would that work, would it behave strangely and what would it do to the definition of infix:+= which would be based on it? Is it even necessary? Does it give me anything? And can I overload based on return types? I can't be sure, but I don't think that we're doing MMD on return types. The most compelling reason for that is because you can get yourself into paradoxes that way. I didn't think we would be, as it would be hideously difficult to pick the right method to dispatch to, but I thought I'd check. Thanks Matthew
S13: Deep operators
This is just to clarify something from S13. If I declare, for example multi sub *infix:+ (EvilNumber $lhs, EvilNumber $rhs) { ... } Then if I run my EvilNumber $a; my EvilNumber $b; my EvilNumber $c = $a + $b; I get my code, but $a += $b; Will attempt the default behaviour for +=, which is liable not to work. However, if I alter my operator overload to be multi sub *infix:+ (EvilNumber $lhs, EvilNumber $rhs) is deep { ... } I get *infix:+= defined as { $lhs = $lhs + $rhs; } for free. Is that right? Also, would things blow up if I specified the return types for operator overloads, such as multi sub *infix:+ (EvilNumber $lhs, EvilNumber $rhs) returns EvilNumber is deep { ... } Would that work, would it behave strangely and what would it do to the definition of infix:+= which would be based on it? Is it even necessary? Does it give me anything? And can I overload based on return types? Thanks Matthew
Re: Perl6/Parrot and Backwards Compatability
I suggest you read more about Parrot... it's designed to allow these things. There is a project (Ponie) to make Perl 5 run on Parrot, and there will be other languages as well - which will be able to call each others libraries. Making the Perl 5 libraries available to Perl 6 being a primary motivation. I'm not sure about how well XS will work on Ponie, but I assume that it will be made to work if at all possible. Milscvaer wrote: Hello, I believe it would be a very good idea and quite essential, if Perl6 is not simply a superset of Perl5 and thus by default back compatable with Perl5, for Parrot/Perl6 to also contain complete, 100% backwards compatability capability with perl5 code, either in a seperate perl5 parser distributed with perl6 or built into the perl6 parser. Perl5 code and all of the perl5 language should be able to run on parrot with no modifications. Furthermore, on parrot, modules written in perl 6 should be accessible from perl5 (forward compatability), and perl5 modules should be accessible from perl6 (backward compatability). The symbol spaces and so on so on for Perl5 libraries should be accessible as well from Perl6 and vice versa, as they are now from one perl5 module to another. This is absolutely essential since there is a very large library of existing Perl5 libraries and it would be completely unreasonable to expect all of these to be converted to Perl6, if such would be required. There are alot of us furthermore who like the Perl5 language as it is, quirks and all, and want to continue to be able to use perl5 yet also have access to new libraries written with perl6. perl6 programmers will want to have access to modules written with perl5. Programmers should be able to use both perl5 and perl6 in the same program. Those who like Perl5 as it is should have the freedom to be able to continue to use it on Parrot and have a 100% perl5 compatable language. Every quirk and feature of perl5 really needs be supported in the perl5 support on parrot, as I code I have written really does depend on all of them. Furthermore, it is very important as well that compatabality with the Perl5 internals and XS be maintained on Parrot/Perl6. This is to allow Perl modules for Perl5 to be used from Perl6 programs and on Parrot. If Parrot internals and XS use a different API from the Perl5 ones, then a compatability layer must be provided to allow Perl 5 XS programs to be compiled and run for Parrot. This is very important as there is a very large library of XS modules for Perl5 and it is totally unreasonable to require that they all be rewritten for Parrot to be able to be used. I know the XS interface and the Perl5 internals can be rather ugly, and its fine if Parrot wants to provide an improved API, but its still important to provide a compatability layer for the old one in order to allow compatability with existing modules and prevent unneeded and unreasonable amounts of work it would require, and wasted time, to port old modules to a new API. It would require much less work and effort to simply provide a compatability interface and allow Perl5 XS modules to run on Parrot and to be accessible from Perl6, than to attempt to rewrite all of the modules one would want to have access to on Perl6. Perl5 and Perl5 XS compatability will furthermore prevent the fragmentation of the Perl community into Perl5 and Perl6 camps, by assuring that Perl5 modules can be loaded from Perl6 and vice versa. It also assures that the rich selection of modules and packages avialable for Perl5 will be immediately and instantly avialable from Perl6, thus continueing the inertia generated by Perl5 into Perl6.It allows Perl5 programs to as well benefit from new Perl6 modules, so both Perl5 and Perl6 can be a part of the same community rather than being fractured off into seperate communities. One reason I use Perl is the vast collection of modules avialable from CPAN and the choice in modules. Perl needs to preserve avialability of all of these modules. Remember that a module, or any feature, that is useless to one person is essential to another person. Running the old Perl5 interpretor and the Parrot in the same process is not a great solution, since this would mean that there would be two completely seperate interpretor codebases to support. A big part of Parrot is to allow several languages to use the same interpretor, thus allowing them all to benefit from the same solid foundation. It would be quite ridiculous if Perl did not completely support a past version of itself on Parrot given we are writing parsers for numerous other languages for Parrot (a good idea, indeed, but lets make sure Perl5 has a Parrot parser too). I urge complete 100% Perl5 support including XS and internals to be included with Parrot. This would seem to be a pretty natural feature for Parrot, which is designed to host several language and should also be extended to other languages Parrot supports, why not
Re: Perl 6 Summary for 2004-10-01 through 2004-10-17
Larry Wall wrote: On Tue, Oct 19, 2004 at 09:35:27PM +0100, Matthew Walton wrote: : Austin Hastings wrote: : Does this mean that we're done? :) : : No, it means Larry's about to stun us with something seemingly bizarre : and inexplicable which turns out to be a stroke of genius. The only bizarre and inexplicable thing that has occurred to me in the last week is that I fell into a canal in Venice. It was definitely somewhat stunning, but I have yet to figure out how to view it as a stroke of genius. I suppose if I were Archimedes I'd have climbed back out and shouted Eureka, but as far as I know Archimedes never made it to Italy, so it didn't occur to me... That's not what I was thinking of. Also, climbing back out and shouting 'Eureka' would only really be appropriate if you actually had experienced a moment of revelation about something. I suspect you were too busy with the not drowning part for that. Youch, anyway.
Re: Perl 6 Summary for 2004-10-01 through 2004-10-17
Austin Hastings wrote: Michele Dondi wrote: On Sun, 17 Oct 2004, Matt Fowles wrote: Google groups has nothing for Perl6.language between October 2 and 14. Is this really the case? (I had not signed up until shortly before Yes: no traffic at all for quite a while... Does this mean that we're done? :) No, it means Larry's about to stun us with something seemingly bizarre and inexplicable which turns out to be a stroke of genius. At least, I hope that's the case. Life's been so dull lately I've even applied to do a PhD.
Re: A..Z alternatives
Andrew Rodland wrote: On Tuesday 21 September 2004 07:18 pm, Thomas A. Boyer wrote: Larry Wall wrote: Somebody needs to talk me out of using A..Z for the simple cases. Larry [ for array dimension placeholder ] That might confuse users of languages that were not C-syntax-influenced, who think that '**' means not equal. But surely old Modula hacks like me are in a minority in the Perl world (and Pascal programmers would never do Perl, would they? Algol, anybody?) So maybe I'm the only one who runs the risk of that particular confusion. :-) What about BASIC? Aren't all the little kids today raised on BASIC? :) Only if their parents are evil... I was raised on BASIC and look what happened - now I'm writing Perl Quiz of the Week solutions in Haskell!
Re: Synopsis 9 draft 1
Michele Dondi wrote: On Thu, 2 Sep 2004, Larry Wall wrote: To declare a multidimensional array, you add a shape parameter: my num @nums is shape(3); # one dimension, @nums[0..2] my int @ints is shape(4;2); # two dimensions, @ints[0..3; 0..1] Just a random thought, and probably a minor point: I know that there already so many keywords, but if not already taken, could Chas be introduced as a synonim for Cis to be freely used where it would fit better? Especially in constructs like my num @data is Stuff has shape(4;2); Chas is already used to give classes attributes... class Thing { has @.fingers; has $.mysteriousness; } I wouldn't be surprised if it does run-time attribute addition to objects as well, but I can't recall seeing that anywhere and haven't got time to look right now. Even if it doesn't, it would, I think, be a mistake to overload it in this way.
Re: A thought for later -- POD tables
Aaron Sherman wrote: =table C$_ | C$x | Type of Match Implied | Matching Code =row Any | CodeC $ | scalar sub truth | match if C$x($_) That's (the above comments aside) the same thing, and as I said when Luke suggested it, it seems fine if that's the way we'd prefer to go. I do want to make sure that there's some way to associate a caption, though. HTML doesn't have a real caption concept, but many markup languages do. Yes it does. There's a CAPTION element for tables in HTML 4.01/XHTML 1: http://www.w3.org/TR/html4/struct/tables.html#h-11.2.2 Is the general consensus,then, that an C=-introduced form would be better? I do agree that we don't want the capability to nest tables, as that DOES break POD down into a presentation system, which it was never meant to be. So perhaps the balanced syntax is too misleading there. I like the =table =row form. Sufficient syntax for laying out simple tables without letting people do silly things.
Re: Instantiation
Aaron Sherman wrote: I was thinking about the case where you use a module, only to define a class that you then instantiate like this: use Some::Module::That::Defines::A::Class; our Some::Module::That::Defines::A::Class $foo := new; and I keep thinking that that's too redundant. It's not so much that I want to syntax-golf it down, but there's just no reason to throw that type around twice, when what you really WANT to say is that module over there is a class, instantiate me one. So, I was wondering about a synonym, like: uses Some::Module::That::Defines::A::Class $foo; syntax will be awful and there are a lot of guesses, but: macro uses($class, $var) is parsed(/(classname) (scalar)/) { use $class; our $class $var; } I suspect. It's probably not quite that simple, but I figured it was worth a shot. Hopefully the compiler would run through the result of the macro, parse it and compile it as normal so the Cuse would actually work. Okay okay, I just got a copy of Perl 6 and Parrot Essentials and I'm trying to learn stuff. I'm even ripping apart the compiler I wrote for my BSc final-year project so it generates working PIR instead of broken C.
Re: Return with no expression
Alexey Trofimenko wrote: On Fri, 20 Aug 2004 09:21:02 +0100, Matthew Walton [EMAIL PROTECTED] wrote: On 19 Aug 2004, at 18:04, Luke Palmer wrote: [...] my $num = $param == 0 ?? 0 : rand $param; my $num = $param == 0 ?? 0 :: rand $param; surely? a little off theme.. I wanna ask, could be there in perl6 any difficulties with recognizing C:: as part of C... ?? ... :: ... and C:: as module sigil? Does it involve some DWIM? Would we have mandatory space after C?? :: ? I didn't get perl6 syntax well yet, so if it's true, you can give better examples yourself.. I doubt that's a problem, as C:: as part of the ternary operator is only going to be found where an operator is expected, and C:: as part of a module name is only going to be found where an identifier is expected, so it's a matter of looking for different things in different places, I suspect. And if this message comes out with strange and stranger formatting, that's because Thunderbird's doing some very odd things in the compose window and I'm not entirely sure how it's going to come out.
Re: Return with no expression
Larry Wall wrote: On Fri, Aug 20, 2004 at 09:21:02AM +0100, Matthew Walton wrote: : It would be nice if rand behaved a bit more sanely in Perl 6. I can : understand the reasoning for making rand 0 produce between 0 and 1, but : that doesn't mean I have to like it. What makes you think there was any reasoning involved? As far as I can recall, it was entirely due to random factors. :-) Sush, I'm giving you credit from pure blind faith here ;-) I suspect there's an argument that [0,0) ought to be considered undef (which would conveniently numerify to 0 with an optional warning). In the absence of a paradox value, undef would be fine there I think :-)
Re: Return with no expression
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19 Aug 2004, at 18:04, Luke Palmer wrote: The one in Perl 5 that stands out most was the cause for the only patch I ever sent to p5p: the rand function. rand $x will give you a uniformly distributed random number in [0, $x) for any $x EXCEPT 0. If you say rand 0, it gives you a random number between 0 and 1, which was supposed to be What I Meant. That led to code like this (Perl6ized as usual): my $num = $param == 0 ?? 0 : rand $param; my $num = $param == 0 ?? 0 :: rand $param; surely? Repeating the test that it did itself, just to get consistent behavior. We must be careful not to repeat mistakes like this in the design of Perl 6 [1]. It would be nice if rand behaved a bit more sanely in Perl 6. I can understand the reasoning for making rand 0 produce between 0 and 1, but that doesn't mean I have to like it. If that behaviour is required, then rand undef; would behave as expected (call with no parameters to get [0, 1), with one param to get [0, $param) ), but really if you want a random number between 0 and 1 why aren't you calling rand 1? Feels like a Cism. Ick. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQFBJbRx0UvYjCBpIlARAjV2AJ0TSuchOHcVMqg3HUPLJ6G5zhnRYwCfQ/26 C6DCRHq0BjxqX4eH5vUeWwk= =ctmb -END PGP SIGNATURE-
Re: Mailing list archives
Joe Gottman wrote: There's something wrong with the mailing list archives at http://dev.perl.org/perl6/lists/. I can get to this page OK, but when I click on a link to the perl6-internals or perl6-language archives, I get a This page cannot be displayed error. The perl.org list server's been having some fairly serious trouble, according to what I read on Planet Perl. That would probably also explain why the list has been so quiet lately.
Re: xx and re-running
Larry Wall wrote: The rand function may be a bad example, since it's by nature a generator, and you should maybe have to work harder to get a single value out of it. We haven't really said what $fh xx 100 should do, for instance. I guess the real question is whether xx supplies a list context to its left argument (and whether rand pays attention to list context). These might produce very different results: @foo = (rand); @bar = (+rand); On the other hand, history has rand producing a scalar, so arguably we should stick with that. One supposes that it's not entirely unreasonable to have rand in list context produce an infinite (lazy) list of random numbers, successively drawn from the generator. The results of @foo = *(rand); (if the syntax is right) in that case would of course be in the 'enough rope to hang yourself' category. But it might be handy to be able to say my ($rand1, $rand2, $rand3) = (rand)[4..6]; although I'm sure some would argue that this is needlessly obfuscated, and that my ($rand1, $rand2, $rand3) = (rand, rand, rand); would be better. Maybe it would. This random thought was brought to you by the demons of lunchtime idleness.
Re: definitions of truth
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Hodges wrote: | --- Luke Palmer [EMAIL PROTECTED] wrote: | |Paul Hodges writes: | |So, in P6: | | if 0 { print 0\n; } # I assume this won't print. | if '0' { print '0'\n; } # I assume this won't print. | if ''{ print ''\n;} # I assume this won't print. | if undef { print undef\n; } # I assume this won't print. | |But my question is, will this: | | if \0 { print null\n; } # Is this going to print, or not? | |As far as things are currently defined, yes, it will print. And your |syntax is perfect... well, maybe not: | |if undef { print undef\n; } | |Might be interpreted as: | |if undef( { print undef\n; } ) # syntax error, expecting { | |But close enough anyway. | | | Maybe I should have been more specific: | | if undef() { whatever(); } | | But it's a moot point, since only a moron would test what he knowks the | answer to -- unless it's one of those wierd cases, and then he could | just use 0 instead.. | | So, putting it back into the context of real things. | | |If you must check for a null byte, it's as simple as: | |unless $chr { print 0, '', or '0' } |unless ord $chr { print null byte } | | | So a null byte is still Boolean true. | Ugh, yarf, ack, etc. | | But as long as I know -- easy enough to check explicitly. | | But just tell me thisam I the only guy who thinks this *feels* | wierd? Understanding the reason doesn't make it any more ~comfortable~. I think it feels fine. The weirdness comes from the difference between string context and numeric context I think - like with '0' being false and '0.0' being true in string context, but if you converted them both to numbers they'd both be false. This is why Perl 6's explicit typing will be such a Good Thing. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA2/4E0UvYjCBpIlARAor4AKCjsHZBmLqnKwDt2kMINwAS0ZMBFQCeIup3 20Jlgv0D/WQt+sRjHhGuAbQ= =Tl+q -END PGP SIGNATURE-
Re: user-defined operators?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michele Dondi wrote: | I don't know if this is already provided by current specifications, but | since I know of Perl6 that is will support quite a powerful system of | function prototyping (signatures?), I wonder wether it will be possible | to specify a (finite number of) argument(s) on the left of functions, thus | allowing to create user-defined operators. I had tried sml (a functional | language) and despite its being really simple if compared to Perl, it | provided this functionality... If SML is anything like Haskell, user-defined operators are really just syntactic sugar around normal function definitions, with appropriate allowances in the grammar for arbitrary operators to exist and be parsed correctly. Haskell also has an interesting backticks operator, which turns any two-argument function into an infix operator, and is generally used for readability purposes. Thus, although you can do modulus with the 'mod' function like this: mod 3 4 you can also write 3 `mod` 4 which can be handy when trying to get an arithmetic-type feel to your programs. I doubt Perl would need something like this though. Haskell of course also lets you do things like infixr 3 +++ which defines a right-associative infix operator at precedence level 3, denoted by the token '+++' and later you can say something like (+++) :: Num a = a - a - a x +++ y = x + y which defines the +++ operator to have exactly the same effect as + (although probably with different precedence, I have no idea what the numeric precedence level of + is in Haskell, and indeed if + is right or left associative, as I always get those two muddled up, so that might be different too) when applied to numbers. Pretty pointless really, unless you wanted a tight-binding + or a backwards one, but you get the idea. Most combinator parsing libraries use user-defined operators to denote parser combination and choice, and GUI libraries tend to use them to denote things like signal connection, property setting and so forth. Wrangling this back to some sort of on-topicness, it would be great if Perl could have user-defined operators that actually work properly. I'm thinking new operator characters (Unicode's got lots left), and also the ability to define short-circuit operators like C's and || (I can't remember what they've become in Perl 6, did they change? I seem to remember them changing). Not being able to do this is a major weakness in C++'s operator overloading, because it effectively means that and || are untouchable unless you really want to mess with other people's heads, and demonstrate the only point operator overloading has against it (that is the potential disruption of expected semantics; this is all IMO of course). So can we at least have the ability to define short-circuit operators, even if we can't define new ones? -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA2rP20UvYjCBpIlARAsFKAJoCBjgP8+wmbQP3XO1HLD+6AC43DQCfVvj3 kTT9cYnblCADyVCWCrpcpD0= =G7FE -END PGP SIGNATURE-
Re: Semantics of vector operations (Damian)
Austin Hastings wrote: Perhaps we could consider the junctive lvalues as a sort of implied ?= operation: junction(@list) = value means unless junction(@list) == value { given junction { when 'none' { (@list.grep value) = undef; } when 'any' { for 0 .. random(@list) { @list[random(@list)] = undef; } } when 'one' { @list[random(@list)] = undef; } when 'all' { @list = $(@list) x undef; } } } (which would make for some interesting use cases around 'any', at least ;-) This is extremely scary. The thought of anybody actually using 'any' in their code is... umm... well, let's just say the Haskell programmer me is curling up in fright and screaming his head off, because the idea is entirely abhorrent to him. Gadget Matthew says it's a substanceless 'wow' feature. Both are also skeptical about 'one', and my psychiatrist is rattling pill bottles. 'none' could be useful, but it would be better to explicitly just say (@list.grep value) = undef although I think that might be supposed to be (@list.grep value) »= undef; as shouldn't list.grep return a list of matches? Which we assume are aliases to the original elements. I'm with Damian. TMTOWTDI yes, but there's a line between 'nice to have the alternative' and 'silly'. Oh, and the example appears to have forgotten that only 'none' should be assigning undef, the rest should be assigning value - shouldn't they? I think they should, otherwise it doesn't make any sense at all. Or perhaps it does, and I need to go to bed. Ciao.
Re: Semantics of vector operations (Damian)
Mark J. Reed wrote: On 2004-06-14 at 22:58:58, Matthew Walton wrote: 'it would be better to explicitly just say (@list.grep value) = undef although I think that might be supposed to be (@list.grep value) »= undef; Those do different things according to my understanding. The first removes all matching items from the list; the second replaces the matching items with undef. e.g. (please forgive any Perl6 syntax errors): [1,2,3,4,5].grep { $_ % 2 } = undef results in the list [2,4] while [1,2,3,4,5].grep { $_ % 2 } »= undef results in the list [undef, 2, undef, 4, undef] That's a very good point, and seems rather likely. I wasn't thinking of it that way. Quite cunning really.
Re: Apocalypse 6: IDs of subroutine wrappers should be objects
Ingo Blechschmidt wrote: Hello, quoting Apocalypse 6: You may ask a subroutine to wrap itself up in another subroutine in place, so that calls to the original are intercepted and interpreted by the wrapper, even if access is only through the reference: $id = $subref.wrap({ # preprocessing here call; # postprocessing here } [...] The $id is useful for removing a particular wrapper: $subref.unwrap($id); One should be able to unwrap $subref using $id.unwrap(); Something tells me that you shouldn't be able to do that. Wrapping is an operation on the subref, which implies very strongly to me that unwrapping should also be an action on the subref. Or, given $id, it'd be cool if you could get the original $subref: my $origsubref = $id.sub(); Additionally, $id could coerce to an ID number in numeric context, so $subref.unwrap($id); would still be valid code (== TIMTOWTDI). At the very least you'd have to be able to do that as well, I get this uneasy feeling about having to do $id.unwrap();. unwrap would be the wrong method anyway - it implies unwrapping $id itself, which seems wrong because $id isn't wrapped, it's wrapped around something else. Maybe $id.remove() or $id.tear_off() or $child.give_present($id), which would cause unwrapping to happen very, very quickly and messily. On the other hand, what happens when you call $id.unwrap() (or $subref.unwrap($id)) if $id is an object? What happens to $id? Does it turn into some kind of limbo object? Does it become undefined? Is it right for $subref.unwrap($id) to be able to do that to $id? Is it right for $id to be able to do it to itself? Hmm. Not a very useful email really. Oh well. It's too hot to think straight.
Re: Periodic Table of the Operators
Mark Lentczner wrote: All - Awhile back, I saw Larry Wall give a short talk about the current design of Perl 6. At some point he put up a list of all the operators - well over a hundred of them! I had a sudden inspiration, but it took a few months to get around to drawing it... http://www.ozonehouse.com/mark/blog/code/PeriodicTable.html Now that is truly a work of art. I look forward to seeing it evolve (and the corrections already suggested being made). And I can also see myself printing it out and putting it on the wall for use the moment I can get my hands on a Perl 6 compiler. Finally a use for the colour laser printer in the office... Well done.
Re: Yadda yadda yadda some more
I actually find myself having somewhat coherent thoughts on this matter. Apologies if they seem rather obvious or naive, but I'm still new to all this. Dov Wasserman wrote: my $id = ...; my Int age = ...; my Str $name = ...; my DbHandle $db = ...; my Int of Hash @array = ...; Therefore, the compile-time type of the term must be assignment-compatible with any and all lvalues. This will have to be true at least in those contexts that ask for strict type-checking, even if other scopes don't care. This reminds me of Java's Cnull literal reference value which can be validly assigned to any reference type. (Technically, it's not a keyword, but try giving that answer on an interview at your own peril.) I don't see any functional problem with this special property as long as it can be implemented in the core language. Seems like it would have to be a special rule of type checking. So we'd have generic Scalar as the universal recipient, and now the Yada literal as the universal donor. (Any association of strong type-checking with the extraction of blood is purely imaginary. As far as the compiler's concerned at that point, it might behave something like Cundef. For the purposes of the type checker that would probably be sufficient. Worrying about the actual value wouldn't be a problem until runtime, at which time it's quite safe for C... to do what it's supposed to do and complain. [Special Property #2] As mentioned in A6, redefining a function (subroutine, method, etc.) which has only been declared with the Yada Yada Yada closure does not generate a warning. It seems like Perl 6 will have to take some special note, then, when we declare a function as: sub foo($bar, $baz) {...}; # pre-declaring sub foo() as opposed to: sub foo($bar, $baz) { die }; # defining sub foo() to throw an exception (mod throwing syntax) so that the first case can be redefined without a warning, while the second case would warn on redefinition. I would guess again that the body of the sub not being actually executed until the sub is called means that C... passes through the compile phase without a problem. The compiler would have to special-case it though, to allow the redefinition. I'm going to assume that if you tried my Int $number = ...; $number = 5; it would still die at run time on the first C I really hope it would anyway, because if you really want to do something like that we've already got Cundef. [Question #1] I'd like to understand how Aaron Sherman's initial example would work: class Foo { has $.a; has $.b; ...; } We know that the class will compile fine, but when exactly would it pitch a fit (or exception)? I'm unsure of the meaning of this idiom, because the only time the C... line gets evaluated is at class compilation time, which is when we don't want any complaints in this case. I thought class closures 'ran' at object creation time. I'm probably wrong about that. Object creation time would be a good time for that particular yada yada yada to start complaining though. I suspect C... is going to be considerably more sophisticated than a macro that replaces it with C{ die }. [Question #2] Does C... know when it's being called during compilation and when it's being used at run-time? I.e., how would it behave in a compile-time block such as BEGIN: BEGIN { our IO $server = ...; }; The rhs value is evaluated here at compile-time. Is C... smart enough to know that and keep quiet? I would expect that to run and complain at compile time. That might be irritating, but I'm not sure how else it could be done, because BEGIN blocks are run then, and when they're run you need to know what values you're going to assign to the variables. Unless you gather it up inside some sort of lazy evaluation construct that keeps delaying the evaluation of it until you hit run phase, at which point you've probably got the entire BEGIN block ready to go, with everything that comes after it also hanging around, and... no, doesn't sound good does it?
Re: Yadda yadda yadda some more
Austin Hastings wrote: I think of this as very much like the typed-undef we discussed last month or so: ... should return an unthrown exception wrapped in undef-ness. The type returned by ... should just have a multitude of type-casting tricks associated: my int $i = ...; # Fails at compile time -- no good conversion. my Int $i = ...; # Warns at compile time, fails at runtime. I don't get the reasoning here. If Yada Yada Yada is to indicate code that you haven't written yet, it should never fail at compile time unless it's impossible to compile the program without knowing what that code is, so my int $i = ...; should compile. The problem would arise when you actually tried to run that particular bit of code, which may well look to Parrot like 'die horribly'. If Yada Yada Yada is not to indicate code that you haven't written yet, then what is it really for? I would guess again that the body of the sub not being actually executed until the sub is called means that C... passes through the compile phase without a problem. The compiler would have to special-case it though, to allow the redefinition. Perhaps not. If {...} evaluates to C(Code)(undef but something), the transition from Cdefined(foo) == FALSE to Cdefined(foo) == TRUE might not be grounds for a redef warning. That would make sense... if ... gave you an indefined code block (rather than code which returns an undefined value, which we all know and love, or at least I love it), it would actually make a LOT of sense. I'm going to assume that if you tried my Int $number = ...; $number = 5; it would still die at run time on the first C I really hope it would anyway, because if you really want to do something like that we've already got Cundef. This is wrong. The purpose of Cundef is I declare that I've thought about the issue and at this point in the code $number should have no value. The purpose of C... is I declare that there should be something here, but I haven't thought about it yet. IOW, C... is a form of literate programming that's relatively self-explanatory and highly compatible with Agile development: class foo { has $.x = ...; method bar() {...} method baz($a) { if ($a) { .bar(); } say Hello; } } class foo_test { is UnitTestCase; has $.foo; method test_empty_baz() { $.foo = new foo; $.foo.baz(undef); } } This code should work okay -- no Yadda ever gets executed. Then when I add: method test_valid_baz() { $.foo = new foo; $.foo.baz(1); } there should be a failure, because $.foo.baz calls $.foo.bar, which is defined C{...}, which evaluates to an unspecified value exception. Yes, that's more or less as I would expect it to work. I thought class closures 'ran' at object creation time. I'm probably wrong about that. Object creation time would be a good time for that particular yada yada yada to start complaining though. I suspect C... is going to be considerably more sophisticated than a macro that replaces it with C{ die }. I think the metaclass class assembler function will behave like this: If only a Yadda is provided, just return a typed Yadda object. If anything other than a Yadda: If you provide a definition of any name, it goes in. If you provide a Yadda, it gets recorded. When wrapping up, if any methods are provided, then a special yadda-on-not-found dispatcher is provided. If no methods are provided, a special yadda-on-not-inherited dispatcher is provided. A similar data member access is provided. So that: class Foo { has $.a; has $.b; ... } Becomes: class Foo { AUTOMETH { if inherited($method_name), run it. else return sub {...}; } has $.a; has $.b; AUTOMEMBER { if inherited($member_name), return it. else return \...; } } So you can have objects made from class Foo, but if you try and get at a method which doesn't exist you get Yada instead of 'that method doesn't exist'... that makes sense, I think, because you can use any method names you like in your code, and the effect is basically 'this method hasn't been written yet'. I would expect that to run and complain at compile time. That might be irritating, but I'm not sure how else it could be done, because BEGIN blocks are run then, and when they're run you need to know what values you're going to assign to the variables. Unless you gather it up inside some sort of lazy evaluation construct that keeps delaying the evaluation of it until you hit run phase, at which point you've probably got the entire BEGIN block ready to go, with everything that comes after it also hanging around, and... no, doesn't sound good does it? Again, I like it. A partially defined object isn't fatal unless you actually need that part. If Yada is actually a value with a special type as you've said here, then it falls out quite well. You can put it into anything you like, you just get a
Re: Yadda yadda yadda some more
[EMAIL PROTECTED] wrote: Austin Hastings wrote: my int $i = ...; # Fails at compile time -- no good conversion. my Int $i = ...; # Warns at compile time, fails at runtime. I don't get the reasoning here. If Yada Yada Yada is to indicate code that you haven't written yet, it should never fail at compile time unless it's impossible to compile the program without knowing what that code is, so my int $i = ...; should compile. The problem would arise when you actually tried to run that particular bit of code, which may well look to Parrot like 'die horribly'. Or. not so horribly. If I'm in the perl debugger, I'd want that to be a breakpoint and give me the option to type in a evaluable string to replace it. So it should throw a properly marked exception that an outer context can do something with. Good point.
Re: Yadda yadda yadda some more
Larry Wall wrote: On Wed, May 12, 2004 at 11:37:44PM +0200, Juerd wrote: : Aaron Sherman skribis 2004-05-12 17:30 (-0400): : I like C... I like it a LOT. In fact, I'm partial to the idea that : it should be usable anywhere : : I agree. It'd make even more of my pseudo code (#perlhelp and : perlmonks.org) valid syntax :). Er. Why are you guys using the subjunctive? Straining my brain to remember what the subjunctive is (and I only ever learned it in German anyway), does that mean that this use of yada yada yada is already decided on and allowed? If so, fantastic.
Re: C style conditional statements
Stéphane Payrard wrote: Le Wed, May 12, 2004 at 02:00:42AM +0200, le valeureux mongueur Pedro Larroy a dit: Hi Is there any chance that in perl6 there will be the possibility to write if/else statements without {}s with the condition at the beginning? Like if (condition) statement; In order not to break traditional C culture. Is there any technical reason why it wasn't done in perl5? In Perl5, variable declaration are an executable statement. Also the scope of a variable starts from its declaration and ends at the end of the immediately enclosing block. Things would get problematic if the branches of an if/else were not scoped. What would be the meaning of : if (condition) my $foo = 'bar'; else print $foo; Not entirely sure, but according to the camel book, another reason for the braces being compulsory is that Perl makes a distinction between a block and a statement, whereas in C a block is actually (sometimes) a kind of statement - indeed a compound statement. Of course, it's possible that was just an excuse, but it does make a fair bit of sense. Especially since Perl's got things like anonymous subroutines and closures, which are sort of fancy blocks, and ultimately one has to realise that { and } don't mean the same thing in Perl at all. They just *look* like they do. I am actually glad to see Perl 6 extending this trend, as it seems to be using { and } for Good Things. I wouldn't argue at all that it's important to keep familiarity for C programmers anymore (so sayeth the Haskell programmer), although it might perhaps be a little early to go for Python-like syntax. For some reason, lots of people don't like it when indentation is what's controlling their code structure...
Re: C style conditional statements
Larry Wall wrote: On Wed, May 12, 2004 at 09:47:04AM +0100, Matthew Walton wrote: : For some reason, lots of people don't like it when indentation is : what's controlling their code structure... Indentation is a wonderful form of commentary from programmer to programmer, but its symbology is largely wasted on the computer. We don't tell poets how to format their poetry. When you put it like that, I'm almost converted. My favourite language that does indentation as syntax is Haskell - where it's optional, so I'm not really all that passionate about it. I just don't mind it.
Re: A12: default accessors and encapsulation
Mark J. Reed wrote: Let me just chime in with my support for John's basic idea. I would definitely prefer that it be easy to arrange things such that $obj.foo = 'bar' winds up invoking a method on $obj with 'bar' as an argument, rather than invoking a method on $obj that returns an lvalue to which 'bar' is then assigned. (Yes, like Ruby's def foo=; I have a Rubyometer and I'm not afraid to use it!) It doesn't need to be the default rw accessor behavior, but I would like it to be accomplishable without jumping through a lot of hoops. -Mark It sounds a lot like C#'s properties, which are in my opinion one of the best things in C#. Nice easy syntax for those as well, although I can't remember it well enough right now to give an example, as I don't generally keep a C# reference lying around at work where I never use it. Effectively though, if you have an object foo with a property bar, things like foo.bar = 5; seem to get turned into foo.set_bar(5); where set_bar() was pulled from the property declaration's set {} block, where some magic goes on. However, it would appear that what John is asking for is already possible, just not necessarily particularly obviously, as returning a proxy object to act as the lvalue and then do the appropriate magic would work, but seems a little mucky. Even if that's what happens behind the scenes. On the other hand, just as a thought from a crazy C++er, couldn't you accomplish a similar effect by defining your $.foo attribute to be of a custom class, then overriding the = operator for that class... I know, messy messy. Don't go that way. I shouldn't even have thought of it.
A12: Mutating Methods and hyperoperators
I know these were discussed to death not that long ago, but reading Apocalypse 12 I had a query I couldn't remember if it had been covered before or not, and I certainly don't recall seeing it in the Apocalypse, although I've not read the entire thing with as much attention as I might like yet (it's great work though). So, simple query. I know I can do @things».method(); But can I do @things».=method(); which would presumably be the same as map { .=method() } @things; And if I can't do it, why not? I think I should be able to do it, but it's entirely possible I've missed something, because I usually have. Thanks Matthew
Re: A12: Mutating Methods and hyperoperators
Luke Palmer wrote: Matthew Walton writes: But can I do @things».=method(); Of course. Excellent. Thankyou. Not this time :-) Next time then, probably.
Re: backticks
Juerd wrote: Sean O'Rourke skribis 2004-04-15 8:55 (-0700): I find that there are still plenty of contexts in which `` is nice and security is irrelevant. This is the second time in this thread that I read about security being unimportant. I still don't know what to say about it, though I feel like ranting. Security is of course extremely important, but changing a language so that doing anything insecure becomes impossible or at least extremely difficult strikes me as a bit too much nannying. One should of course never accept user input without validating it first - especially stuff coming in over a network - but once you know what's in it, there's nowt wrong with interpolating that into a `` or qx// kind of structure. Well, other than the usual mistakes you can make by forgetting how it's going to interact with the shell, but this really doesn't bother me in the slightest. And as has been said, there's a vast amount of one-liners and short utility scripts out there which use backticks quite happily and safely. As with many things, they're only dangerous if you don't know what you're doing. Probably you know when you can use qx safely, but many, MANY people out there have no clue whatsoever and use qx with interpolation *because* it is easy. Which is exactly why I use it. I'm just not foolish enough to trust the variables I'm interpolating into it unless I've constructed them entirely myself and I know the code that constructs them is bug-free. Having said all that about lack of knowledge though, I'm sure everyone on this list knows about how to deal with tainted data and such things, but there are a lot of fresh Computer Science graduates and other people learning programming who never hear a thing about it. I don't see that as an excuse to turn Perl into a hand-holding nanny language though.
Re: backticks
Juerd wrote: chromatic skribis 2004-04-14 12:32 (-0700): That's exactly my objection to this idea. I think it goes too far to make simple things simpler while making complex things impossible. Absolutely false. This is an addition to the already existing {}, which should stay. %foo{ something } will still be necessary if: * the key is the result of an expression * you want a slice * the key is not a string * the key is a string that isn't simple enough (i.e. contains \W in a way that isn't supported) I really don't want to explain why there are two hash key access mechanisms, one that only works for single keys that match a very simplified regular expression and one that works for one or many hash keys with no restrictions. There are already two. One that works with expressions and one that works for one or many hash keys as long as they are literals. %foo$bar doesn't quite do the same as %foo{$bar}. That's one method, really - being like {' '}, and really just carrying on the very familiar idea of different kinds of quotes. Like ' and . The ` idea is completely different. Also, ditching `` quotes strikes me as a fairly dreadful idea. I for one use them almost perpetually. Yes, I could use qx// instead, but I could also use qq// instead of . Ultimately, ` looks like an opening quote character, and so people will expect it to behave like one. I think that violates the principle of least surprise.
Re: Compatibility with perl 5
Mark J. Reed wrote: On 2004-04-13 at 13:16:02, David Cantrell wrote: Perl 6, we are promised, will try to run legacy code unchanged. How will it spot such legacy code? My understanding has been that perl6 will assume a program is Perl 5 unless it sees a Perl 6 keyword such as 'module' or 'class'. That could be problematic, because if Perl 6 sees something like: my %myhash; %myhash{'foo'} = 'bar'; Is it going to think 'ahah, perl 6' or 'perl 5 with errors'? That's assuming my understanding of hash subscripting and variable declarations in Perl 6 is even slightly correct, of course.
Re: Compatibility with perl 5
Thomas A. Boyer wrote: Matthew Walton wrote: That could be problematic, because if Perl 6 sees something like: my %myhash; %myhash{'foo'} = 'bar'; Is it going to think 'ahah, perl 6' or 'perl 5 with errors'? It's going to think 'ahah', perl 5'. Because it doesn't contain any Perl 6 keyword (such as 'module' or 'class'), as Mark said. But then trying to process that as Perl 5 will result in an error. This doesn't seem particularly sane to me. Will we have to say use 6; on all Perl 6 programs to avoid this kind of thing? Forgive me if I'm missing something obvious here.
Re: Compatibility with perl 5
Thomas A. Boyer wrote: The original question was how do I label my code as Perl 5? The correct answer, according to Apocalypse 1, is to start your source with package. If you didn't want to put your code in a package, then start it with package main. The other question was how do I label my code as Perl 6? The correct answer, according to Apocalypse 1, is to start your source with module or class. Here is the relevant paragraph from the apocalypse: I hereby declare that a |package| declaration at the front of a file unambiguously indicates you are parsing Perl 5 code. If you want to write a Perl 6 module or class, it'll start with the keyword |module| or |class|. I don't know yet what the exact syntax of a module or a class declaration will be, but one thing I do know is that it'll set the current global namespace much like a |package| declaration does. Righty-ho then. That's not actually all that bad, I'm used to starting files with 'module' in Haskell (where it's not always compulsory but is a good idea) so I'm sure I can cope with a similar thing in Perl 6. Thanks
Re: Funky «vector» operator
Robin Berjon wrote: Specifying the OS is not enough, you need at least the keyboard layout. It would be impossible to have shortcuts involving | or \ on a French keyboard since they are respectively Alt-Shift-L and Alt-Shift-: OS X / iBook / fr-fr « Alt-è » Alt-Shit-è Good point. I tend to be a bit shortsighted on things like that. OS X / Powerbook / en_GB « Option-\ » Option-Shift-\
Re: Mutating methods
Larry Wall wrote: On Thu, Mar 11, 2004 at 01:18:52PM -0800, chromatic wrote: : On Thu, 2004-03-11 at 13:04, Larry Wall wrote: : : Well, okay, not a boolean. More like a troolean. : : Unless it's a falselean. It's more truelean than falselean by a 2/3rds majority. And it's much more if you include 2, -2, 3, -3,... in the data type. And it's *very* much more if you include the reals So that's a (numeric) scalar then... I'm new to this list, although I've been keeping an eye on Perl 6 for quite a while now as it's looking like it's going to be an extremely pleasant language to work with. Seems I joined at the right time as well, for these mutators are an interesting thing. Please excuse my no doubt numerous abuses of conventional formatting used here as I don't know it yet, and I've got a very shaky knowledge of some parts of the Perl 6 grammar that everyone posting seems to know. However, it strikes me that notation like int method =foo(String $bar) {...} is at risk of causing serious confusion to people coming from other languages. This may not be a concern, of course (and isn't really one of mine despite being a C++/Perl 5/Haskell kind of person at the moment). It seems that int method self:foo(String $bar) {...} is clearer and easier to read, but I did actually prefer int method mutate:foo(String $bar) {...} or int method inplace:foo(String $bar) {...} which seem to have been dismissed in favour of the form using Cself, although I can see that it does have a valid interpretation. Perhaps I'm just too stuck in writing member subs of objects in Perl 5 by saying sub foo { my $self = shift; # something useful here } so I always see 'self' as reading something like 'this' does in C++ or Java (or as 'self' does in Python, if I'm remembering that correctly). There is undeniable logic in using it to define mutators though, as they do most certainly act upon 'self' or 'this' or whatever it's called. One is lead to wonder if the most appropriate definition might not be int method mutator:foo(String $bar) { ... } but that's getting very silly, so maybe just ignore everything I said just now and cheer the introduction of Cself as the most practical and least prone to the introduction of finger trouble. And having said all that, I like .= as invocation syntax for it, even if I keep thinking it means 'append string'. Anyway, thankyou for listening, I shall return now to watching in awe. Matthew