Re: S4: Can PRE and POST be removed from program flow?
[EMAIL PROTECTED] (John Siracusa) writes: there's an official way, you'll certainly see less wheel reinvention than in Perl 5. This is a good thing. That is only true if you accept the fundamentalist principle that one should never reinvent wheels. If that were true, then we wouldn't be working on Perl 6. The standardized class, method, submethod, and so on in Perl 6 will be an absolute breath of fresh air. Don't worry; people will soon create their own helper modules anyway. There'll still be More Than One Way To Do It, like it or not. Furthermore, every non-core implementation will necessarily be uglier than the built-in system. Again, this is dogma. If the core specifies every minute detail of what you can do with the language, it's going to be far uglier than any module or implementation you can come up with. Although the Perl motto is There's More Than One Way To Do It, I hesitate to make 10 ways to do something. The trick is to only make one way to do lots of things. The Perl core should be about facilitating cool stuff, not legislating it. -- Why do programmers get Halloween and Christmas mixed up? Because OCT(31) == DEC(25)
Re: S4: Can PRE and POST be removed from program flow?
John Siracusa writes: To bring it home, I think packaging and distribution is important enough to warrant a standard, core-supported implementation. Yes, it's great to be able to roll your own solution, but forcing the issue by providing nothing but the most basic features required to bootstrap a custom solution leads to too much variety and confusion. For some features, familiarity and standardization are more important. That only works if the 'core' feature is unquestionably 'right' and can't be improved upon by somebody else (or indeed by the same person, but later). Furthermore, every non-core implementation will necessarily be uglier than the built-in system. What makes you think that? There are plenty of counter-examples, in terms of things that Perl 5 has in its core (or in its standard set of modules) that others have improved on later. For example in the last couple of years several popular File::Find alternatives/enhancements have found their way to Cpan. It's arguable that current releases of Perl shouldn't have File::Find (or CGI or Text::Soundex or whatever) in the core, since better ways of doing this are elsewhere. In some ways putting features in the core actually stifles innovation, because it doesn't encourage people to come up with novel and better ways of addressing that problem. As a minimum if a feature goes into the core then considerable effort has to be put into ensuring that it is done right, or at least as well as possible and in a way that minimizes the chance of improving or extending it in the future. That takes time. Suppose the time to write the best possible packaging feature is n months. That means that Perl 6.0 could be released on date d without it, or on date d + n with it. Should everybody who doesn't need a packaging feature have to wait for it to be written before Perl 6.0 is released? Suppose instead that 6.0 was released without packaging on date d and 6.1 was released with it on date d + n: that means that you still get your packaging feature on exactly the same date, but it doesn't hold up 6.0. More to the point, once Perl 6 is about people can try writing their own packaging systems, publish them, improve on each other's and so. Perhaps after a few years we will collectively have the experience to see which features and interfaces are most appropriate, and maybe even there's a consensus that a particular packager is the way to go. If many people are all using a single packaging system, then that would be good time to add it to the core, perhaps shipping it with Perl 6.4. Adding a packaging system before then is premature, because there's a very high chance that somebody will write a better alternative packager, leaving Perl in the situation of distributing something that isn't recommended. Smylers
Re: The last shall be last (was: The first shall be first)
John Williams writes: BTW, there should be no ambiguity between Cpostfix:'th and C'', because one occurs where an operator is expected, and one occurs where a term is expected. There may be no ambiguity for the Perl engine, but any use of C' for anything other than quoting makes life hard for syntax highlighters in editors (which have to be able to work well with partially typed Perl, not just complete, parsable Perl). Smylers
Re: The last shall be last (was: The first shall be first)
On Sun 05 Sep, David Green wrote: On 2004/9/04, [EMAIL PROTECTED] (Jonathan Lang) wrote: (Nice Subject change, I almost missed it!) Larry Wall wrote: Yow. Presumably nth without an argument would mean the last. If it means the last, why not just use Clast? Conflict with last LOOP? Hm, the context should be enough to distinguish them, no? (Hey, maybe they can be unified somehow -- last -1 to skip to the penultimate pass through the loop? =P) That could be generalised, next +1 skipping next iteration, next -1 redo this iteration, first redo the iteration from the beginning etc. Richard -- Personal [EMAIL PROTECTED]http://www.waveney.org Telecoms [EMAIL PROTECTED] http://www.WaveneyConsulting.com Web services [EMAIL PROTECTED]http://www.wavwebs.com Independent Telecomms Specialist, ATM expert, Web Analyst Services
Re: What Requires Core Support (app packaging)
On 9/4/04 11:42 PM, chromatic wrote: On Sat, 2004-09-04 at 18:44, John Siracusa wrote: To bring it home, I think packaging and distribution is important enough to warrant a standard, core-supported implementation. I think the specially structured dir of files and its single-file packaged (and precompiled) variants are important enough to be standardized, or core, or whatever you want to call it. ... you can find almost anyone arguing this point for almost any feature. I'm inclined to distrust it. Yes, this is a hard aspect to get consensus on, but that doesn't mean it's not important. Totally avoiding this kind of question is not the solution, IMO. That said... I just don't see a way to achieve this level of transparency and elegance without core support. That's a much better gauge for whether a feature should go into the core. I don't know how this particular case fares with that metric, but it's one of the right questions to ask. I think the most important question was at the end of my last message: is something even *possible* without core support? Taking a set of scripts and libs and making single-file, compiled (or precompiled bytecode or whatever) executable that will run on all platforms that merely have a perl6 executable installed is something that *requires* core support, as far as I can see. On 9/5/04 3:02 AM, Simon Cozens wrote: [EMAIL PROTECTED] (John Siracusa) writes: there's an official way, you'll certainly see less wheel reinvention than in Perl 5. This is a good thing. That is only true if you accept the fundamentalist principle that one should never reinvent wheels. If that were true, then we wouldn't be working on Perl 6. Perl 6 will do many things that Perl 5 can't, so its more aptly described as an upgrade :) The standardized class, method, submethod, and so on in Perl 6 will be an absolute breath of fresh air. Don't worry; people will soon create their own helper modules anyway. There'll still be More Than One Way To Do It, like it or not. Maybe, but I'll wager there'll be a lot less variety since the standard system is more than capable enough for most purposes. Even if it's tweaked a little, if you know the standard system then you have a huge head start on whatever a particular program is doing. Wholesale reinvention will likely be confined to Damians. Furthermore, every non-core implementation will necessarily be uglier than the built-in system. Again, this is dogma. If the core specifies every minute detail of what you can do with the language, it's going to be far uglier than any module or implementation you can come up with. It's not specifying what you can do, it's providing one (good) way to do it. This brings up (again) the issue of core vs standard lib and all that. Some features are naturally library functions, but some things either can't or shouldn't be done without core support. The packaging issue spans the whole range: 1. The special dir of files (SDoF). Ignoring, for now, the argument for a standard way to do this, all the core needs to do to bootstrap an entire ecosystem of app packagers is support some standard starting point. Maybe it's a file names main.pl inside a *.pmx dir, or whatever. But there needs to be something, otherwise every SDoF system will have to bootstrap itself using some executable other than perl (e.g. PAR/parl) I think that's much less elegant. 2. The single-file, packaged version of the SDoF (SDoF Package). Too boostrap this, the core needs to know what to make of such a file. Maybe nothing needs to be done if a #! line and some plain old perl code at the start of the file is sufficient. But something tells me that a bit more is needed to unzip/untar/whatever the rest of the stuff in the package file before execution. Trying to inline pure perl unzip/untar at the header of each SDoF Package file doesn't seem elegant to me, but it could be technically possible to bootstrap that way using only the perl 6 executable. 3. The single-file, platform independent, non-source executable (P6exe). This is bytecode or some other platform neutral representation of the SDoF. I just don't see how to do this at all without core support. (Well, I suppose it could try to #! boostrap as well, but then you'd have to inline a bytecode interpreter or find some way to feed the bytecode to the right part of perl 6, which seems like it also leads to some sort of core support.) The B:: family of modules in Perl 5 are fun, but Perl 6 is supposed to do this better. The perl 6 core needs to be designed with this type of stuff in mind. Regardless of whether it's core or stdlib, I think Java benefited greatly from having the JAR format. Perl 6 should one-up Java here like it does everywhere else :) Based on the little I know of JAR, the three features listed above seem to extend a bit beyond JAR in both directions, and each either require or should have some amount of core support, even if only to
Re: Synopsis 9 draft 1
On Thu, 2004-09-02 at 19:47, Larry Wall wrote: This synopsis summarizes the non-existent Apocalypse 9, which discussed in detail the design of Perl 6 data structures. It was primarily a discussion of how the existing features of Perl 6 combine to make it easier for the PDL folks to write numeric Perl. It took us some time discussing this... we weren't sure what tense you were using. At first we thought it might be the past subjective, but after a while, we decided to coin a new tense: the vapor tense. ;-) Working my way through... thanks Larry! -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: Compiling parrot, cvs head
Alberto Manuel Brandao Simoes wrote: I know head can not compile at all, but maybe this can help to know that the following tests fail on my Slackware Linux: t/pmc/signalNOK 2# Failed test (t/pmc/signal.t at line 44) t/pmc/signalNOK 4# Failed test (t/pmc/signal.t at line 44) t/pmc/signalok 6/6# Looks like you failed 2 tests of 6. t/pmc/signaldubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 2, 4 Failed 2/6 tests, 66.67% okay (less 2 skipped tests: 2 okay, 33.33%) If unespected, I can send more details, if expected: good :-) Best regards, Alberto
Re: [perl #31424] [RESOLVED] PATCH: Fix for parrot linking issue on Solaris 8
Attached is a patch that should fix the solaris link issues without breaking every other platform, hopefully. ;) This adds support for setting triggers on specific config variables. The basic idea is that you can register a named callback for any specific config variable. When that variable is set, all the callbacks registrered for that variable will be called to notify them that the new setting is available. I added subs in config/init/data.pl to for adding triggers, getting them and deleting them. I also fixed the solaris hints file to use the new trigger code. It sets a trigger on 'gcc_version' and when that gets set later on in the config, if it's defined, then the link command will be set to 'g++'. I'm not sure this is the best solution either, but it shouldn't break as much stuff as my last patch, and adds some functionality that might be useful for other similar problems. parrot.config.triggers.patch Description: Binary data
Re: [ANNOUNCE] Test::Simple 0.48_02
hi all :) Michael G Schwern wrote: http://mungus.schwern.org/~schwern/src/Test-Simple-0.48_02.tar.gz A new alpha release of Test::Simple/More/Builder. You can consider this the 0.49 release candidate. Please let me know how it goes. just out of curiosity, what's the word on 0.49? --Geoff
Re: What Requires Core Support (app packaging)
John Siracusa writes: I think the most important question was at the end of my last message: is something even *possible* without core support? Taking a set of scripts and libs and making single-file, compiled (or precompiled bytecode or whatever) executable that will run on all platforms that merely have a perl6 executable installed is something that *requires* core support, as far as I can see. So have you, um, seen PAR? Luke
Re: What Requires Core Support (app packaging)
On 9/5/04 8:31 PM, Luke Palmer wrote: John Siracusa writes: I think the most important question was at the end of my last message: is something even *possible* without core support? Taking a set of scripts and libs and making single-file, compiled (or precompiled bytecode or whatever) executable that will run on all platforms that merely have a perl6 executable installed is something that *requires* core support, as far as I can see. So have you, um, seen PAR? PAR doesn't compile or precompile to bytecode, it packages, temp-expands, and runs. It's closest to item #2 in my feature list, but it's something very different than compiling down to bytecode. Within the realm of what it does, PAR is pretty amazing. But the internals are (necessarily) very ugly and fragile. I suspect the PAR author would love to list the things he needs in the perl 6 core to implement PAR6 in a reliable, straight-forward manner. As for making bytecode packages and cross-platform single-file executables, maybe that's within the realm of the Parrot people. But the perl 6 executable would still to understand such things. -John
Re: The last shall be last
On Sat, 4 Sep 2004 22:17:22 -0700 (PDT), Jonathan Lang Agreed; that's why I'd include last for newbies to use. 0th as last works only as an extension of -1st as first from last, -2nd as second from last, and so on; you have positive numbers counting from the first, and negative numbers counting from next-to-last, leaving only 0th unused and only last unaccounted for. Am I the only one that thinks that -1st should return the last element in an array under the nth scheme? 1st should mean the first element. -1st should mean the first element of the reversed array. Don't say -1st is the first from last. If last is the opposite of first, I would expect 1st to mean first from first, which would mean the second. Say first from the end. -- matt
Re: S4: Can PRE and POST be removed from program flow?
I may be completely off base here, but I think this whole discussion would be better suited for perl6-internals. A packaging system would not be a feature of the language itself, but of its implementation. Don't confuse Perl and perl. -- matt
