Slicing conflict
In Perl 5: my @a = (1,2,3); my @b = @a[0..3]; print scalar(@b); # 4 But in Perl 6: my @a = (1,2,3,4); my @b = @a[1...]; # elements from 1 onward say [EMAIL PROTECTED]; # should probably be 3, but with Perl 5 semantics is Inf We have to break one of these. I think the former is the one to break, even though that might cause some unexpected surprises here and there. Any ideas? Luke
Re: Slicing conflict
On Tue, Apr 12, 2005 at 12:30:42AM -0600, Luke Palmer wrote: But in Perl 6: my @a = (1,2,3,4); my @b = @a[1...]; # elements from 1 onward say [EMAIL PROTECTED]; # should probably be 3, but with Perl 5 semantics is Inf In Pugs (r1847), after the IType refactoring, I have allowed infinite slicing of arrays to simply mean slice until the end. That is: @b = @a[1...]; # elements from 1 onward @b = @a[1..Inf];# same thing I think that's far more more intuitive and convenient. Thanks, /Autrijus/ pgpJeoZ9nKnM7.pgp Description: PGP signature
Re: Slicing conflict
Luke Palmer [EMAIL PROTECTED] wrote: In Perl 5: my @a = (1,2,3); my @b = @a[0..3]; print scalar(@b); # 4 But in Perl 6: my @a = (1,2,3,4); my @b = @a[1...]; # elements from 1 onward say [EMAIL PROTECTED]; # should probably be 3, but with Perl 5 semantics is Inf We have to break one of these. I think the former is the one to break, even though that might cause some unexpected surprises here and there. Any ideas? I was thinking about this today, actually, because my CS textbook was talking about multidimensional arrays. If we make an infinite index mean slice until you can slice no more, then we can possibly have a Cterm:* which is the same as C0 That means we can slice like this: @foo[1,3; *; 7] Which I rather like. (Although term:* might conflict with prefix:*...hmm. I'm not sure it would in common usage--the only things I can think of that could follow are a dot, opening or closing bracket, semicolon or comma, or hyperoperator, none of which are ambiguous if we stick to the no-whitespace-before-postcircumfix rule.) By the way, this also shortens the common idiom: @[EMAIL PROTECTED] To simply: @foo[3...] Which strikes me as a win. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I used to have a life, but I liked mail-reading so much better.
Re: Whither use English?
On Mon, 11 Apr 2005, Juerd wrote: Seriously, is there some reason that we would not provide a Language::Russian and Language::Nihongo? Given Perl 6, it would even [snip] Because providing it leads to its use, and when it gets used, knowing English is no longer enough. I have some code that uses Dutch variable names. When I show that code to people who can't read any Dutch, they have a hard time finding out Which reminds me of the TeX format ConTeXt which is (told to be) somehow more powerful and modern wrt LaTeX, but has a much narrower user base, and IIRC is expressedly design to support localized user interfaces, the only existing one should actually be ductch. I'd be curious to know if and how this works amongst ConTeXt users... Michele -- [...] is like requiring to play tennis with a square ball. Which admittedly makes the game more interesting. - Giuseppe Oblomov Bilotta in comp.text.tex (edited)
S27 Draft
I've taken a shot at starting a Synopsis 27 as well: http://svn.openfoundry.org/pugs/docs/S27draft.pod Cheers, Brian
Re: Question about list context for String.chars
On Mon, Apr 11, 2005 at 03:53:32PM -0400, Mark Reed wrote:
(B: I think that, in general, at the level of Perl code, 1
$B!H(Bcharacter$B!I(B should be
(B: one code point, and any higher-level support for combining and splitting
(B: should be outside the core, in Unicode::Whatever.
(B
(BI think the default should be language-independent graphemes, and
(Bthat support for all Unicode levels below that is in the core, while
(Ball of the many level 4 ("use French") modules should come standard,
(Bwhich is core by some definition.
(B
(BLarry
Re: Blocks, continuations and eval()
On Tue, Apr 12, 2005 at 11:36:02AM +0100, Piers Cawley wrote: : wolverian [EMAIL PROTECTED] writes: : : On Fri, Apr 08, 2005 at 12:18:45PM -0400, MrJoltCola wrote: : I cannot say how much Perl6 will expose to the high level language. : : That is what I'm wondering about. I'm sorry I was so unclear. : : Can you tell me what your idea of a scope is? I'm thinking a : continuation, and if that is what you are thinking, I'm thinking the : answer to your question is yes. : : Yes. I want to know how Perl 6 exposes continuations, and how to get one : for, say, the current lexical scope, and if it has a method on it that : lets me evaluate code in that context (or some other way to do that). : : As I understand what Larry's said before. Out of the box, it : doesn't. Apparently we're going to have to descend to Parrot to write : evalcc/letcc/your-preferred-continuation-idiom equivalent. We'll make continuations available in Perl for people who ask for them specially, but we're not going to leave them sitting out in the open where some poor benighted pilgrim might trip over them unawares. Larry
Re: Slicing conflict
On Tue, Apr 12, 2005 at 12:08:43AM -0700, Brent 'Dax' Royal-Gordon wrote: : I was thinking about this today, actually, because my CS textbook was : talking about multidimensional arrays. If we make an infinite index : mean slice until you can slice no more, then we can possibly have a : Cterm:* which is the same as C0 That means we can slice : like this: : : @foo[1,3; *; 7] : : Which I rather like. Me too. Unless my memory is failing me, I believe that's what S09 already specifies. Larry
Re: Question about list context for String.chars
On Mon, Apr 11, 2005 at 01:08:04PM -0700, gcomnz wrote: : I read followed by 0 or more combining characters to mean that it is : smart enough to combine the vowels in Arabic and other syllabic : alphabets that use special conjuncts. However I'm also not exactly : sure if that's even reasonably possible, or even if it makes sense in : the counting of characters for languages that use those. The 0 or more combining characters is relying on the exact definition of combining character in Unicode, which is construed as (somewhat) language-independent. But the language-dependent level can split up characters in whatever way makes sense to a native speaker of the language. That's what it's there for. But you actually have to declare up front what language you want to work in. Language-independent graphemes is the highest we can go by default, and that's where I think we should go by default, because that's closest to what the naïve user will expect. The smart people will know to drop to codepoints or bytes when they need that. Larry
Re: Whither use English?
On Mon, Apr 11, 2005 at 03:42:25PM -0400, Aaron Sherman wrote: I don't think you can say (as Larry has) that you want to be able to fully re-define the language from within itself and still impose the constraint that it can't confuse people who don't know anything about my module. You might argue that Language::Dutch should never ship with the core... that's a valid opinion, but SOMEONE is going to write it. It'd be a kind of strange form of censorship for CPAN not to accept it. After all, there's more than one way to say it... isn't there? While it may be possible to do it, and while it may be an interesting exercise to implement it, that doesn't mean that anyone *using* it for anything other than a joke isn't a blithering idiot. I'm not even sure I like the *possibility* of using non-ascii letters in identifiers, even. I think we already have Latin-1 in identifiers... more's the pity. Let's see about UTF-8 pugs my $??? = 1; undef pugs $???; 1 I see a sequence of three question marks, there's no funny foreign characters there. I have to confess to being surprised that $??? is legal. -- David Cantrell | Benevolent Dictator Of The World May your blessings always outweigh your blotches! -- Dianne van Dulken, in alt.2eggs...
Re: Whither use English?
Thomas Yandell skribis 2005-04-12 13:13 (+0100): According to Wikipedia there are around 400 million native English speakers and 600 million people who have English as a second language. Should the remaining ~5.5 billion humans be exluded from writing perl code just so that we English speakers can understand all the code that is written? Yes. But your numbers are utterly useless, as they are counts of humans, not programmers. I think that the number of programmers who don't understand English is very small. They know English because historically, the programmer's world has been English. Of course, the level of comprehension differs greatly. That's why where things get hard, Perl lets you write the wrong thing, like 1th and 2th, maybe even 5rd and 7nd. And documentation should be written as simply and clearly as possible. If a word like mnemonic is used, it should first be explained. And keywords are new to any programmer anyway. Mnemonically, it may be easy to remember that say prints something, but it certainly doesn't say anything. And how is remembering my or readline or try any harder than the many not-at-all-english \W operators that Perl has? Then, there are books, documentation, mailing lists and fora, most of which are available in English only. A small part is translated, but I find it hard to believe that the translated portion can be enough. (Still, having them around does help many people, and that's why I think perldocs should perhaps come in several languages (as a different project, so translation delays don't delay Perl releases)). Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Whither use English?
On Tue, Apr 12, 2005 at 02:38:01PM +0200, Juerd wrote: (Still, having them around does help many people, and that's why I think perldocs should perhaps come in several languages (as a different project, so translation delays don't delay Perl releases)). Should ? Who is going to pay for all these translations? There are already volunteer efforts to translate into Japanese and Italian, according to http://www.perl.org/docs.html plus I'm aware of perlchina.org, which is actively translating documentation to Chinese: http://wiki.perlchina.org/main/recently_revised/ Nicholas Clark
Re: Whither use English?
Nicholas Clark skribis 2005-04-12 13:58 (+0100): (Still, having them around does help many people, and that's why I think perldocs should perhaps come in several languages (as a different project, so translation delays don't delay Perl releases)). Should ? Yes, should. That's ideology, though. Who is going to pay for all these translations? Who is going to pay for Parrot? Perl 6? Who's paying for Pugs? Who's going to pay for perldocs in English? Did I miss some important memo? Many people work on Perl 6 voluntarily, and as many could work on translations, but you need an army of translators to keep up with newer versions, and that's why I think it should be official, so it gets lots of attention. There are already volunteer efforts to translate into Japanese and Italian, according to http://www.perl.org/docs.html plus I'm aware of perlchina.org, which is actively translating documentation to Chinese: http://wiki.perlchina.org/main/recently_revised/ That's nice, but were this an international project for in theory any language in existence, then I had probably heard of it much sooner, which is my argument for making translated perldocs an official project that isn't limited to any language. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Whither use English?
On Tuesday 12 April 2005 07:42 am, David Cantrell wrote: On Mon, Apr 11, 2005 at 03:42:25PM -0400, Aaron Sherman wrote: I'm not even sure I like the *possibility* of using non-ascii letters in identifiers, even. I think we already have Latin-1 in identifiers... more's the pity. Let's see about UTF-8 pugs my $??? = 1; undef pugs $???; 1 I see a sequence of three question marks, there's no funny foreign characters there. I have to confess to being surprised that $??? is legal. If it helps any, the problem is somewhere betwen lists.develooper.com and your eyes; the missing doodad was U+0E81 LAO LETTER KO, which is pleasantly curvy.
Re: Whither use English?
On Tue, Apr 12, 2005 at 02:38:01PM +0200, Juerd wrote: Thomas Yandell skribis 2005-04-12 13:13 (+0100): According to Wikipedia there are around 400 million native English speakers and 600 million people who have English as a second language. Should the remaining ~5.5 billion humans be exluded from writing perl code just so that we English speakers can understand all the code that is written? But your numbers are utterly useless, as they are counts of humans, not programmers. I think that the number of programmers who don't understand English is very small. They know English because historically, the programmer's world has been English. There's another issue that he didn't address. OK, let's allow identifiers in (say) Urdu. That's great for the three people in the entire world who speak Urdu, right up to the moment that they want their English, or Russian, or German, or Japanese users to submit patches. -- David Cantrell | London Perl Mongers Deputy Chief Heretic It's my experience that neither users nor customers can articulate what it is they want, nor can they evaluate it when they see it -- Alan Cooper
Re: Whither use English?
I'm not even sure I like the *possibility* of using non-ascii letters in identifiers, even. I think we already have Latin-1 in identifiers... more's the pity. According to Wikipedia there are around 400 million native English speakers and 600 million people who have English as a second language. Should the remaining ~5.5 billion humans be exluded from writing perl code just so that we English speakers can understand all the code that is written? I think not. Tom
Re: Whither use English?
But your numbers are utterly useless, as they are counts of humans, not programmers. I think that the number of programmers who don't understand English is very small. They know English because historically, the programmer's world has been English. My point was that English speakers are in a minority and that the current bias towards English speakers is not necessarily a good thing, and definitely not something we should seek to preserve. Of course, the level of comprehension differs greatly. That's why where things get hard, Perl lets you write the wrong thing, like 1th and 2th, maybe even 5rd and 7nd. And documentation should be written as simply and clearly as possible. If a word like mnemonic is used, it should first be explained. And keywords are new to any programmer anyway. Mnemonically, it may be easy to remember that say prints something, but it certainly doesn't say anything. And how is remembering my or readline or try any harder than the many not-at-all-english \W operators that Perl has? My point was in response to the expressed sentiment that non-ascii letters should not be used in identifiers, rather than in keywords. Then, there are books, documentation, mailing lists and fora, most of which are available in English only. A small part is translated, but I find it hard to believe that the translated portion can be enough. (Still, having them around does help many people, and that's why I think perldocs should perhaps come in several languages (as a different project, so translation delays don't delay Perl releases)). I sincerely hope that one day there will be perl books written by non-English speakers that I can find English translations for ;-) Tom
Re: Whither use English?
On Tue, Apr 12, 2005 at 03:09:10PM +0200, Juerd wrote: Nicholas Clark skribis 2005-04-12 13:58 (+0100): (Still, having them around does help many people, and that's why I think perldocs should perhaps come in several languages (as a different project, so translation delays don't delay Perl releases)). Should ? Yes, should. That's ideology, though. I read should as a danger word. It's often person A describing a desirable feature and intimating that unspecified other people B-Z ought to be implementing it. Who is going to pay for all these translations? Who is going to pay for Parrot? Perl 6? Who's paying for Pugs? Who's going to pay for perldocs in English? Did I miss some important memo? Many people work on Perl 6 voluntarily, and as many could work on translations, but you need an army of translators to keep up with newer versions, and that's why I think it should be official, so it gets lots of attention. You missed an important social observation. Many *programmers* work on these projects voluntarily because they find programming fun. Translation isn't programming, so it's unlikely to be as appealing to the majority of the community involved in Perl 6 currently. That's nice, but were this an international project for in theory any language in existence, then I had probably heard of it much sooner, which is my argument for making translated perldocs an official project that isn't limited to any language. Would you be volunteering to organise this? It's nothing personal if I'm sounding harsh. There is always this great temptation to assign jobs to the they department. (They should do this They should do that). There is no they department in a volunteer organisation - stuff happens because people care about it enough to do it themselves. Nicholas Clark
Re: Whither use English?
Nicholas Clark skribis 2005-04-12 14:34 (+0100): Yes, should. That's ideology, though. I read should as a danger word. It's often person A describing a desirable feature and intimating that unspecified other people B-Z ought to be implementing it. Please note that I try to not think about who's going to implement it at all. That makes being creative and coming up with good ideas much, much easier. Yes, if it is done, people are indeed involved, but if we all agree that something must happen, that's not terribly relevant. And before we can agree, someone must first let it enter discussion. Translation isn't programming, so it's unlikely to be as appealing to the majority of the community involved in Perl 6 currently. If it wasn't for all the pain in my wrists, hands and arms, I would already have translated perldocs and Beginning Perl (1st ed.) to Dutch. And I can't imagine I'm the only language nerd who also understands Perl. Translations work well for lots of other software, and I don't see why software for programming languages would be any different. Would you be volunteering to organise this? When/if I have the time and health to spend on it, certainly. This is one of the many things I'd love to do, but at the moment can't. There is no they department in a volunteer organisation - stuff happens because people care about it enough to do it themselves. Of course there is a they. Many of them even. Let me list a few groups of people commonly referred to as they: * parrot people * @Larry * perldoc/doc/kwid people * p6l people * the people who will be writing perl6 I'm one of the people who has ideas but is currently unable to help implementing them. I can discuss them, though, and I hope that my input can somehow, even though I'm not writing any code, help make Perl 6 a great language. For me, there is a very large they, and without them, there'd never be a Perl 6. If stuff is only happening because people care about it, then my approach should be to try and make people care, and a mailing list like this is a perfect medium for that. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Whither use English?
Juerd skribis 2005-04-12 15:46 (+0200): Please note that I try to not think about who's going to implement it at all. That makes being creative and coming up with good ideas much, much easier. And to be honest, it makes coming up with bad ideas much easier than that even :) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Whither use English?
On Tue, Apr 12, 2005 at 03:46:03PM +0200, Juerd wrote: Yes, if it is done, people are indeed involved, but if we all agree that something must happen, that's not terribly relevant. And before we can That's another dangerous word. If stuff is only happening because people care about it, then my approach should be to try and make people care, and a mailing list like this is a perfect medium for that. This I agree with completely. It's the right way to go about things, as you're not able to do them in person. It's just dangerous words such as should and must that I don't like, because they start to sound like they're imposing obligations on volunteers. Maybe I'm jaded, but if you read enough feedback about Perl 5 it seems that there are an awful lot of people in the world using it who seem to expect rather a lot for nothing. I'd just like people to be careful in their choice of words when suggesting things. Nicholas Clark
Re: Whither use English?
On Tue, Apr 12, 2005 at 03:48:02PM +0200, Juerd wrote: Juerd skribis 2005-04-12 15:46 (+0200): Please note that I try to not think about who's going to implement it at all. That makes being creative and coming up with good ideas much, much easier. And to be honest, it makes coming up with bad ideas much easier than that even :) Good point. Saves having to ask how would I do that?, let alone answer it :-) Nicholas Clark
Re: Whither use English?
On Tue, 2005-04-12 at 07:42, David Cantrell wrote: You might argue that Language::Dutch should never ship with the core... that's a valid opinion, but SOMEONE is going to write it. It'd be a kind of strange form of censorship for CPAN not to accept it. After all, there's more than one way to say it... isn't there? While it may be possible to do it, and while it may be an interesting exercise to implement it, that doesn't mean that anyone *using* it for anything other than a joke isn't a blithering idiot. We're all programmers (I assume), and we've all come across environments where programming tools that seemed useless or silly in one environment were critical in another. The education example I gave is an ideal one, but there are dozens of others from any number of fields. Perl 6 offers us the opportunity to create true dialects, and dialects are valuable things. I don't recommend that everyone rush in and use such a module, but it has its value. I'm not even sure I like the *possibility* of using non-ascii letters in identifiers, even. I think we already have Latin-1 in identifiers... more's the pity. This is just ASCII prejudice (which seems strange, as your domain implies you're not here in the US where such prejudice is usually assumed). There's nothing fundamentally wrong with having $ther as a variable name, other than the fact that most Americans are confused by it because they think and ae are identical. They're wrong. We've already deeply embraced the Latin-1 character set for many purposes in Perl 6. I *would* however, have a use warning unicode type of thing which would warn on the use of any Unicode character in an identifier whose standard display form is difficult to distinguish from some more commonly used character's display form. For example, is just a bit too close to b, so you might want to warn the user unless their default locale was one where it's commonly used, or at least provide a facility for requesting such warnings. Let's see about UTF-8 pugs my $??? = 1; undef pugs $???; 1 I see a sequence of three question marks, there's no funny foreign characters there. I have to confess to being surprised that $??? is legal. That's either a bug in your mailer (or possibly something that tried to re-encode your mail for you) or the fact that you're using some ancient output device that doesn't grok Unicode character sequences. It's refusing to display perfectly valid Content-Type: text/plain; charset=UTF-8 mail in Content-Transfer-Encoding: quoted-printable correctly. It should render pugs my $=E0=BA=81 =3D 1; as the appropriate Unicode sequence. Certainly we've already stated that the default encoding of Perl 6 programs will be UTF-8, and that means that such sequences are valid, and all editors I know of handle these sequences correctly (Emacs, vim, eclipse, etc.) I don't see why stopping someone in Russia from writing code in their native syllabary is wrong... after all, they're probably not going to use ASCII to represent words that I can read anyway... they're going to use ASCII to write a romanized form of their own language. Restrictions on style should be performed at a higher level. For example the new CPAN for Perl 6 might have some qualifiers that you can attach to your programs that describe character set used and other stylistic conventions. That way, I might choose to look for only modules that are written in a language that I feel comfortable maintaining. Then again, I might not care, and just install whatever works. -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
subscripts are.... objects?
We blitzed a discussion on #perl 3 minutes ago, reaching the conclusion that negated subscripts are cool. So i was thinking: subscripts are objects. They are sets, really. You can perform set operations on them: [!-2] is the subscript for everything but the second to last element. By using a context enforcer (subscript [] ?, maybe since lists are lazyy they can just be subscripts when used that way?) you can get a subscript object, which you can then use in a subscript, and it flattens out. The set math is done by special casing junctions, perhaps? my @array; @array[$subscript]; @array[$other]; @array[$subscript | $other]; # union @array[$subscript $other]; # intersection @array[!-1]; # -1 but false? this means that it's masking my $not_1 = [!-1]; @array[$subscript $not_1]; # subscript without -1 @array[$subscript | $not_1]; # subscript with -1, since it's a union # with the complement of just -1 I've found myself replicating sets like these for accessing data many a time in perl 5. Maybe if refined this can be useful? -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me wields bonsai kittens: neeyah pgpgtuYOUpvBY.pgp Description: PGP signature
Win32 with ICU files build problem
Following the instructions in README.Win32 (which has been successful for me in the past), no longer works successfully. First, I cannot run Configure.pl successfully; it complains about --icudatadir not being defined (again not one of the --icu* options mentioned in README.Win32 AND not necessary before). Defining --icudatadir, I now get the following error during make: Src\string_primitives.c(24) : fatal error C1083: Cannot open include file: 'unicode/ucnv.h': No such file or directory I had defined --icuheaders in my call to Configure in whose directory 'unicode/ucnv.h' does exist. Does this mean that Configure is ignoring --icuheader or --icuheader is ignored in the build of the file above? Has anyone successfully built Parrot on Win32 (MSVC 13.10.3077) recently? Mark Solinski
Re: subscripts are.... objects?
Yuval Kogman wrote: You can perform set operations on them: [!-2] Hmm, that would produce a boolean index. is the subscript for everything but the second to last element. By using a context enforcer (subscript [] ?, maybe since lists are lazyy they can just be subscripts when used that way?) you can get a subscript object, which you can then use in a subscript, and it flattens out. The set math is done by special casing junctions, perhaps? I'm not the junction expert, but it's said that they wrap around indexing/slicing! So the @array[!-2] would just read @array[none(-2)]? But how does none() get the base set where the second to last is excluded from? my @array; @array[$subscript]; @array[$other]; @array[$subscript | $other]; # union That is valid already. @array[$subscript $other]; # intersection This'll do autothreaded, indexed access with the outcome of the all() junction. Regards, -- TSa (Thomas Sandlaß)
Re: Blocks, continuations and eval()
Larry Wall [EMAIL PROTECTED] writes: On Tue, Apr 12, 2005 at 11:36:02AM +0100, Piers Cawley wrote: : wolverian [EMAIL PROTECTED] writes: : : On Fri, Apr 08, 2005 at 12:18:45PM -0400, MrJoltCola wrote: : I cannot say how much Perl6 will expose to the high level language. : : That is what I'm wondering about. I'm sorry I was so unclear. : : Can you tell me what your idea of a scope is? I'm thinking a : continuation, and if that is what you are thinking, I'm thinking the : answer to your question is yes. : : Yes. I want to know how Perl 6 exposes continuations, and how to get one : for, say, the current lexical scope, and if it has a method on it that : lets me evaluate code in that context (or some other way to do that). : : As I understand what Larry's said before. Out of the box, it : doesn't. Apparently we're going to have to descend to Parrot to write : evalcc/letcc/your-preferred-continuation-idiom equivalent. We'll make continuations available in Perl for people who ask for them specially, but we're not going to leave them sitting out in the open where some poor benighted pilgrim might trip over them unawares. Oh goody! Presumably we're initially talking of a simple 'call_with_current_continuation'?
Re: Win32 with ICU files build problem
Hi Mark, I was able to compile parrot yesterday night. I compiled icu and copied the contents of the directory icu/include (two directories) manually to parrot/src. After that the compiler didn't complain anymore and I got a working parrot.exe. The --icudatadir I pointed to the out directory in my icu-build. Hope that helps. Christian Sporer On Apr 12, 2005 6:25 PM, Solinski, Mark [EMAIL PROTECTED] wrote: Following the instructions in README.Win32 (which has been successful for me in the past), no longer works successfully. First, I cannot run Configure.pl successfully; it complains about --icudatadir not being defined (again not one of the --icu* options mentioned in README.Win32 AND not necessary before). Defining --icudatadir, I now get the following error during make: Src\string_primitives.c(24) : fatal error C1083: Cannot open include file: 'unicode/ucnv.h': No such file or directory I had defined --icuheaders in my call to Configure in whose directory 'unicode/ucnv.h' does exist. Does this mean that Configure is ignoring --icuheader or --icuheader is ignored in the build of the file above? Has anyone successfully built Parrot on Win32 (MSVC 13.10.3077) recently? Mark Solinski
Re: Win32 with ICU files build problem
Solinski, Mark [EMAIL PROTECTED] wrote: Following the instructions in README.Win32 (which has been successful for me in the past), no longer works successfully. First, I cannot run Configure.pl successfully; it complains about --icudatadir not being defined (again not one of the --icu* options mentioned in README.Win32 AND not necessary before). Defining --icudatadir, I now get the following error during make: Note that you sent this to the wrong list (perl6-internals is for Parrot discussion, perl6-language is for discussion of Perl 6). I just recently saw some of this on Linux as well. I didn't go as far as to define --icudatadir, but I noticed that passing no icu options causes Configure.pl to autodetect icu. You might give that a shot. Please consider patching the documentation if what you find there doesn't work. -- matt diephouse http://matt.diephouse.com
Re: Slicing conflict
Larry Wall [EMAIL PROTECTED] wrote: On Tue, Apr 12, 2005 at 12:08:43AM -0700, Brent 'Dax' Royal-Gordon wrote: : @foo[1,3; *; 7] : : Which I rather like. Me too. Unless my memory is failing me, I believe that's what S09 already specifies. It does include a Cterm:* (d'oh, should've checked), but it doesn't specify how it works. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I used to have a life, but I liked mail-reading so much better.
Summary for the week ending 2005-04-12
The Perl 6 Summary for the week ending 2005-04-12 Whoa! Deja vu! Where'd Matt go? Don't worry, Matt's still writing summaries. As you may have noticed, Matt's been writing summaries every two weeks. And now so am I. Because we love you, we've decided to arrange things so I write summaries in the weeks when Matt doesn't. We could do it the other way, but that could be seen by some as self-defeating. Heck, when I say 'some' I probably mean 'all'. So, bear with me while I remember how to type all those accented characters and get back into the swing of writing these things (and of reading everything in the mailing lists once more -- someone should write a summary for us summarizers...) I'll be sticking to my old 'lists in alphabetical order' scheme of writing summaries. So, let's get going This week in perl6-compiler Array of arrays, hash of hashes, elems, last Lev Selector asked for confirmation that Pugs didn't support compound data structures, @ar.elems or @ar.last. Autrijus and others confirmed that they didn't then, but they do now. http://xrl.us/fq99 MakeMaker6 stalls on takeoff Darren Duncan pointed out that, whilst last week's summary had claimed he was working on implementing MakeMaker in Perl 6 which is, sadly not the case. He reckoned he'd possibly look into it again when he had tuits and Pugs was more complete (supporting objects, for instance). http://xrl.us/fraa Declaration oddness Roie Marianer pointed out what looks like some weirdness in Pugs' parsing of lexically scoped subroutines. Warnock applies. http://xrl.us/frab Toronto pugs hackathon John Macdonald asked for people who wanted to come to the YAPC::NA pugs hackathon to get in touch with him beforehand as spaces there are limited. If you're interested, drop him a line. http://xrl.us/frac Pugs slice oddities Andrew Savige noticed some weirdness in pugs's slicing behaviour. He posted some example code showing the problem. Autrijus agreed that there was a problem and explained that he was in the process of rewriting all the variable types, symbol tables and casting rules to agree with the Perl 5 model as described in perltie.pod. The rewrite is currently failing tests, so he posted a patch for people who want to play. On Sunday, he bit the bullet and committed the entire 2500 line patch which 'touches pretty much all evaluator code'. http://xrl.us/frad -- Autrijus's patch http://xrl.us/frae -- Autrijus on the patch http://xrl.us/fraf Meanwhile, in perl6-internals Tcl, Unicode William Coleda has been trying to add Unicode support to his TCL implementation and he fell across issues with missing methods in charset/unicode.h. Leo waved a magic wand and checked in an implementation which he fenced about with disclaimers. http://xrl.us/frag The status of Ponie Nicholas Clark confessed that Ponie had been pretty much stalled for some time, but sweetened the pill by announcing that it's about to restart and that he would be able to allocate at least one day a week to the project. He pointed people at the Ponie roadmap which breaks down the required tasks between here and a first release, complete with time estimates. If you're interested in getting Ponie to a ridable state, this would be a good place to start. People were pleased. http://xrl.us/frah -- Ponie intro/roadmap http://xrl.us/frai Monthly release schedule Chip donned his Fearless Leader hat and announced that, effective, Parrot would be moving to a monthly release schedule (with an initial three week 'month' to get things into sync). There was some debate about whether Solaris/SPARC should be one of the officially required monthly release platforms (darwin, linux-x86-gcc3.* and win32-ms-cl were Chip's initial blessed three). This morphed into a discussion of Tinderbox; apparently there are cool things happening behind the scenes. http://xrl.us/fraj Calling convention abstraction What do you know? You go away for n months and when you come back people are *still* talking about calling conventions. http://xrl.us/fram Dynamic Perl, Part 1 William Coleda announced that he was starting work on removing the core's dependence on Perl* PMCs in favour of using language agnostic PMCs internally and loading the Perl ones dynamically as required. Everything but PerlArray was dealt with quickly and names and ways forward with that tricky case were discussed. It looks like we're going to have a 'ResizablePMCArray' added to the core once people have the tuits. http://xrl.us/fran Subversion Another discussion that wouldn't go away back when I was last writing summaries has come to a head. Parrot's finally migrating from CVS to Subversion. By the time
Pugs 6.2.0 released.
I am delighted to report that the first major milestone of Pugs, version
6.2.0, has been released to CPAN:
http://wagner.elixus.org/~autrijus/dist/Perl6-Pugs-6.2.0.tar.gz
SIZE (Perl6-Pugs-6.2.0.tar.gz) = 642482
MD5 (Perl6-Pugs-6.2.0.tar.gz) = 8d5438d49db872ffe2394fd4995d335b
It represents the culmination of 71 days of intensive work, by more
than 60 people in our committer team, with nearly 2000 revisions.
According to the roadmap in PA01, this and the next milestone are:
6.2: Basic IO and control flow elements; mutable variables; assignment.
6.28: Classes and traits.
In other words, we are now reasonably confident that the basics of
Perl 6 syntax and data structures are in place. We already have an
object/type system now, and the 6.2.x series will make them available
on the language leve, together with a full-fledged class system.
After this release, I will take a short break from coding Pugs, and
focus on writing Pugs Apocryphon 2: Design of Pugs. In it I will
explain the relation of the various components in Pugs, as well as how
it relates to Parrot, GHC, and other systems. Once it is written,
I plan to start working on the IMC subsystem, with the goal of making
Parrot IMC the primary target for the 6.28.0 release.
Again, thanks too all lambdacamels for making this release possible,
and for building this new ship with me.
Enjoy,
/Autrijus/
== Changes for 6.2.0 - April 13, 2005
=== Pugs Internals
* Major refactor of ITypes subsystem, we now have:
** Nested structures: `$a{1}[2]{3}`
** Autovivification: `$a{1}[2]{3} = b`
** Tied magic: `%ENVUSER`
** Proxy scalars: `%ENVPATH ~= '/tmp'`
** Slice assignment: [EMAIL PROTECTED],2] = a b`
** Anonymous arrays: `[1..10][0] = 0`
** Lazy IArray structures: Infinite lists, constant time
** Infinite slices: [EMAIL PROTECTED]
** and much much more ...
* Experimental support for link external Haskell libraries
** One such module is SHA1.pm: http://tpe.freepan.org/repos/ingy/SHA1/
* New builtins:
** `sum`, `log`, `log10`, `sign`, `pi`, `tan`, `cos`, `atan`
** `zip`, `hash`, `pair`, `isa`, `bytes`, `chars`, `codes`, `graphs`
* New type specific builtins;
** `.kv`, `.pairs`, `.delete`, `.exists`
** `.pick`, `.keys`, `.values`
* Several file test operators
** `-r`, `-w`, `-x`, `-e`, `-z`, `-s`, `-f`, `-d`
* Support for `$*UID`, `$*EUID`, `$*GID`, and `$*EGID` on *nix
* Stacked file test operators now (mostly) work
* Added `is rw` trait for subroutine parameters
* `$*PID` now works on *nix systems
* Several command line switches implemented: `-I` `-p` `-n` and more
* `s:perl5/.../{ code }/` works correctly
* Type casting errors are now more descriptive
* `require ` now works on UTF-8 files
* Regex substitution is now UTF-8 safe
* `sort {}` now works
* Some support for the /splat/ star `*`
=== Tests, Examples and Documentations
* Many new tests and cleaning up of older tests, we now have 4200+
* `examples/games/hangman.p6` added which uses the `AUTHORS` file as
the dictionary file
* `READTHEM` added; recommended reading for aspiring Pugs hackers
* The Perl 6 Cookbook is well underway at `examples/cookbook/`
* Working perl6 modules added to `ext/`
** CGI.pm
** lib.pm
** HTML::Entities
* Several Working Drafts added to `docs/`
** Apocalypse 20 - Debugging
** Synopsis 26 - Perl Documentation
** Synopsis 28 - Special Variables
** Synopsis 27 - Perl Culture (with CPAN drinking game rules)
** Synopsis 29 - Builtin Functions
* Early work on Perl 6 Object System in `docs/class/`
=== Bug Fixes
* Parens no longer required for; `last()` and `return()`
* Fixed issue with binding invocant parameters
* Fixed parsing issue with `lc $, $y`
* `$_` now behaves correctly in most cases
* `exit()` now triggers `END {}` correctly
* `undef $x` now works correctly ($x is rw)
* Fixed parsing of default parameters: `sub foo (+$x = 3, +$y = 4)`
* `say` and `print` now default to `$_`
* `map { ... } @list` now parses correctly
* `loop { ... }` no works correctly
* `int(3) + 4` now parses correctly
* Fix parsefail bug on false unaries
* `for (@list)` no longer flattens [EMAIL PROTECTED]
* `$var.method $param` is now illegal: use `$var.method($param)`
* `readline()` is now strict in list context
* `$list.join('|')` now works
* `xor` and `^^` now short-circuits
* Named bindings to `%_` repaired
pgpoAIqOTByVr.pgp
Description: PGP signature
trim() and words() functions?
Hey all, not sure if I'm just missing some obvious source of information, but I used trim() as a function in a cookbook example, then realized that it's not even in S29... There is a brief mention of trim(), as well as words() (odd as the words() function may seem, to me at least), at http://tinyurl.com/6fjda but it hardly seems definitive. Trim sure is handy and would get used a lot, I think. But boy do I need to study up on my Unicode: I have such a hard time believing that words() is practical for CJK. It sure would be cool I guess, if that did work. Any validation on whether either, both, or neither of those functions is supposed to exist? Just to throw another question in the works and perhaps gunk up the machine, the link above also talks about whether or not these functions would exist as methods to strings and arrays. I'm certainly not clear on what the outcome of that is? I've been writing examples as if that's a possibility and no one seems to be disputing those, so I apologize if I just need to be pointed to where methods v functions is clarified. Perhaps a good next synopsis would be to start putting some docs around the String and Array object methods? Again, sorry if I'm missing that in some obvious location already. Thanks! Marcus
Re: trim() and words() functions?
gcomnz wrote: Hey all, not sure if I'm just missing some obvious source of information, but I used trim() as a function in a cookbook example, then realized that it's not even in S29... There is a brief mention of trim(), as well as words() (odd as the words() function may seem, to me at least), at http://tinyurl.com/6fjda but it hardly seems definitive. Trim sure is handy and would get used a lot, I think. But boy do I need to study up on my Unicode: I have such a hard time believing that words() is practical for CJK. It sure would be cool I guess, if that did work. Any validation on whether either, both, or neither of those functions is supposed to exist? Well, some form of words() exists... only spelled q:w//, with various doublings of q and w available, some of which can be spelled or «», though to be honest, I've lost track of how often the meanings of those as quoters has changed. I suspect S02 or S03 would have that answer. As for whether or not these actually exist, I'd like a bit more consensus that they are actually needed as builtins. One side of me says Hey, we've got them all seperated into different namespaces now, so we're not really getting polluted, so sure, let's add anything that's in the least bit useful. The other side of me then starts to say bloated. I'm not sure where the balance on this lies, and will yield to the will of those better at language design than myself. Just to throw another question in the works and perhaps gunk up the machine, the link above also talks about whether or not these functions would exist as methods to strings and arrays. I'm certainly not clear on what the outcome of that is? I've been writing examples as if that's a possibility and no one seems to be disputing those, so I apologize if I just need to be pointed to where methods v functions is clarified. Many of them will happen in S29, since there's an odd duality that class based multi subs exist in. I don't pretend to fully understand it, but look at http://www.nntp.perl.org/group/perl.perl6.language/19802 for insight. -- Rod Adams
Re: trim() and words() functions?
Rod Adams wrote: Well, some form of words() exists... only spelled q:w//, with various doublings of q and w available, some of which can be spelled or «», though to be honest, I've lost track of how often the meanings of those as quoters has changed. I suspect S02 or S03 would have that answer. I must have misunderstood the original discussion that I linked to. When i saw words() I assumed words($string), and that it was a split by 'words' function. Sorry if that was my dumb error. I'm aware of q:w//, just didn't realize that's what I was seeing. As for whether or not these actually exist, I'd like a bit more consensus that they are actually needed as builtins. One side of me says Hey, we've got them all seperated into different namespaces now, so we're not really getting polluted, so sure, let's add anything that's in the least bit useful. The other side of me then starts to say bloated. I'm not sure where the balance on this lies, and will yield to the will of those better at language design than myself. I agree, with my (probably wrong) impression that words() was a split a string into words function, I was thinking to myself bloat, but then I was also reminding myself that Perl's power as a natural language text processor has always been a premium feature (somehow even prior to full Unicode). Marcus Adair
Re: trim() and words() functions?
I agree, with my (probably wrong) impression that words() was a split a string into words function, I was thinking to myself bloat, but then I was also reminding myself that Perl's power as a natural language text processor has always been a premium feature (somehow even prior to full Unicode). On the other hand: words() as i (mis-)understood it, probably is perfectly covered by Rules, sure does seem like bloat that's unlikely to be in the final spec now that I continue thinking about it :) Marcus Adair
Hyper operator corner case?
Hey folks, I wanted to delurk and address an issue that may need clarification in regards to hyper operators. Quoting S03: If one argument is insufficiently dimensioned, Perl upgrades it: (3,8,2,9,3,8) - 1; # (2,7,1,8,2,7) Now in this example case, it's pretty clear that the scalar 1 gets turned into a list of 1s with the length of the lhs. What about the case of a larger-dimensioned or single-dimensioned array? Example: (1,2,3,4,5) + (1,2) Is this equivalent to: a) (1,2,3,4,5) + (1,2,undef,undef,undef) (undef padding) b) (1,2,3,4,5) + (1,2,1,2,1) (repetition) c) (1,2,3,4,5) + (1,2,2,2,2) (stretching) d) (1,2) + (1,2) (truncation) e) something else, ie, warnings about mismatched dimension, die(), segfault, kill -9 1 (whatever your sadism level is). Additionally, I was wondering if there was a difference between: (3,8,2,9,3,8) - 1 and (3,8,2,9,3,8) - (1) I suppose the answer to that depends on the answer to the above question. If the answer is the a) case as above and undef resolves to 0 numerically, then we run into another issue to consider. In the case of addition and subtraction, 0 is the identity element, and so: (1,2,3,4,5) + (1,2) yields (2,4,3,4,5). But the intuitiveness goes away with multiplication, and completely blows up with division: (1,2,3,4,5) * (1,2) yields (1,4,0,0,0), probably not what we wanted. (1,2,3,4,5) / (1,2) yields (1,1,NaN,NaN,NaN), and probably die()s with division by zero errors. If in the addition and subtraction cases we want to preserve the identity cases for the slots not accounted for, undef is fine because it resolves to 0; to provide the same features for multiplication and division, the identity element would have to be 1. But that would suppose that the potential hyper-operators would know what their appropriate identity elements were (and that such a thing is meaningful to them). Additionally, if there is a difference between the automatic scalar promotion and list promotion, we could run into errors where people would expect an expression to be a scalar which would be promoted in the documented fashion, but would really be promoted in one of a)-e), breaking what they expected: (1..5) + ($a-$b) # list context for the expression? Promotes like what? (1..5) + +($a-$b) # forced scalar context -- promotes like documented. (1..5) + (1) # promotes like what? Thoughts? David Christensen
Re: trim() and words() functions?
On Tue, Apr 12, 2005 at 09:52:38PM -0500, Rod Adams wrote: : gcomnz wrote: : : Hey all, not sure if I'm just missing some obvious source of : information, but I used trim() as a function in a cookbook example, : then realized that it's not even in S29... : : There is a brief mention of trim(), as well as words() (odd as the : words() function may seem, to me at least), at : http://tinyurl.com/6fjda but it hardly seems definitive. : : Trim sure is handy and would get used a lot, I think. But boy do I : need to study up on my Unicode: I have such a hard time believing that : words() is practical for CJK. It sure would be cool I guess, if that : did work. A words() function would only be useful for space-separated CJK. : Any validation on whether either, both, or neither of those functions : is supposed to exist? : : : Well, some form of words() exists... only spelled q:w//, with various : doublings of q and w available, some of which can be spelled or «», : though to be honest, I've lost track of how often the meanings of those : as quoters has changed. I suspect S02 or S03 would have that answer. Yes, it's a dup of «$string», so we probably don't need words(). On the other hand, there's no trivially obvious way to trim whitespace from both ends of a string. (Not that «$string» is *entirely* obvious either...) Of course, generations of Perl programmers have made do with various forms of s///, trudging miles through the snow, uphill both ways. : As for whether or not these actually exist, I'd like a bit more : consensus that they are actually needed as builtins. One side of me says : Hey, we've got them all seperated into different namespaces now, so : we're not really getting polluted, so sure, let's add anything that's in : the least bit useful. The other side of me then starts to say : bloated. I'm not sure where the balance on this lies, and will yield : to the will of those better at language design than myself. Hmm, where there's a way, there's a will, I guess. Larry
