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
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.
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
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
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 a b c, 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 a b c, 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, a b c 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 qq:to/EOTEXT/, $target here doc here ... EOTEXT Any comments? Marcus
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 Csubstr), 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 Csubstr), 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.
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/
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 Itext or Ctext 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
