Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On Thu, 17 Mar 2005 16:16:00 -0700, gcomnz <[EMAIL PROTECTED]> wrote: Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote: >By the way, I think I've seen a few people suggest some sort of >syntax-switching mechanism for "Pod6". The day people have to think >about what dialect of Pod they're using is the day Pod dies as a >useful documentation language. 1. TMTOWTDI 2. Competition will help, not hinder. I for one would very much like to see a more Wiki and less POD like syntax. But that's a matter of taste. I will say though that I've never heard of anyone suffering because of how wide or narrow the [ and ] characters are in Wiki markup ;-). And MediaWiki's format is a beautiful example of a markup that has taken off and vastly simplified page creation and editing for over 100,000 editors at Wikipedia. 3. A format like I or C is just plain ugly and verbose. I can't imagine why anyone defends that as something too keep. In understand there's a lot of love/hate emotion when it comes to Wiki's, but if we step back and ignore for a moment what the alternatives are will we really still want to keep that ugly inline syntax? (No disrespect intended, POD clearly predates of lot of other ideas about simple markups.) Marcus
Re: (pugs) Managing pleac
I'd really like to contribute, but I'm wondering if for the first phase a wiki would help the community pull together the best practice for each recipe? I'm thinking mediawiki style, where there's a discussion page attached to each wiki page. Would it help the conversation progress quickly (and grow and cross reference the recipe collection more)? I'd be happy to put one up if that seemed helpful, or perhaps there's a preferred place for such things...(or maybe every really just prefers SVN annotations ;) ) Marcus Adair On 4/9/05, Ovid <[EMAIL PROTECTED]> wrote: > http://groups-beta.google.com/group/perl.perl6.language/browse_frm/thread/b29d689814d0a50e/bd6ed3ba5ee17ffb#bd6ed3ba5ee17ffb > > Following up on Tim Bunce's April 1st suggestion that we implement > PLEAC (http://pleac.sourceforge.net/), I've gotten a few things started > in examples/pleac, but I think it's time to step back and think > seriously about how to organize this stuff. > > pleac will essentially be a Perl6 Cookbook modeled after the second > edition Perl Cookbook. I've laid out a directory and filename > structure/format that will make it very easy to look things up and I've > added a few sample programs, but I realize that there are a few issues > with my approach. > > 1. I stop coding a particular bit when I hit a bug in Pugs. > 2. Perl6 is more expressive than Perl5 and I rather think the Perl5 > recipes are limiting. > > Here's what I'm asking: > > 1. Should we just write out full examples, even if Pugs won't compile > 'em? Seems more sensible to me. > 2. POD docs? Does it matter? > 3. Add recipes that more accurately reflect Perl6's strengths? That > goes beyond pleac, but I'd much rather see this as a resource that Perl > programmers can really rely on. > 4. Are the filenames portable? > (examples/pleac/05hashes/05-05traversing.p6) > > Regarding question 1: if we only add code as Pugs can handle it, we > always have working code examples. However, how do we know which code > we should update? If we write up full examples, there's less > maintenance, but we're also less likely to spot syntax errors since a > lot of code won't even compile. > > And please, if you have commit access, feel free to correct my code and > add more. I don't want to do this by myself. > > http://svn.openfoundry.org/pugs/examples/pleac/ > > Cheers, > Ovid > > -- > If this message is a response to a question on a mailing list, please send > follow up questions to the list. > > Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/ >
Re: (pugs) Managing pleac
Autrijus, let me convert a few recipes first, to earn it ;-) I guess the only thing I'd really like to see is a lot of random community improvements around commits to the recipes, for one. I know that I've got a long way to "getting" the best practices for Perl 6. I guess my sense of versioned source is that it's not readable the way a book or a wiki is, and perhaps there's also less of an editorial sweep, the way both books and wikis have, where people who perhaps don't create a lot of content go through and clean up a lot of content (or rather, code, in this case). That said, svn is probably fine...just my two cents. Marcus On 4/9/05, Autrijus Tang <[EMAIL PROTECTED]> wrote: > On Sat, Apr 09, 2005 at 10:17:12PM -0600, Luke Palmer wrote: > > gcomnz writes: > > > I'd really like to contribute, but I'm wondering if for the first > > > phase a wiki would help the community pull together the best practice > > > for each recipe? > > > > Yes, yes, yes. I am a strong believer in wiki, especially when most > > changes are small refactors rather than large rethinkings, as would seem > > to be the case here. > > Well, I've found that "doing wiki in svn", i.e. handing out committer bits > to all interested people, and put discussions in each file themselves > (often by summarizing mailing list or IRC discussion), has worked quite > well too, as it reduces the bitrotting between the actual code and the > discussions around them. gcomnz, would you like a committer bit? :-) > > That said, there is a pugs.kwiki.org wiki, and I'd also be happy if > people would like to use that to coordinate PLEAC efforts. > > Thanks, > /Autrijus/ > > >
Question about list context for String.chars
Hi all,
I'm writing a bunch of examples for perl 6 pleac and it seems rather
natural to expect $string.chars to return a list of unicode chars in
list context, however I can't find anything to confirm that. (The
other alternatives being split and unpack.)
# unpack
@array = unpack("C*", $string);
# split
@array = split /./, $string;
# this too?
@array = $string.split(/./)
# and how about this?
@array = $string.chars
# and this explicit list context?
@array = $string.chars[];
Thanks,
Marcus
Re: Question about list context for String.chars
I have to say I'm slightly confused too for some languages, especially for syllabic alphabets. At the same time, I'm pretty clear for CJK, Syllabaries, and alphabets, or at least I hope I'm clear (I guess I'm about to find out), .chars just returns the right unicode level for whatever the string contents requires. "abc".chars would return , which I'm guessing would be byte size usually. "ææè".chars would return <æãæãè>, which can probably be expressed with UTF8? > Aaron wrote: > Same here, though I have to admit that I'm slow on this whole Unicode > thing, so I'm not sure what you mean by "Unicode chars". For example, > are you expecting to get "f", "f", "i" or "ï" back when you say > "ï".chars? More interestingly, what about all of the Arabic ligatures > which someone who speaks that language might reasonably expect to get > back as multiple "chars", but they have their own Unicode codepoint > (e.g. ï which is "U+FCF3 ARABIC LIGATURE SHADDA WITH DAMMA MEDIAL FORM" > which you might expect to get "ï", "ï" from)? Any Arabic speakers to > confirm or deny this behavior of ligatures? From Apocalyps 5: "Under level 2 Unicode support, a character is assumed to mean a grapheme, that is, a sequence consisting of a base character followed by 0 or more combining characters." Marcus On 4/11/05, Aaron Sherman <[EMAIL PROTECTED]> wrote: > On Mon, 2005-04-11 at 14:12, Ingo Blechschmidt wrote: > > > gcomnz wrote: > > > I'm writing a bunch of examples for perl 6 pleac and it seems rather > > > natural to expect $string.chars to return a list of unicode chars in > > > list context, however I can't find anything to confirm that. (The > > > other alternatives being split and unpack.) > > > > I like that. > > Same here, though I have to admit that I'm slow on this whole Unicode > thing, so I'm not sure what you mean by "Unicode chars". For example, > are you expecting to get "f", "f", "i" or "ï" back when you say > "ï".chars? More interestingly, what about all of the Arabic ligatures > which someone who speaks that language might reasonably expect to get > back as multiple "chars", but they have their own Unicode codepoint > (e.g. ï which is "U+FCF3 ARABIC LIGATURE SHADDA WITH DAMMA MEDIAL FORM" > which you might expect to get "ï", "ï" from)? Any Arabic speakers to > confirm or deny this behavior of ligatures? > > Please be aware, I'm talking about ligatures above, NOT special letters > such as "Ã", which are their own letters, and cannot be decomposed into > "a", "e" without losing information. > > Given Parrot, what happens when you are presented with a Big5 string > that does not have a strict Unicode equivalent? Does .chars throw an > exception, or does it rely on the string to know how to "characterify > itself" according to its vtable? > > -- > Aaron Sherman <[EMAIL PROTECTED]> > Senior Systems Engineer and Toolsmith > "It's the sound of a satellite saying, 'get me down!'" -Shriekback > >
Re: Question about list context for String.chars
> > "abc".chars would return , which I'm guessing would be > > bytesize usually. > > Fair enough. > > > "日本語".chars would return <[EMAIL PROTECTED]@語>, which can probably be > > expressed with > > UTF8? > > I think you're confusing UTF8 (which can represent ALL Unicode > characters) and "the UTF8 subset which consists of one-byte > representations" (which happens to overlap with 7-bit ASCII). Perhaps my confusion is that I thought, perhaps wrongly, that since .chars returns a count that is appropriate for the given unicode level, that would mean that if it were able to return a list in list context then it would be with the right storage size as needed for the given string contents. For instance, just requires bytes for each element, while Kanji would require more. I'm leaving very wide room open here for me really misunderstanding how all this works. > > > >From Apocalyps 5: "Under level 2 Unicode support, a character > > isassumed to mean a grapheme, that is, a sequence consisting of a > > basecharacter followed by 0 or more combining characters." > > Marcus > > Hmmm... that doesn't answer the ligature question clearly though. That > answers for the case of combining diacritical marks: 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.
Here documents as positional parameters to a function call
Hey all, more pleac conversion questions: I can't prove with the docs that a heredoc will continue to work as positional params to a function call, particularly where it's not the first param: die "Couldn't send mail" unless send_mail <
Re: Question about list context for String.chars
> Rod wrote: > However, I do like the idea of treating a string as an array of chars. I > remember some discussion a while back about making [] on strings do > something useful (but not the same thing as C), but I forget how > it ended, and my brain is too fried to go hunt it down. But overall I > like that idea. Then you could just say: > > @array = $string[]; This all sounds nice and simple. My only question then is what about the instances where you specifically need the array of graphs, codes, bytes, or whatever? If we can do one, why not all? I recall that a good point Larry made previously is not to bend over backward to let C programmers still think like C programmers in Perl (sorry if my munging didn't get that just right). And to be honest I only came up with this question for the cookbook (pleac) examples, but I'm guessing there's some reasonable use for all this stuff outside of the C-thinking world?
Re: Question about list context for String.chars
> > > However, I do like the idea of treating a string as an array of chars. I > > > remember some discussion a while back about making [] on strings do > > > something useful (but not the same thing as C), but I forget how > > > it ended, and my brain is too fried to go hunt it down. But overall I > > > like that idea. Then you could just say: > > > > > > @array = $string[]; > > > > This all sounds nice and simple. My only question then is what about > > the instances where you specifically need the array of graphs, codes, > > bytes, or whatever? If we can do one, why not all? > > That's why C<$string.chars[]> was proposed -- it would be accompanied > by .graphs, .codes, and .bytes. That is all fine and dandy, but I > don't think I should have to think about unicode if i don't want to. > And if I understand correctly, that means that I want everything to > use chars by default. And C<$string[]> would be a nice shortcut for > that. Yes, that's sort of what I was arguing for, in an underhanded way. I agree that $string[] is a good shorthand for the most common usage ($string.chars[]) too.
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?
> 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
Comparing rationals/floats
More questions stemming from cookbook work... Decimal Comparisons: The most common recipe around for comparisons is to use sprintf to cut the decimals to size and then compare strings. Seems ugly. The non-stringification way to do it is usually along the lines of: if (abs($value1 - $value2) < abs($value1 * epsilon)) (From Mastering Algorithms with Perl errata) I'm wondering though, if C<$value1 == $value2> is always wrong (or almost always wrong) then should it be smarter and: a. throw a warning b. DWIM using overloaded operators (as in reduce precision then compare) c. throw a warning but have other comparison operators just for this case to make sure you know what you're doing I'd vote for b., but I don't know enough about the problem domain to know if that is safe, and realistically I just want to write the cookbook entry rather than start a math-geniuses flame war ;-) Which leads to another question: Are there $value.precision() and $value.accuracy() methods available for decimals? I'd really rather not do the string comparison if it can be avoided, maybe it's just the purist in me saying "leave the numbers be" :-) Apologies in advance if this is somewhere I missed. I did a lot of searching. Marcus Adair
Re: <[]> ugly and hard to type
> I never liked character sets. They introduced yet another exception to
> the parsing rules, and it irked me. If it weren't for the need to
> optimize character sets, I'd prefer to be Pythonized into using @{'a'
> .. 'z'}
Isn't that just a digression into the bad old pre-internationalized
days. Unicode-schmunicode, but I'm all about the internationalization,
even if I am just an English speaker, and Unicode makes it happen, so
I love it. And it's WAY too easy for me as an English speaker to
ignore or badly program so that Internationalization is more work than
it needs to be, so any effort to push me into character classes is
Good and I appreciate the discipline.
Re: use English
Aaron Sherman wrote: > As a side note, I'd like to suggest that "English" is just rubbing > people's noses in the fact that they're not allowed to program in their > native tongue. "Names" might be less in-your-face. Why are we even having to say use English or Names or whatever? Why not just make it a part of the core alongside the original short special var names? In my opinion the short version of special vars is one of the worst features of Perl, despite the fact that I like concise code. But then again, I'm not a golfer. Marcus Adair
