Rakudo Star 2013.12 Released!
# Announce: Rakudo Star Release 2013.12 ## A useful, usable, early adopter distribution of Perl 6 On behalf of the Rakudo and Perl 6 development teams, I'm happy to announce the December 2013 release of Rakudo Star, a useful and usable distribution of Perl 6. The tarball for the December 2013 release is available from http://rakudo.org/downloads/star/. A Windows .MSI version of Rakudo star will usually appear in the downloads area shortly after the tarball release. In the Perl 6 world, we make a distinction between the language (Perl 6) and specific implementations of the language such as Rakudo Perl. This Star release includes [release 2013.12] of the [Rakudo Perl 6 compiler], version 5.9.0 of the [Parrot Virtual Machine], plus various modules, documentation, and other resources collected from the Perl 6 community. [release 2013.12]: https://github.com/rakudo/rakudo/blob/nom/docs/announce/2013.12.md [Rakudo Perl 6 compiler]: http://github.com/rakudo/rakudo [Parrot Virtual Machine]: http://parrot.org Some of the new features added to this release include: + The Whatever Star (*) now works inside chain operators like comparisons. + Private attributes from roles are now visible in the classes they apply to. + Memory and speed improvements for ListIter and List.combinations, respectively. + Improvements to the execution of regexes. This release also contains a range of bug fixes, improvements to error reporting and better failure modes. Please note that this release of Rakudo Star does not support the JVM backend from the Rakudo compiler. While the JVM backend mostly implements the same features as the Parrot backend, many bits are still missing, most prominently the native call interface. We hope to provide a JVM-based Rakudo Star release soon. The following notable features have been deprecated or modified from previous releases due to changes in the Perl 6 specification, and are planned to be removed or changed as follows: * All unary hyper ops currently descend into nested arrays and hashes. In the future, those operators and methods that are defined nodal will behave like a one-level map. There are some key features of Perl 6 that Rakudo Star does not yet handle appropriately, although they will appear in upcoming releases. Some of the not-quite-there features include: * advanced macros * threads and concurrency (in work for the JVM backend) * Unicode strings at levels other than codepoints * interactive readline that understands Unicode * non-blocking I/O * much of Synopsis 9 and 11 There is an online resource at http://perl6.org/compilers/features that lists the known implemented and missing features of Rakudo and other Perl 6 implementations. In many places we've tried to make Rakudo smart enough to inform the programmer that a given feature isn't implemented, but there are many that we've missed. Bug reports about missing and broken features are welcomed at rakudo...@perl.org. See http://perl6.org/ for links to much more information about Perl 6, including documentation, example code, tutorials, reference materials, specification documents, and other supporting resources. A draft of a Perl 6 book is available as docs/UsingPerl6-draft.pdf in the release tarball. The development team thanks all of the contributors and sponsors for making Rakudo Star possible. If you would like to contribute, see http://rakudo.org/how-to-help, ask on the perl6-compi...@perl.org mailing list, or join us on IRC \#perl6 on freenode.
Fwd: [Boston.pm] Tech Meeting Tuesday
FYI -- Forwarded message -- From: Bill Ricker bill.n1...@gmail.com Date: Dec 6, 2013 6:25 PM Subject: [Boston.pm] Tech Meeting Tuesday To: Boston Perl Mongers boston...@pm.org, Boston Perl Mongers (announce) boston-pm-annou...@pm.org Cc: Tuesday December 10, 2013 E51-376 Tim King - Benchmarking Perl6 vs Perl5 * Perl 6's suitability for production. (Your definition may vary.) * Experiences of the state and stability of Rakudo. * Benchmarks of my favorite P6 features. * Lines of P6 code from everyday life. * Some comparisons of P6 with P5. - http://sd.jtimothyking.com/tag/perl-6/ benchmarks Perl 6 tvs Perl 5. *Boiler plate Details* - Tech Meetings are held on the 2nd Tuesday of every month at MIT ( directions http://boston-pm.wikispaces.com/MIT+Directions ). - Talk begins at 7:30. - Refreshments in the hallway prior. - RSVP for count encouraged but not required, to bill.n1...@gmail.commebill.n1...@gmail.com or Boston-PM list, by 3pm Tuesday. - In case of weather, check boston.pm.org wiki and this mailing list for updates. -- Bill @n1vux bill.n1...@gmail.com ___ Boston-pm mailing list boston...@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: Licensing: Perl 6 specification and test suite
frettled, Right, it's just the AL2 requires you to thoroughly rename the project's main name(s) if you redistribute a modified version.. -Matthew On Tue, Nov 5, 2013 at 7:21 AM, Jan Ingvoldstad frett...@gmail.com wrote: On Tue, Nov 5, 2013 at 3:36 PM, Moritz Lenz mor...@faui2k3.org wrote: I have no idea if the AL2 is well suited for sets of documents, as the specification is. I'll leave that decision to Larry. To anyone in doubt: please note that I'm not Larry, I'm not an authority, I'm just opinionated. :) Considering that the specification is sortof actually a language specification, I think there should at least be some terms regarding how this should apply. Forking the documentation, or creating derivative works, shouldn't be a problem, as long as it doesn't change the specification in itself, and thereby create confusion regarding what the Perl 6 specification is. Technically speaking, there shouldn't be a problem with pulling the Git repository, making changes, and proposing that these changes should be merged with the central Git repository for the specification – that is, after all, an approximation of how the specification is changed and developed by the community. -- Jan -- Sent by the Internet - Login to LinkedIn to see my whole profile and Connect http://linkedin.com/in/mattswilson
Announce: Rakudo Star 2013.10 Released!
## A useful, usable, early adopter distribution of Perl 6
On behalf of the Rakudo and Perl 6 development teams, I'm happy to
announce the October 2013 release of Rakudo Star, a useful and usable
distribution of Perl 6. The tarball for the October 2013 release is
available from http://rakudo.org/downloads/star/. A Windows .MSI
version of Rakudo star will usually appear in the downloads area
shortly after the tarball release.
In the Perl 6 world, we make a distinction between the language
(Perl 6) and specific implementations of the language such as
Rakudo Perl. This Star release includes [release 2013.10] of the
[Rakudo Perl 6 compiler], version 5.9.0 of the [Parrot Virtual
Machine], plus various modules, documentation, and other resources
collected from the Perl 6 community.
[release 2013.10]:
https://github.com/rakudo/rakudo/blob/nom/docs/announce/2013.10.md
[Rakudo Perl 6 compiler]: http://github.com/rakudo/rakudo
[Parrot Virtual Machine]: http://parrot.org
Some of the new features added to this release include:
+ postcircumfix {} and [] are now implemented as multi subs rather than
multi methods.
+ Add support for is DEPRECATED, making it easy for early adopters to
stay current.
+ Track multiple spec changes for various container classes.
+ Greatly reduce object creation during Regex parsing.
+ Various portability fixes.
+ qx// and run() now auto-quote correctly.
+ Allow #`[...]-style comments in regexes.
+ unlink() behaves like P5's, it deletes write-protected files on Windows.
This release also contains a range of bug fixes, improvements to error
reporting and better failure modes.
Please note that this release of Rakudo Star does not support the JVM
backend from the Rakudo compiler. While the JVM backend mostly implements
the same features as the Parrot backend, many bits are still missing,
most prominently the native call interface.
We hope to provide a JVM-based Rakudo Star release soon.
The following notable features have been deprecated or modified from
previous
releases due to changes in the Perl 6 specification, and are planned to be
removed or changed as follows:
* `postcircumfix:[ ]` and `postcircumfix:{ }` are now multi-subs
rather
than multi-methods. Both at_pos and at_key remain as methods.
* All unary hyper ops currently descend into nested arrays and
hashes. In the future, those operators and methods that are
defined nodal will behave like a one-level map.
* The Str.ucfirst builtin is deprecated; it will be replaced by
Str.tc. In this Rakudo Star release, use of Str.ucfirst will actually
generate a warning upon first usage.
* In the next release, leading whitespace in rules and under
:sigspace will no
longer be converted to `.ws`. For existing regexes that expect this
conversion now and in the future, add a `?` in front of leading
whitespace
to replicate the old behavior. (Adding `?` today will have no adverse
effects on your code.)
There are some key features of Perl 6 that Rakudo Star does not yet
handle appropriately, although they will appear in upcoming releases.
Some of the not-quite-there features include:
* advanced macros
* threads and concurrency
* Unicode strings at levels other than codepoints
* interactive readline that understands Unicode
* non-blocking I/O
* much of Synopsis 9 and 11
We are also aware of these issues in the current release, which will be
dealt
with in a future relase:
* Whatever-currying of *, *{}, and *[] is currently broken.
* You may experience some test failures running the rakudo
spectest. S16-filehandles/filestat.t will fail if you have Rakudo
Star on a
drive that does not record access times.
S05-mass/charsets.rakudo.parrot
will fail due to the tests being outdated.
There is an online resource at http://perl6.org/compilers/features
that lists the known implemented and missing features of Rakudo and
other Perl 6 implementations.
In many places we've tried to make Rakudo smart enough to inform the
programmer that a given feature isn't implemented, but there are many
that we've missed. Bug reports about missing and broken features are
welcomed at rakudo...@perl.org.
See http://perl6.org/ for links to much more information about
Perl 6, including documentation, example code, tutorials, reference
materials, specification documents, and other supporting resources. A
draft of a Perl 6 book is available as docs/UsingPerl6-draft.pdf in
the release tarball.
The development team thanks all of the contributors and sponsors for
making Rakudo Star possible. If you would like to contribute, see
http://rakudo.org/how-to-help, ask on the perl6-compi...@perl.org
mailing list, or join us on IRC \#perl6 on freenode.
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
Pragma to change presentation of numbers in Perl 6.
Today I propose a pragma that changes how numbers are presented in Perl
6. The idea arises from a discussion on the freenode channel #perl6,
available here: http://irclog.perlgeek.de/perl6/2010-09-01#i_2773432
The most important thing to remember is that the presentation of numbers
in Perl 6 is different from the number itself, the way we use numbers in
our code is different from how Perl 6 handles them internally. We only
chose for numbers in our code to be presented and treated as being in
base 10 because that's how most of us count.
The pragma I propose is use base, which takes one positional argument
that denotes what base you want Perl 6 to interpret and present numbers
in your code. For example, use base 16 tells Perl 6 to handle all
numbers as if they're in base 16, and to present them as base 16. Here,
I present an example use:
my $a = 10;
say $a;
This code does what it always does. It puts the number 0d10 into $a, and
then say outputs `10'. But this code:
use base 16;
my $a = 10;
say $a;
puts the number 0x10 into $a, and outputs `10'. Here, say $a.fmt('%d')
would output `16'.
Now, this may cause some confusion in some cases, particularly with the
radix conversion :10() and such. In the default base 10, :10($a) is
interpreted to mean that $a is in base 10, and to convert it to how Perl
6 currently presents numbers, base 10. Naturally, this is pretty
useless. In base 16 mode, :10($a) is interpreted to mean that $a is in
base 16 (because the 10 here is now 0x10), and to convert it to base 16,
and is just as useless. In base 16 mode, :A($a) would be used instead
to convert base 10 to base 16.
If you see any significant problems or have suggestions, then feel free
to reply. I feel this will help with making non-10 bases easier to deal
with in applications where its necessary.
-lue
Re: Ideas for a Object-Belongs-to-Thread threading model
On Wed, May 12, 2010 at 8:57 PM, Alex Elsayed eternal...@gmail.com wrote: Forgot to send this to the list. -- Forwarded message -- From: Alex Elsayed eternal...@gmail.com ... It's also CPS based, which fits pretty well. Here's another, one that might fit more readily with perlesque/CLR: Actors that Unify Threads and Events pdf: http://lamp.epfl.ch/~phaller/doc/haller07actorsunify.pdf slides: http://lamp.epfl.ch/~phaller/doc/ActorsUnify.pdf In this paper we present an abstraction of actors that combines the benefits of thread-based and event-based concurrency. Threads support blocking operations such as system I/O, and can be executed on multiple processor cores in parallel. Event-based computation, on the other hand, is more lightweight and scales to large numbers of actors. We also present a set of combinators that allows a flexible composition of these actors. Scala actors are implemented on the JVM, but our techniques can be applied to all multi-threaded VMs with a similar architecture, such as the CLR.
Re: Proposal for a new Temporal time-measurement paradigm
I whole-heartedly agree that we need to make a system independent of any sort of time measurement system. I think the conclusion reached on IRC was that most of the world uses or is at least familiar with the Gregorian system. Now, I can't help but think how we would define an Instant. The best (reasonable) choice is something like TAI or Unix Epoch (I could argue that seconds are not independent, but don't trust me; I'd suggest tapping into the cosmic timeline :) ). I also hope there aren't going to be any leap Instants. (the filter should take care of leaping, after all the calendar has an issue with leaping.) If there isn't a standard defining how many seconds are in a year (i.e. as defined by TAI or the metric system or some other international standard), I propose it'd be about 365.25 Gregorian days (although I'd much prefer an international standard to my Indo-European ways :) ). Overall, I think you have a great idea. As long as the filters are implemented simply, I think it will prove to be the best option. -- Don't Panic!
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: underscores vs hyphens (was Re: A new era for Temporal)
I can't help but agree with Damian. I don't see much of a point in making a distinction between - and _. More specifically, if a user were to define a function (say, i-hate-camel-case()), it would not be good to let them be the same. Readability would suffer when examining someone's code and you see i_hate_camel_case() and you can't find that function (in my example there are 8 different possibilities for what the actual function was defined as!) However, in core functionality, such a distinction should be made /if it makes sense/. For example, allowing 3 _ 4 in place of 3 - 4 would not make sense, while obscure commands (the PIR functions in rakudo, for example), would do better to not be so stringent (or at least tell you what you did wrong). This is my best guess based on what I know. I don't know the whole story, and I'm always ready to be convinced otherwise. -- Don't Panic!
Re: perl6 compiler
As written in pmichaud's journal entries, stability is explicitly *not* (and never was) one of the goals of the April 2010 release of Rakudo. On Fri, Mar 19, 2010 at 7:24 AM, Steve Pitchford steve.pitchf...@gmail.com wrote: I think this question was largly addressed in the first link? On Fri, Mar 19, 2010 at 12:59 PM, Wendell Hatcher wendell_hatc...@comcast.net wrote: I actsully read the fact sheets in the past and want to confirm that a stable production qaulity release of perl6 is coming out this April or at the berry least the summer? Sent from my iPhone Wendell Hatcher wendell_hatc...@comcast.net 303-520-7554 Blogsite: http://thoughtsofaperlprogrammer.vox.com/ http://thoughtsofaperlprogrammer.vox.com/ On Mar 19, 2010, at 3:19 AM, Steve Pitchford steve.pitchf...@gmail.com wrote: Aha - A FAQ - for the answer, read here: http://use.perl.org/%7Epmichaud/journal/39411 http://use.perl.org/~pmichaud/journal/39411http://use.perl.org/%7Epmichaud/journal/39411 and here: http://en.wikipedia.org/wiki/Rakudo_Perl http://en.wikipedia.org/wiki/Rakudo_Perl Cheers, Steve On Fri, Mar 19, 2010 at 4:05 AM, Wendell Hatcher wendell_hatc...@comcast.net wendell_hatc...@comcast.net wrote: Is there ever going to be a perl6 production version coming out soon? Sent from my iPhone Wendell Hatcher wendell_hatc...@comcast.netwendell_hatc...@comcast.net 303-520-7554 Blogsite: http://thoughtsofaperlprogrammer.vox.com/http://thoughtsofaperlprogrammer.vox.com/ http://thoughtsofaperlprogrammer.vox.com/ On Mar 17, 2010, at 7:18 AM, Steve Pitchford steve.pitchf...@gmail.com steve.pitchf...@gmail.com wrote: Have a read of this: http://www.parrot.org/ http://www.parrot.org/http://www.parrot.org/ The parrot project is to build a virtual machine for dynamic languages, like perl 6. On Wed, Mar 17, 2010 at 1:43 AM, Dell wendell_hatc...@comcast.netwendell_hatc...@comcast.net wendell_hatc...@comcast.net wrote: Has anyone thought about designing or is the Rakudo compiler similar to the JVM on an enterprise level? What I mean is would I be able to write applications that can process huge amounts of data like files,claims or account transactions on Rakudo in the future? I think this would be a huge push for perl and any dynamic language. :-) Matthew Walton wrote: 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.netwendell_hatc...@comcast.net 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: 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: One-pass parsing and forward type references
On Mon, Feb 1, 2010 at 9:32 AM, Larry Wall la...@wall.org wrote: But I also think that type recursion is likelier to indicate a design error than function recursion, so I'm not sure how far down this road we want to go. We could, for instance, create a new type name every I was going to say I use self-referential and cyclical type definitions in Sprixel's (stage0) C# source... (because I did at one point), but then I realized I stopped doing that; it worked, but it was a tad too tricksy to maintain. So, point taken.
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.
Re: s/ DateTime - Instant / TAI /
Dare I suggest TAIME? I do. On 9/9/09, Richard Hainsworth rich...@rusrating.ru wrote: Carl Mäsak wrote: Darren (), commit-bot (): +Returns a TAI epoch value for the current time. Shouldn't the result type of time() be an Instant object (Instant and Duration are defined in S02) rather than a Rat? I fear that the Instant from S02 is a fossil. Instant was renamed by Dave Rolsky to DateTime on 2009-02-19. There was fairly extensive discussion. My recollection was that 'Instant' and 'Duration' were preferred. The problem arises because in English the word 'instant' can be several parts of speech (noun - 'in an instant', adjective - 'instant coffee'), and that the adjective is the most common. DateTime is uglier. I cant remember whether there was a definitive resolution to this discussion, other than Dave Rolsky changing the spec and the discussion fading into other questions. Since a TAI epoch value is the underlying metric, how about a 'TAI' as the type (in place of DateTime)? Richard
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: Grammars that generate stuff
On Sat, Mar 28, 2009 at 1:48 AM, Timothy S. Nelson wayl...@wayland.id.auwrote: Perl 6 has a general language (grammars) for taking some input and a grammar, and separating the data from the formatting, as it were. Ideally, it'd be possible to specify one grammar that would act both for parsing output and formatting input. This may not be possible, but I like the idea. Tim, Regarding generative/transforming grammars, you may get some good syntax/architecture ideas from the OMeta language system see http://www.tinlizzie.org/ometa-js/#Sample_Project for a selection of browser-based examples... (it's also the subversion repo). Also if you don't mind things Microsoft, there's the (part of Oslo) M language family. -Matthew
Re: Logo considerations - 3 logos needed
On Wed, Mar 25, 2009 at 6:06 PM, Larry Wall la...@wall.org wrote: http://www.wall.org/~larry/cameliafav.icohttp://www.wall.org/%7Elarry/cameliafav.ico out to be necessary. Hand-crafted anti-aliasing is your friend. :) Larry firefox at 3025%: cameliafav.ico all blown up. [groan] http://feather.perl6.nl/~diakopter/cameliafav.ico.png
Re: [svn:perl6-synopsis] r14494 - doc/trunk/design/syn
BEGIN (right now at compile time) UNITCHECK (at end of this compilation unit) CHECK (at end of main compilation) (compile time finishes) ...time passes... (run time starts) INIT (main starts running) ENTER (every block entry) START (first time through only) LEAVE (every block exit) (main finishes running) END See S04 for when the other more specialized closure blocks get called. Code that is generated at run time can still fire off CHECK and INIT blocks, though of course those blocks can't do things that would require travel back in time. Could you specify [at least some examples of] which things would require travel back in time when eval'd?
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: Referring to package variables in the default namespace in p6
On Thu, 21 Jul 2005, TSa (Thomas Sandlaß) wrote:
Matthew Hodgson wrote:
I guess $::('Foo') was a bad example - $Foo=Foo; $::($Foo) would have
been better at illustrating my point - which was that if $::($Foo)
searches outwards through namespace for a variable whose name is held in
$Foo, then $::Foo should end up referring to the same variable.
Let me restate that in my own words. You mean that a symbolic runtime
lookup $::($Foo) with the value of $Foo at that time shall be cached
in the immediatly surrounding namespace and that cached ref is then
accessable through the syntax $::Foo?
Hm, I seem to be making a bit of a pigs ear of explaining myself here, but
thank you for bearing with me. What I was trying to confirm was that
if you create a variable in your immediately surrounding namespace:
$*Main::foo = 'bar'; # (assuming you are in the default namespace)
and a variable containing the string 'foo':
my $varname = 'foo';
then the principle of least surprise suggests to me that the result of
evaluating $::($varname) should be identical to that of evaluating $::foo.
I wasn't getting hung up on whether $::($varname) should somehow be cached
to avoid a dynamic lookup based on the current value of $varname every
time. And I assume that if $*Main::foo hadn't been created, assigning to
$::($varname) would create it as expected (again, without any caching of
$varname).
My confusion initially stemmed from chat on #perl6 about $::Foo and
$::('Foo') being Very Different Things - and the fact that there was ever
any confusion over whether $::foo was your 'closest' $foo variable or
something else.
BTW, I wonder if $::() means $::($_) :)
hehe; that would almost be nice... :)
Otherwise the two $::... forms would be horribly confusingly different
Sorry, they are the same thing: namespace lookup. But without ::() the
compiler does it at compile time for bareword resolving. Without a sigil
in front the result can be used where a type is expected:
for (blahh, fasel, blubber) - $name
{
($name).new;
}
We can consider the equivalence of $foo and $::foo as TIMTOWTWI.
I dought that assigning two different meanings just because their
are two syntactical forms is a good idea.
Fantastic - all my fears are allayed, then. $::foo is $::('foo') is $foo
(assuming it hasn't been our'd or my'd), and all is well in the world.
[lest] I (and other future legions of newbies) would despair. :)
You consider yourself a 'legion of newbies' ;)
Well, earlier I may have been legion, but I think i've regained my karmic
balance a bit now... ;)
cheers;
M.
Re: Referring to package variables in the default namespace in p6
On Wed, 20 Jul 2005, TSa (Thomas Sandlaß) wrote:
Matthew Hodgson wrote:
I'm very surprised that package variables end up in OUR::, however -
because surely they're not necessarily lexically scoped - and the whole
point of 'our' was lexical global scoping, right? :/
Sorry, what is 'lexical global scoping' e.g. compared to
non-global lexical scoping? Is it not so, that conceptually
a program that is loaded from several files can be seen as
a complete nesting of all used packages, modules, classes
etc. where the file scopes are replaced by pairs of braces?
Sure - a nesting of namespaces as opposed to lexical pads.
The care takers of OUR:: are the package, module, class and
role meta classes while MY:: is handled by everything in braces
basically.
Well, when I saw the pseudo-namespace OUR::, my first thoughts were that
its contents would be the current our()d variables which we can access in
a non-qualified manner in our current lexical pad. Not that it was
actually all the package variables in our current namespace, be they
currently lexically accessible or not. Surely this pseudo-namespace
should be called PACKAGENAME:: or something rather than OUR:: in order to
avoid this confusion?
Whilst:
% perl -we 'use strict; { our $foo = foo; } warn $::foo'
makes sense in perl 5, I still maintain that:
% perl6 -we '{ our $foo = foo; } warn $OUR::foo'
is kinda confusing ;)
I've tried to wrap my head around all these behaviours of :: and
summarize them here for future readers: inevitable corrections more than
welcome ;)
Foo # leading sigil: disambiguates Foo as being in type
space
$Foo::bar # trailing sigil: indicates preceding term is in type
space
$Foo::Baz::bar # separator: type space hierarchy separator
($foo) # special case leading form which behaves more like the
trailing sigil separator form for building up type
terms from expressions, as ($foo):: would be ambiguous.
Isn't it easier to say that :: is a unary/binary, right associative
pseudo operator with the following properties:
1) whitespace around :: is not allowed
whitespace to the left stops outwards scanning
this allows ?? ::
2) its rhs is the leaf name you want to refer to
3) the lhs is the namespace path to that leaf
4) a * wildcard starts lookup from the root
(for details of *Foo versus *::Foo see above)
5) parentheses cause symbolic runtime lookup, otherwise
the lookup is at compile time and needs pre-declared
names because there are no barewords
6) a sigil determines the type you want to refer to:
no sigil means autoderefed---that is called---Code
whitespace means a type (if more than one leaf
matches because the name is overloaded the least
upper bound (lub = any type junction) supertype is
returned.
These rules are all fair enough - but they are then ambiguous for $::Foo.
Is that the leaf name variable Foo in your current (innermost) namespace?
Or is it an attempt to dereference the disambiguated type Foo? Or is it
like perl5, shorthand for $*Main::Foo?
Is there any reason why $::Foo could not do both, and not start by
searching your current namespace for a variable called $Foo... and then
start searching your current namespace hierarchy for a type called Foo and
try to dereference it (whatever that does)?
Presumably it should behave in precisely the same way that $::('Foo') does
for sanity - does that search the current namespace for just types or
variables or both?
M.
Referring to package variables in the default namespace in p6
Hi all, I've spent some of the afternoon wading through A12 and S10 trying to thoroughly understand scope in perl 6, in light of the death of use vars and the addition of class (as well as package module) namespaces. In the process I came up against some confusion concerning how the default package namespace should work. Currently, pugs does: % pugs -e '$main::foo=foo; say $foo' foo which contradicts S10, which states: The ::* namespace is not main. The default namespace for the main program is ::*Main. This turned out to be an oversight - but there was then confusion as to how one actually refers to variables in the ::*Main namespace, as if $Foo::bar looks up the ::Foo object and fetches $bar from it, then presumably $*Main::foo should look up the ::*Main object, and fetch $foo from it. However (from #perl6): autrijus Arathorn: when you see $Foo::bar, it means looking up the ::Foo object, then fetch $bar from it autrijus and ::Foo, just like %Foo, can be lexical or package scoped or global (%*Foo) autrijus to restrict the lookup to ::*Foo you can't use the ordinary qualifying syntax, I think. autrijus but I may be completely wrong Arathorn so it sounds as if to get the variable $bar from the global packagename ::*Foo (or just *Foo if disambiguation is not necessary), you'd use $*Foo::bar then. autrijus that may be the case, yes. autrijus $?Foo::bar means $?bar in Foo:: autrijus but $*Foo::bar can't mean $*bar in Foo:: autrijus because Foo:: will never contain a $*bar. autrijus so it must mean $bar in *Foo:: autrijus this is very weird. So the question is: what is the correct syntax for referring to package variables in the default namespace? Also, what is the correct syntax for referring to package variables in your 'current' namespace? $::foo? $?PACKAGENAME::foo? $::($?PACKAGENAME)::foo? %PACKAGENAME::foo? cheers, Matthew. -- Matthew Hodgson [EMAIL PROTECTED] Tel: +44 7968 722968 Arathorn: Co-Sysadmin, TheOneRing.net®
Re: Referring to package variables in the default namespace in p6
On Tue, 19 Jul 2005, Larry Wall wrote:
On Tue, Jul 19, 2005 at 07:25:35PM +0100, Matthew Hodgson wrote:
:
: So the question is: what is the correct syntax for referring to package
: variables in the default namespace?
The * looks like a twigil but it isn't really. It's short for *::,
where the * is a wildcard package name, so in theory we could have
$=*foo, meaning the $=foo in the *:: package. (But most of the
twigils imply a scope that is immiscible with package scope.)
So, if I understand this correctly, the conclusion for referring to the
default program namespace is $*Main::foo - which is shorthand for
$*::Main::foo, which pulls the variable $foo out of the globally-rooted
namespace called Main. I'll plonk some tests into pugs to try to steer
towards that...
In terms of resolving non-fully-qualified namespaces, presumably
$Main::foo would work most of the time, assuming that you weren't
currently within any package/module/class namespace scopes called Main -
as S02 says 'the * may generally be omitted if there is no inner
declaration hiding the global name.'?
: Also, what is the correct syntax for referring to package variables in
: your 'current' namespace? $::foo? $?PACKAGENAME::foo?
: $::($?PACKAGENAME)::foo? %PACKAGENAME::foo?
That's currently:
$OUR::foo
right... I guess that goes with $MY:: and $OUTER:: in S06 and their
respective hash access methods.
I'm very surprised that package variables end up in OUR::, however -
because surely they're not necessarily lexically scoped - and the whole
point of 'our' was lexical global scoping, right? :/
is being able to:
% perl6 -e '{ $*Main::foo = foo; } say $OUR::$foo'
really a feature? Or is OUR:: actually intended to include non-lexically
scoped package variables too as a special case?
I'm not sure whether $::foo
is usefully distinct from $foo these days. It almost seems to imply
that ::foo is in type space and we have to dereference it somehow.
There's a sense in which :: only implies type space after a name.
We somehow seem to have the situation where :: is simultaneously
trying to be a leading sigil, a trailing sigil, and a separator.
I've tried to wrap my head around all these behaviours of :: and summarize
them here for future readers: inevitable corrections more than welcome ;)
::Foo # leading sigil: disambiguates Foo as being in type space
$Foo::bar # trailing sigil: indicates preceding term is in type space
$Foo::Baz::bar # separator: type space hierarchy separator
::($foo) # special case leading form which behaves more like the
# trailing sigil separator form for building up type
# terms from expressions, as ($foo):: would be ambiguous.
I assume that I am correctly following your lead in referring to
package/module/class namespaces as 'type space' here...
As regards $::foo, making a special case for it being a synonym for
$*Main::foo be yet another complication entirely without precedent in the
current behaviour. But then again, using $::x in the past as a quick way
to disambiguate between lexical package variables in simple package-less
scripts was quite handy...
thanks hugely for the quick feedback :)
M.
Re: ./method defunct
Juerd wrote: What does this have to do with perl6-internals? F-up to p6l. Sorry! Typing faster than my brain is working. Resent to the right list. If I have a complicated mathematical expression If you have anything that is complicated, a verbose version should always be considered, if only to avoid getting lost in punctuation. This is not specific to ./foo in any way. If I'm calling a method on $?SELF five times in a statement and you're only calling one once, wouldn't such an operator be more important to me than to you? I'm not arguing that having a short way to call a method on the current invocant-- be it operator or keyword-- is a bad thing. It's a great feature, and why I'm delurking to comment on this. If 'o.' really doesn't work, it doesn't work. We could pick a different operator. I'm just saying that the particular choice of './' doesn't work for me (and evidently a number of other people). It is visually much more suited for action than functional use: ./foo($bar, $baz); # beautiful print 5 + ./foo($bar); # ugly Right here, in my mind, is an argument against it. I'd end up using the operator in some places and not others, because in some contexts it'd be ugly and others beautiful. Thus further reducing the visual consistency of the code. I haven't yet given up on the idea that there's a shortened operator that would be more universally readable. at the top of my code if I have to, but I want to make one last gasp at getting $Larry / @Larry to reconsider this. I find o. absolutily horrifying. But then, that's apparently how you think of ./, so we have to trust Larry's decision on this. I don't think further discussing this is really fruitful, as it has already been discussed more than is good for us. Fair point. I mean no offense, nor do I wish to beat a dead horse. I just want to make sure it's dead, instead of merely resting. -- Matt Matthew Zimmerman Interdisciplinary Biophysics, University of Virginia http://www.people.virginia.edu/~mdz4c/
Re: ./method defunct
[Sorry, sent this to the wrong list by mistake.]
Matthew Zimmerman wrote:
Juerd wrote:
Kurt skribis 2005-06-20 19:46 (-0400):
On 6/20/05, Juerd wrote:
Or you can just get your self with a simple (module that does)
macro self () { '$?SELF' }
And you could do the same for `./`.
Certainly.
However, there has proven to be much demand for something like ./method,
and in such cases, having it by default is probably the best thing.
I personally don't think it's either necessary or too much. I care about
.method using $_, and many other people care about having short syntax
for self.method too. ./method was something that would work for me, so I
shared that idea, and it was generally accepted.
Apart from the personal joy of seeing something I invented become part
of the official language, I don't really care if ./method is eventually
part of Perl 6 or not. I have always named my invocants, and don't mind
continue to do so. On the other hand, if there is a shorthand, I will
use it, because regardless of whether you think it's pretty or ugly, and
regardless of whether you think it looks enough like a method call,
having a short two character operator for this is in fact very
convenient.
Could we revisit the idea of using a shorter keyword for $?SELF, like
'o'? I know that $Larry said the idea was probably not going to work:
http://tinyurl.com/7baz6
but I'm curious if the reasoning that killed it then still holds now,
now that './' has emerged as a replacement.
Count me among the './' dissenters, too. The virtual explosion of new
operators in Perl 6 has not concerned me too much, as I don't envision
myself using many of them, but the operation that './' does is something
I do very frequently. I'm just imaging a lot of my Perl 5 code like:
if ( $self-unit_id == $s2-unit_id ) {
$self-add_component(
$self-_fraction * $self-concentration +
$s2-_fraction * $s2-concentration
);
$self-update;
}
replaced with:
if ( $.unit_id = $s2.unit_id ) {
./add_component(
./:fraction * ./concentration +
$s2.:fraction * $s2.concentration
);
./update;
}
and it gives me the willies. If I have a complicated mathematical
expression with method calls in it (which happens a lot for me), the '/'
part of './' in particular gives me lots of visual problems.
I'll put
macro o () { '$?SELF' }
at the top of my code if I have to, but I want to make one last gasp at
getting $Larry / @Larry to reconsider this.
--
Matt
Matthew Zimmerman
Interdisciplinary Biophysics, University of Virginia
http://www.people.virginia.edu/~mdz4c/
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-\
