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: S26 - The Next Generation
Aaron Sherman asked: Should there be an explicit way to step this down to just parsing the bits that are called out as pod? The original conception allowed for Pod to be independent of the interleaved language. That has now been supplanted by a model that views Pod as an integral part of Perl. There's definitely a trade-off there, but one we've decided to make. So, no, there are no longer any plans to extend Pod to documenting *everything*, except so far as Perl 6 will be ale to subsume everything (in line with Larry's musings of braided languages). There is no explicit mention in the document as to what happens at the Perl level when the closing bracket is reached at a point that is not the end of a line (i.e. it is not followed by whitespace that contains a newline character). Here's an example: my $a #-[stop the presses!] = 4; Except for the #~ instead of #=, that's valid (and documented) Perl 6. That is, Pod comments work exactly like non-Pod comments. As Synopsis 26 now states: That is, declarator Pod blocks are syntactically like ordinary Perl 6 single-line comments and embedded comments. * This new declarator block form is special. During source code parsing, normal Pod blocks are simply appended into an array attribute of surrounding Comment object in the AST (which is just $=POD, at the top level). However declarator blocks are *also* appended to the .WHY attribute of the declarator at the start of the most recent (or immediately following) line. I'd very much like to establish that at default optimization levels for execution, this information is not guaranteed to be maintained past the creation of the AST. Unfortunately, it is. Perl 6 defines that Perl 6 programs can always access their own Pod at runtime (via $=POD). You probably can't even optimize the information away in the absence of any compile-time reference to $=POD, since there are plenty of symbolic ways to refer to $=POD at run-time. Damian
Re: How can i contribute for perl 6 ?
Timothy (): I'd actually be in favour of Masak's post being copied to the site (with attribution) and expanded, rather than just linked, if Carl is happy with the idea. [...] I'd be honoured. In general, consider anything I write on use.perl to be cc-attr-licenced. http://creativecommons.org/licenses/by/3.0/ For http://use.perl.org/~masak/journal/39445 in particular, I'd suggest copying everything after the Ahem, partly to get to the meat of the post sooner, partly because the text gets more of a community voice that way. // Carl
Re: How can i contribute for perl 6 ?
Timothy S. Nelson wrote: On Wed, 16 Sep 2009, Geoffrey Broadwell wrote: On Wed, 2009-09-16 at 19:49 +1000, Timothy S. Nelson wrote: +1. I have a set of 7 bookmarks that load in tabs that I call my Perl 6 bookmarks. I load this group of tabs into a separate web browser window when I'm doing Perl 6 stuff. That link is one of the 7 links. Perhaps your other Perl 6 bookmarks ought to appear on rakudo.org or perl6.org as well. :-) They probably mostly do: - rakudo.org ☑ (for the non-Unicode readers, that's a check mark in a box ;-) - parrot.org ☑ - P6 specs ☑ - Moritz' blog (especially because of the monthly summaries) Maybe I should be more disciplined with the monthly summaries then ;-) Anyway, perl6.org links to planetsix, which aggregates my blog, and which I prefer for such a general site than linking to individual blogs. - #perl6 IRC logs ☑ - perl6.org ☑ - That link to Masak's blog will be added as soon as we have a -Ofun sub page (see my other mail about perl6.org in this thread). I'm pretty sure most of those are linked somewhere. I'd actually be in favour of Masak's post being copied to the site (with attribution) and expanded, rather than just linked, if Carl is happy with the idea. Unfortunately no tuits at the moment. We're not in a hurry either... ;-) Cheers, Moritz
Re: Cobra Ioke Programming Languages
Also any thoughts on implementing Perl 6 on LLVM? Well, the planning is already under way... Parrot want to eventually use LLVM as one of the possible backend: http://wknight8111.blogspot.com/2009/09/first-steps-on-jit-overhaul.html At the moment, it is targeted for the 2.6 release: https://trac.parrot.org/parrot/report/14 Bye, Raphael.
Re: How can i contribute for perl 6 ?
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? @perlsaran On Wed, Sep 16, 2009 at 9:39 PM, Geoffrey Broadwell ge...@broadwell.orgwrote: On Wed, 2009-09-16 at 19:49 +1000, Timothy S. Nelson wrote: +1. I have a set of 7 bookmarks that load in tabs that I call my Perl 6 bookmarks. I load this group of tabs into a separate web browser window when I'm doing Perl 6 stuff. That link is one of the 7 links. Perhaps your other Perl 6 bookmarks ought to appear on rakudo.org or perl6.org as well. :-) -'f
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: S26 - The Next Generation
On Thu, Sep 17, 2009 at 1:05 AM, Damian Conway dam...@conway.org wrote: Aaron Sherman asked: ... I'd very much like to establish that at default optimization levels for execution, this information is not guaranteed to be maintained past the creation of the AST. Unfortunately, it is. Perl 6 defines that Perl 6 programs can always access their own Pod at runtime (via $=POD). You probably can't even optimize the information away in the absence of any compile-time reference to $=POD, since there are plenty of symbolic ways to refer to $=POD at run-time. Can some concept/implementation of $=POD lazyness only incur the memory and performance hit on access? -y
Re: Cobra Ioke Programming Languages
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. On Thu, Sep 17, 2009 at 6:06 AM, Juan Madrigal jua...@mac.com wrote: In addition to what you mentioned I would like to be able to specifying whether the language is strictly typed or dynamically type in Perl6 (not sure if that's possible now). Would be nice to mix both in with a keyword. In Perl6 a variable can be untyped, typed at compile time (statically typed), or typed at run time (dynamically typed). In fact you can also specify the implementation of the variable independently of its type, similar to perl5's tie interface. For a nice long list of P6 buzzwords (though perhaps a bit outdated) look at http://dev.perl.org/perl6/faq.html 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! -y
Re: S26 - The Next Generation
On Thu, 2009-09-17 at 11:12 -0700, yary wrote: On Thu, Sep 17, 2009 at 1:05 AM, Damian Conway dam...@conway.org wrote: Aaron Sherman asked: ... I'd very much like to establish that at default optimization levels for execution, this information is not guaranteed to be maintained past the creation of the AST. Unfortunately, it is. Perl 6 defines that Perl 6 programs can always access their own Pod at runtime (via $=POD). You probably can't even optimize the information away in the absence of any compile-time reference to $=POD, since there are plenty of symbolic ways to refer to $=POD at run-time. Can some concept/implementation of $=POD lazyness only incur the memory and performance hit on access? Alternately it should be possible to declare that the Pod data be dropped before mainline runtime begins. For example, it ought to be possible for a compiling implementation such as Rakudo to declare that the Pod data not be frozen into the PBC file. (If this is already specced, I apologize -- I haven't searched for it.) -'f
Re: S26 - The Next Generation
yary asked: Can some concept/implementation of $=POD lazyness only incur the memory and performance hit on access? IANAImplementor, but I suspect that virtually all of the performance hit could be incurred at run-time, if it happened to be implemented that way. The memory hit too, if necessary, but that would then make the performance hit hit very hard indeed. I suspect that it would be better to preserve the Poddish parts of the AST structure and just have them transmogrify into the appropriate Pod objects on demand. Damian
Announce: Rakudo Perl 6 development release #21 (Seattle)
On behalf of the Rakudo development team, I'm pleased to announce the September 2009 development release of Rakudo Perl #21 Seattle. Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine [1]. The tarball for the September 2009 release is available from http://github.com/rakudo/rakudo/downloads . Due to the continued rapid pace of Rakudo development and the frequent addition of new Perl 6 features and bugfixes, we recommend building Rakudo from the latest source, available from the main repository at github. More details are available at http://rakudo.org/how-to-get-rakudo. Rakudo Perl follows a monthly release cycle, with each release code named after a Perl Mongers group. September 2009 is code named Seattle for the enthusiasm they have shown for Perl 6 during monthly meetings, and the feedback, encouragement and support given me for the past several years. Since the 2009-08 release, Rakudo Perl builds from an installed Parrot instead of using Parrot's build tree. This release of Rakudo requires Parrot 1.6.0. For the latest information on building and using Rakudo Perl, see the README file section titled Building and invoking Rakudo. (Quick note: the --gen-parrot option still automatically downloads and builds Parrot as before, if you prefer that approach.) Also, unlike previous versions of Rakudo Perl, the perl6 (or perl6.exe) executables only work when invoked from the Rakudo root directory until a make install is performed. Running make install will install Rakudo and its libraries into the Parrot installation that was used to build it, and then the executables will work when invoked from any directory. Some of the specific major changes and improvements occuring with this release include: * Rakudo is now passing 15,497 spectests, an increase of 3,128 passing tests since the August 2009 release. With this release Rakudo is now passing 71.5% of the available spectest suite. * Rakudo now supports contextual variables. * Rakudo now supports the rational (Rat) data type. * Rakudo now supports overloading of many of the builtin operators, many of which are now defined in the core setting. Many have also been improved to be more faithful to the specification with respect to types and coercions. * Substantially improved support for trait handling. Most of the built-in traits are now defined in the core setting. * The %*ENV variable now works properly for modifying the process environment. Since the Perl 6 specification is still in flux, some deprecated features have been removed from Rakudo. Prominently among those are: * '=$handle' is deprecated in favor of '$handle.get' (one line) and '$handle.lines' (all lines). * 'int $obj' is deprecated in favor of '$obj.Int'. The development team thanks all of our contributors and sponsors for making Rakudo Perl possible. If you would like to contribute, see http://rakudo.org/how-to-help , ask on the perl6-compi...@perl.org mailing list, or ask on IRC #perl6 on freenode. The next release of Rakudo (#22) is scheduled for October 22, 2009. A list of the other planned release dates and codenames for 2009 is available in the docs/release_guide.pod file. In general, Rakudo development releases are scheduled to occur two days after each Parrot monthly release. Parrot releases the third Tuesday of each month. Have fun! References: [1] Parrot, http://parrot.org/
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.
Re: Cobra Ioke Programming Languages
I'll take a look at web.pm and see I can get involved. Would be interesting to see if Catalyst is being ported over as well. I see Perl 6 really taking off if the tools for server side scripting/ web development get revamped to take on PHP's and Ruby's in terms of ease of use and deployment. Perl 5/mod_perl2 aren't that easy to administer from a shared hosting perspective and takes some work to get going properly, find the right modules etc... Perhaps there should be a version of Perl tailored for the web with built in features or maybe an include/explicit option to load a specific set of language features. mod_perlite looks interesting as well: http://freshmeat.net/projects/mod_perlite/ -Juan On Sep 17, 2009, at 6:10 PM, Matthew Walton wrote: 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.
Re: S26 - The Next Generation
Not actually S26; but closely related: should $=POD and .WHY be read-only? Also, should there be other Pod variables besides $=POD? If so, which ones? Back on the subject of S26: should declarator blocks and aliases be able to introspect the object with which they're associated? That is, should you be able to say things like A.WHAT or A.^methods? (If so, be sure never to say A.WHY.) -- Jonathan Dataweaver Lang
