Re: Amazing Perl 6
On Sun, May 31, 2009 at 04:45:12PM -0400, Brandon S. Allbery KF8NH wrote: On May 29, 2009, at 15:43 , John M. Dlugosz wrote: Care to try ☃ ? That's alt-meta-hyper-doublebucky-cokebottle. *puzzled as to why OSX Character Map thinks that's related to 雪* Maybe they can't tell the diffence between snowman and snow? (By the way, if you know any 日本人 named Yuki, they probably write their name with 雪. Which is a really cool (no pun intended) character--if you look at the two radicals, it basically means precipitation you can grasp. :) Larry
RE: [RFC] CPAN6 requirements analysis
On Fri, 29 May 2009, Jesse Vincent wrote: Making binary distribution easy is a laudable goal, but it's something the existing infrastructure already supports. I'd love to see CPAN autobuilders which build perl modules for a givven platform and architecture and make them generally available. That'd be a lot cleaner than the current ad-hoc system which requires authors to jump through hoops. But really, that's just another CPAN-related service that could easily layer on the existing infrastructure. Note that this already exists with the PPM (Perl Package Manager) repositories. ActiveState PPM build machines attempt to build all CPAN uploads for a variety of architectures: http://ppm4.activestate.com/ You can see that there are a number of other people who also maintain repositories, but typically only for Windows. Of course the main problem with binary package distributions is that there are several Configure options that will generate Perl binaries that are not binary compatible with each other. So the ActiveState PPM repositories only work for ActivePerl, or any other Perl configured in the same way. Cheers, -Jan
Re: CPAN -- moving forward
Part of the tension here may be coming from the attempt to debate too many levels of structure at once. One of the common factors that has contributed to the longevity of Unix (in the generic sense), and the Internet, is their layered architectures. The kernel does its thing, the shell sits on top, shell tools and applications attend to their matters, and as long as they abide by some standard conventions, revolutions can occur at one level without disturbing others. Similarly, co-ax, twisted pair, power lines, fibre-optics and pigeons can all carry IP packets for UDP or TCP, that might be VoIP or HTTP, and apart from some latency issues with the pigeons, the various layers don't care what's happening either side of them. If this discussion can be split into clear layers, (what gets stored, where, how, c.) it might be easier to produce results.
Re: CPAN -- moving forward
Parrot Raiser wrote: One of the common factors that has contributed to the longevity of Unix (in the generic sense), and the Internet, is their layered architectures. +1 for layered architectures. If this discussion can be split into clear layers, (what gets stored, where, how, c.) it might be easier to produce results. I feel similar. I attempted to do something like that with my wiki page, but that didn't work so well. Now I'm trying a new approach: I am in IRC working with Rakudo folk on how Rakudo is going to store modules on the disk. Once that is done, one can begin talking about a package format and an installer, and then go from there. So far the discussion has been productive and we have some code written that we can experiment with. So I feel encouraged. Daniel.
Module naming conventions
Hi all, Currently in CPAN you have modules like: Digest::MD5 Digest::SHA Digest::MD5::Perl Digest::SHA::PurePerl The difference is that the first two are implemented in C and the later two in Perl. Naming issues are likely to become worse in Perl 6 when we also have modules that use Parrot. You might have three implementations of Digest::SHA, one in Perl 6, one that uses Parrot, and one that uses C. Worse, you might even find a module that depends on both Parrot *and* C. I think we might need to come up with some sort of standard naming convention to distinguish dependencies. Something that the *user* can recognize quickly when he browses CPAN. My first thought was: P6::Digest::SHA C::Digest::SHA Parrot::Digest::SHA But that does nothing for modules that require both C and Parrot (it sounds horrendous, but I bet *someone* will do it). And btw, this isn't just to help users pick the right module. The modules do need different names to avoid naming conflicts. One idea is to introduce a non-alphanumeric character to separate dependencies. For example: Digest::SHA-- No dependencies. Just Perl. Digest::SHA/C -- Requires C. Digest::SHA/Parrot -- Requires Parrot. Digest::SHA/C/Parrot -- Requires C and Parrot. Remember that in Perl 6 modules can be named with any Unicode character, so / is fair game. I am not proposing a change to the language. Just a naming convention using characters that the language already allows. There are other possible symbols besides '/'. All in all, I think my favourite options are (in no particular order): Digest::SHA/C Digest::SHA/Parrot Digest::SHA!C Digest::SHA!Parrot Digest::SHA+C Digest::SHA+Parrot Digest::SHA.C Digest::SHA.Parrot Digest::SHA~C Digest::SHA~Parrot What do you think? If anyone can think of a symbol that is already used in Perl with a similar meaning, please let me know. Daniel.
Re: Module naming conventions
On Mon, Jun 1, 2009 at 5:44 PM, Daniel Carrera daniel.carr...@theingots.org wrote: I think we might need to come up with some sort of standard naming convention to distinguish dependencies. Something that the *user* can recognize quickly when he browses CPAN. Why do we need the dependencies to be part of the name? Perl 6 provides a rugged versioning system for its modules; we should use it. -- Jonathan Dataweaver Lang
Re: Module naming conventions
Jon Lang wrote: On Mon, Jun 1, 2009 at 5:44 PM, Daniel Carrera daniel.carr...@theingots.org wrote: I think we might need to come up with some sort of standard naming convention to distinguish dependencies. Something that the *user* can recognize quickly when he browses CPAN. Why do we need the dependencies to be part of the name? Perl 6 provides a rugged versioning system for its modules; we should use it. I read S11 and AFAICT Perl 6 only includes metadata for *versions* and *authority*: class Dog:ver1.2.1:authcpan:JRANDOM; class Dog:ver1.2.1:authhttp://www.some.com/~jrandom; class Dog:ver1.2.1:authmailto:jran...@some.com; This has nothing to do with dependencies. There is no reason why the same author cannot write two variations of the same module, with different dependencies. In fact, I suspect that will happen often. Digest::SHA and Digest::SHA::PurePerl are written by the same author. He recommends the C version to most people, but he also wrote a Perl only version for people who don't have access to a C compiler. module Using the version or authority fields to denote dependencies is a much greater abuse than using the base name. Daniel.
Re: The game of life
yary not.com-at-gmail.com |Perl 6| wrote: http://www.dlugosz.com/Perl6/web/APL.html The rho example is interesting, though it doesn't compile in current Rakudo. 1 2 3 ⍴¨ 10 would natively be written in Perl 6 as 10 »xx« (1,2,3). perl6 complains about non-dwimmyness. 10 xx (1,2,3) gives (10),(10,10),(10,10,10) , I think that matches the rho example. Ah, I seem to remember something about which way the arrows point with a scalar. I'll look it up. So let’s implement the APL ⌿ operator which works on the columns of a matrix. I think that's something that perl6 could do better then APL. From what I understand, APL has some operators that work on columns and other similar ones that work on rows, p6 has an opportunity to take the direction/dimension as an argument. Which is something I'm thinking about... Good point. Even infix operators can take adjectives! Can the same effect be achieved with slices? --John
Re: Module naming conventions
On Mon, Jun 1, 2009 at 7:50 PM, Jon Lang datawea...@gmail.com wrote: On Mon, Jun 1, 2009 at 5:44 PM, Daniel Carrera daniel.carr...@theingots.org wrote: I think we might need to come up with some sort of standard naming convention to distinguish dependencies. Something that the *user* can recognize quickly when he browses CPAN. Why do we need the dependencies to be part of the name? Perl 6 provides a rugged versioning system for its modules; we should use it. I agree entirely with Jon. This sounds like a fruitless idea and outside the scope of the language. The only idea that I would give any consideration to would be to extend the versioning metadata to allow for the user to define new metadata. That sounds too similar to the goals of XML, but it would at least allow the community to define what metadata is important. Some things are best left unsaid. -Jason s1n Switzer
Anonymous multidimensional array
How does one create an anonymous multidimensional array in p6? Not an array of arrays or a capture of captures... I'm guessing it involves Array.new(:shape) or something like words go in here:shape(2;2), and that it's not yet implemented in Rakudo. Is anonymous multidimensional array creation covered in the synopses? Might be good to answer this explicitly in S09, 'less it's in there and I missed it. -y
Re: Module naming conventions
Daniel Carrera daniel.carrera-at-theingots.org |Perl 6| wrote: Naming issues are likely to become worse in Perl 6 when we also have modules that use Parrot. You might have three implementations of Digest::SHA, one in Perl 6, one that uses Parrot, and one that uses C. Worse, you might even find a module that depends on both Parrot *and* C. Much much worse. There will be many implementations of Perl 6, and each will have totally different non-native interfaces. The front-end should figure out which binary is proper for your platform. Non-binary source code can simply contain everything supported, and let the build process sort it out.
Re: Anonymous multidimensional array
On Mon, Jun 01, 2009 at 08:23:41PM -0700, yary wrote: : How does one create an anonymous multidimensional array in p6? Not an : array of arrays or a capture of captures... But I would expect a shaped array to be able to coerce either of those into its internal format. And coercing captures into structure is basically what @@/slice context is for. Larry
Re: Anonymous multidimensional array
Larry Wall larry-at-wall.org |Perl 6| wrote: On Mon, Jun 01, 2009 at 08:23:41PM -0700, yary wrote: : How does one create an anonymous multidimensional array in p6? Not an : array of arrays or a capture of captures... But I would expect a shaped array to be able to coerce either of those into its internal format. And coercing captures into structure is basically what @@/slice context is for. Larry Right, after meditating on that very thing a few days ago, I conclude @A = @list; should work when one of the containers on the left happens to be shaped. The right is flattened, losing any structure it may have had, including the properly shaped thing already, a single linear list, or a different shape with a suitable number of elements. I would suggest that the assignment demand sufficient elements to fill, or be an integral number of lower-level units if the highest dimension is unspecified. You can always make up the difference by sticking 0 x * at the end of the right-hand-side if that was your intent. And it should be an error if dimensions other than the highest are unspecified. How can it know how to shape it? Use an explicit command to shape up the argument in that case. Also, if you were using an array of arrays, this will clobber that and fill the top array with items. If the top array is declared to be of Arrays, then the assignment will fail just like any other type constraint. But if the second-level arrays are fixed size, you can always write |@A on the left to re-fill those from the right hand side. --John
