Re: [RFC] Perl6 Operator List, Take 5
On 2002-10-30 at 12:47:17, Larry Wall wrote: (Anybody know of a version of pine that does UTF-8?) Yes - it's called mutt. ☺ Seriously, I do highly recommend switching from pine to mutt. It's not a completely painless transition, since mutt is more ELMlike than PINElike, but I know many who have made the switch and never looked back. And mutt does do UTF-8 just fine, including converting automagically between it and various other character sets (whichever ones your iconv library knows about). And I continue to see no French quotes whatsoever in your messages, while those from other people either come through fine or come through with Latin-1 French quotes marked as UTF-8. Very odd. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
email encoding of the french quote characters (ISO_8859_1 0xab and 0xbb)
On Wed, 30 Oct 2002 at 12:17 -0800, Michael Lazzaro [EMAIL PROTECTED]: On Wednesday, October 30, 2002, at 11:58 AM, Larry Wall wrote: I'd even be willing to give up ´foo bar bazª meaning qw(foo bar baz) for this. I can't see that right (MacOSX Jaguar) in the email; to me it looks like a forwardtick and an, um, underlined 'a' -- but in spite of that, I'm game. It's just so pretty (when it works!) On my Mac, it's spelled «op» -- can others see that correctly, or do we have a sorry disconnect in the fonts, here, for us Mac folks? This concerns me, so forgive this partial digression. When I tried to read Larry's message there were no characters around the foo bar bas (which arrived as Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT) I just saw I'd even be willing to give up foo bar baz meaning qw(foo bar baz) for this. in both pine and lookout, and my spool files. I was quite surprized when I saw Larry's message quoted with the characters in question in Austin's message (arrived as Content-Type: text/plain; charset=us-ascii) I'd even be willing to give up «foo bar baz» meaning qw(foo bar baz) for this. How did they get transformed to the funny 0xb4 and 0xaa characters in Micheal's quote. (arrived as Content-Transfer-Encoding: quoted-printable_ ISO_8859_1 253 171 AB « LEFT-POINTING DOUBLE ANGLE QUOTATION MARK 273 187 BB » RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK
RE: [RFC] Perl6 Operator List, Take 5
-Original Message- From: Austin Hastings [mailto:austin_hastings;yahoo.com] How do you write a in a Windows based environment? (Other than by copying them from Larry's emails or loading MSWord to do insert-symbol) You could use the Character Map accessory to put the character into the clipboard, or press the alt and hold the alt key while typing 0171 (or 0187) alt+0171 alt+0187
Re: Iterators [was: worth adding collections to the core language?]
Luke Palmer wrote: I wonder if things should have a more general interface than numerical indices. I've wanted linked lists in perl, and every time I do a splice on an array I cringe for speed reasons. Heh, we could use my linked array implementation. Or not. Please have a look at list.c, which is the engine for *Array classes. But I think we need a concept of iterators in the core. There were some patches floating around. Dunno what happened to them. Luke leo
Re: Vectorizing operators for Hashes
%a ^:union[op] %b %a :foo[op]:bar %b I think that any operators over 10 characters should be banished, and replaced with functions. I'd agree with that. In fact probably anything over 4, and even 4 is seriously pushing it. I'll clarify that I am talking here about using adverbs. From A3 (about the colon): Hence, this operator modifies a preceding operator adverbially. ... It can be used to supply a ``step'' to a range operator, for instance. I would expect the length of these adverbs to fall in a range somewhat the same as properties. So a word like 'union' is reasonable, and even 'intersection' too. Ignoring hyperoperators, one might use an adverb thus: $a / $b : dbz_Inf to have a divide by zero be treated as Infinity. I can see scope for a bunch of adverbs that control how a particular hyperoperation works. Thus, perhaps: a ^[/] b : short to stop iteration when the shortest of two arrays is used up. But this assumes that the adverb applies to the ^[] hyperop, not the / op. Perhaps this is resolved thus: a ^[/ : dbz_Inf] b : short But I also suspect it would be good to be able to associate distinct adverbs with the lhs and rhs of a binary operation. So I thought perhaps one could go down the path of a ^ :step(2) [/ : dbz_Inf] :step(3) b : short Hmm. Perhaps hyperop adverbs are preceded with a ^ and one gets instead: a ^[/] b : dbz_Inf, ^short, ^step(2,3) -- ralph
Re: Vectorizing operators for Hashes
On 31 Oct 2002 at 0:40, John Williams wrote: On Wed, 30 Oct 2002, Me wrote: %a ^:union[op] %b %a :foo[op]:bar %b I think that any operators over 10 characters should be banished, and replaced with functions. I don't think there should be any upper limit for operator-lengths. e.g. When teaching perl to my little brothers (still at primary school) I might want to use alphabetical userdefined operators: print 1 + 5 - 4 / 2 print one plus five minus four divided_by two (and same in finnish) näytä yksi plus viisi miinus neljä jaettuna kaksi At least it wouldn't harm anyone to allow this. -- Markus Laire 'malaire' [EMAIL PROTECTED]
Re: [RFC] Perl6 Operator List, Take 5
* Dyck, David ([EMAIL PROTECTED]) [31 Oct 2002 19:21]: [...] You could use the Character Map accessory to put the character into the clipboard, or press the alt and hold the alt key while typing 0171 (or 0187) alt+0171 alt+0187 To be honest, as easy as it is to type ^a^v or ^k,[1] it's still typing an awful lot just to get a character. Surely the Perl operator Huffman encoding should take into account the length of time it takes to type the darn thing. Personally, I'm against non US-ascii chars being part of the core language. It's fine if people want their Unicode identifiers, or import modules to change operators, but I'd like to think I can at least read and write my own code in non-Latin-1 environments. [1] screen and vim respectively, although I could always make vim treat as an abbreviation for the guillemet, although that would interfere with heredocs), cheers, -- Iain, who carefully didn't use any « or » chars until just then. Oops.
Re: Vectorizing operators for Hashes
Uri Guttman writes:
%hash1.values [+]= %hash2{%hash1.keys} ;
but here is exactly example analogous to
my Dog $x = new Dog .
which was discusse dand turned to
my Dog $x .= new ;
It's (almost) clear what you want when you write
%hash1 [+]= %hash2 ;
so why to screen the meaning with several ( almost ) unnecessary
words .
And besides, If that will be usefull there will be somebody who will
make those shortcuts.
aracdi .
Perl6 Operator List (REMAINING ISSUES)
Michael Lazzaro writes: OK, by my count -- after editing to reflect Larry's notes -- only a few issues remain before the ops list can be completed. 1) Need a definitive syntax for hypers, ^[op] and «op» have been most seriously proposed -- something that keeps a bracketed syntax, but solves ambiguity issues. 2) Possible inclusion of unary prefix ^, meaning complement. (Assuming doesn't conflict with (1)) 3) Possible inclusion of like/unlike or similar as synonyms for ~~ !~. Which we don't have to decide now. All other op issues, by my count, revolve around the meanings of specific hyperop constructs. There is one, overriding question with the hyperops, which is the precise relation between an op, an assignment op, and their (three!) hyperop equivs: A op B A op= B A ^[op] B A ^[op=] B A ^[op]= B If we can formalize the precise relationship between the three hypers in the presence of scalar and list (and hash?) values for A and B, I believe we can answer nearly all the hyperop questions definitively. For example: a ^[op] b # array v array $a ^[op] b # scalar v array a ^[op] $b # array v scalar $a ^[op] $b # scalar v scalar a ^[op=] b # array v array $a ^[op=] b # scalar v array a ^[op=] $b # array v scalar $a ^[op=] $b # scalar v scalar a ^[op]= b # array v array $a ^[op]= b # scalar v array a ^[op]= $b # array v scalar $a ^[op]= $b # scalar v scalar and also this : %a ^[op]= b # hash v array %a ^[op]= $b # hash v scalar %a ^[op]= %b # hash v hash a ^[op]= %b # array v hash $a ^[op]= %b # scalar v hash Some of these are nonsensical, some of them aren't. So which are which, and can someone demonstrate that the rule holds true for ALL hyperoperators, as opposed to just MOST? ;-) MikeL arcadi
Re: Vectorizing operators for Hashes
Me writes: %a ^:union[op] %b %a :foo[op]:bar %b I think that any operators over 10 characters should be banished, and replaced with functions. I agree. But I think that we can get away here with just hash properties , just like hash behaviour in regexps is controlled by properties . e.g. union: (%a,%b) ^is no_strict_keys ; (%a %b) ^is default_value ( 0 ) ; %a ^[+] %b intersection : (%a,%b) ^is strict_keys ; %a ^[+] %b this maybe longer but clear : one line - one concept . but I am not shure ... arcadi .
Re: [RFC] Perl6 HyperOperator List
Yesterday Aaron Crane wrote: Jonathan Scott Duff writes: a `+ b In my experience, many people actually don't get the backtick character at all. Yes. I think that might be a good reason _for_ using backtick in vector operators: * Backticks aren't used in any other operators, so they would not be mistaken for xor nor arrays. Backticks also look a little odd, so even if it isn't intuitive as to what is going on, somebody seeing a vector op for the first time should at least spot that _something_ different is happening. * People starting out in Perl wouldn't want to use vector ops straight away (there are enough other things to be learning). So a character that involves 'advanced' typing is used for an 'advanced' feature. A pair of backticks could be used if the vector-equals distinction is required: a `+`= b; a `+=` b; I always hate teaching people what backticks do -- not because the concept is difficult, but because the syntax is so alien to so many people. So I teach qx// for Perl, and $() for Unix shell, and I throw in backticks as an extra 'you might also see this' affair. I don't think backticks for vector conflicts with backticks for invoking a shell (cos the latter is a term not an op), I'd be in favour of removing the current backtick behaviour anyway: * It looks like quoting, and it isn't really. It's more like a function call. * Many people use backticks when Csystem() is desired. The fact that these two similar features look so different from each other us confusing. Also, if backticks were to be used for vector ops then removing the existing use would mean that backticks are _only_ for vector ops. No 'small exceptions' -- the very simple rule that backticks are always vector ops. Anyway, that was a bit of a rant, but what I mean is: I'd actually be in favour of avoiding backtick entirely in operators. I can see where you're coming from there. They are an awkward glyph. But Larry's short enough of characters as it is: I don't think we can afford to throw one away entirely, however unpleasant it is. Smylers
Re: [RFC] Perl6 HyperOperator List
On Thu, Oct 31, 2002 at 12:16:34PM +, [EMAIL PROTECTED] wrote: Yesterday Aaron Crane wrote: Jonathan Scott Duff writes: @a `+ @b In my experience, many people actually don't get the backtick character at all. Yes. I think that might be a good reason _for_ using backtick in vector operators: A pair of backticks could be used if the vector-equals distinction is required: @a `+`= @b; @a `+=` @b; Thats ugly, IMO. Now this is going to sound wild (probably) and I have not thought too much about it and there are probably others who can see the pitfalls quicker then me. But could () be available for hyper operators ? I will sit back now and watch the firewaorks, as I wont be in the UK on Nov 5 :-) Graham.
RE: [RFC] Perl6 Operator List, Take 5
--- Dyck, David [EMAIL PROTECTED] wrote: -Original Message- From: Austin Hastings [mailto:austin_hastings;yahoo.com] How do you write a in a Windows based environment? (Other than by copying them from Larry's emails or loading MSWord to do insert-symbol) You could use the Character Map accessory to put the character into the clipboard, or press the alt and hold the alt key while typing 0171 (or 0187) alt+0171 alt+0187 Well, that certainly flows fluidly from the fingertips... ^[op], you say? Or I could finally figure out how to program the function keys on my keyboard, I guess... APL, here we come... =Austin __ Yahoo! - We Remember 9-11: A tribute to the more than 3,000 lives lost http://dir.remember.yahoo.com/tribute
Re: [RFC] Perl6 HyperOperator List
--- Damian Conway [EMAIL PROTECTED] wrote:
Austin Hastings wrote:
? ?| ?^ - [maybe] C-like bool
operations
?= ?|= ?^= - (result is always just 1 or
0)
[?][?|][?^] - (hyperversions)
[?]= [?|]= [?^]=
[?=] [?|=] [?^=]
Two possible differences between double-[|] and single-[|]:
1- Force (unlazy) evaluation of all operands.
2- Force conversion to 1 or 0. (Are true and false going to be
built-in literals, a la java?)
Which (or both) of these are supposed to come from the single-op
versions of these?
Superpositions don't lazily evaluate their operands (unless those
operands are themselves superpositions).
Sorry, let me be more explicit: Forget the flexops for now. What's a
C-like boolean single-letter do?
- [maybe] C-like bool operations
- (result is always just 1 or 0)
In the C that I learned, the ^| ops were bitwise.
Likewise, the || ops were lazy booleans.
So what's a single-letter boolean act like? Is it lazy? Does it retain
its bitwise-ness but (since boolean) force evaluation for 1 or 0 first?
I just don't understand what the implied behavior is, since the
reference is outside my experience.
$a = 1 | 5;
$a = 10;
What's $a?
1 | 5 10
Yes (by precedence)
Umm, is this wrong? As I understand it, that's the same as 1 | (510)
because of precedence, no?
(1|5) 10
Yes (explcitly).
(With apologies to the folks at Sesame Street):
One of these answers isn't like the other ...
One of these answers just doesn't belong ...
On the other hand, some of the examples seem counterintuitive. That
is,
considering Damian's:
$seen = $start | $finish;
for ... - $line {
print $line\n unless $line == $seen;
$seen |= $line;
}
I can understand the notion of unless $line is a-or-b-or-c-or...
but
I keep THINKING in terms of I've seen a-and-b-and-c-and...
That's understandable. So you write:
$seen = $start $finish;
for ... - $line {
print $line\n if $line != $seen;
$seen = $line;
}
Yeah, that's better. Thanks.
So when would multiple flexops be combined? Anyone have any real
world
examples, even simple ones?
Sure (for sufficiently complex values of simple ;-)
Here's how to find the love of your life:
$requirements = tall dark handsome
| old rich
| Australian;
for - $candidate {
my $traits = any( split /ws/, $candidate );
print True love: $candidate\n
if $requirements eq $traits;
}
Of course, not everyone can hope to be lucky enough to meet an
Australian, but you get the idea. ;-)
Well, thank God for small favors.
traits = any ( ... )
requirements = .. ..
if $requirements eq $traits
Should that be traits = all()?
I mean, assuming that the split returns only adjectives, you've got
something like:
short busty dark nymphomaniac father owns a chain of
liquor stores
in the requirements
and you've got
a | b | ... | z
in the traits
How do THOSE work together?
(In other words: Can you write Apoc.Flexible now, please?)
=Austin
__
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
Re: worth adding collections to the core language?
--- Damian Conway [EMAIL PROTECTED] wrote: Larry wrote: Possibly we might even extend the notion of hash to any junk. %hash = 1 | 2 | 3; So you're suggestion that a normal hash is a junction of pairs??? Damian Conway admits: Everything in Perl6 is 'Junk' Who can't see *this* coming on slashdot? :-) =Austin __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
UTF-8 and Unicode FAQ, demos
Here is an extensive FAQ for Unicode and UTF-8: http://www.cl.cam.ac.uk/~mgk25/unicode.html and here is a test file that will show you how many of the most common glyphs (WGL4, via Microsoft) you are capable of displaying in your current setup: http://www.cl.cam.ac.uk/~mgk25/ucs/wgl4.txt A reduced list of interesting characters is as follows. Note that I may not be sending them all correctly, as not all of them are available on OSX. And that not all interesting characters are a part of the WGL4 set. 00AB # « LEFT-POINTING DOUBLE ANGLE QUOTATION MARK 00BB # » RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK 00AC # ¬ NOT SIGN 2202 # ∂ PARTIAL DIFFERENTIAL 2206 # ∆ INCREMENT 220F # ∏ N-ARY PRODUCT 2211 # ∑ N-ARY SUMMATION 2219 # ÅE BULLET OPERATOR 221A # √ SQUARE ROOT 221E # ∞ INFINITY 221F # àA RIGHT ANGLE 2229 # Åø INTERSECTION 222B # ∫ INTEGRAL 2248 # ≈ ALMOST EQUAL TO 2260 # ≠ NOT EQUAL TO 2261 # Åfl IDENTICAL TO 2264 # ≤ LESS-THAN OR EQUAL TO 2265 # ≥ GREATER-THAN OR EQUAL TO 00D7 # Å~ MULTIPLICATION SIGN 00F7 # ÷ DIVISION SIGN 00B0 # ° DEGREE SIGN 00B1 # ± PLUS-MINUS SIGN 00B5 # µ MICRO SIGN 00B6 # ¶ PILCROW SIGN 2020 # † DAGGER 2021 # ‡ DOUBLE DAGGER 2022 # • BULLET 2026 # … HORIZONTAL ELLIPSIS 2030 # ‰ PER MILLE SIGN 00A1 # ¡ INVERTED EXCLAMATION MARK 00A2 # ¢ CENT SIGN 00A3 # £ POUND SIGN 00A4 # °Ë CURRENCY SIGN 00A5 # ¥ YEN SIGN 00A6 # ∫ BROKEN BAR 00A7 # § SECTION SIGN 00A8 # ¨ DIAERESIS 00A9 # © COPYRIGHT SIGN 00AA # ª FEMININE ORDINAL INDICATOR 00AD # ú SOFT HYPHEN 00AE # ® REGISTERED SIGN 00AF # ¯ MACRON 00B2 # ©˜ SUPERSCRIPT TWO 00B3 # ©¯ SUPERSCRIPT THREE 00B7 # · MIDDLE DOT 00B8 # ¸ CEDILLA 00BA # º MASCULINE ORDINAL INDICATOR 00BF # ¿ INVERTED QUESTION MARK 203C # ßÑ DOUBLE EXCLAMATION MARK 02C7 # ˇ CARON 02D8 # ˘ BREVE 02D9 # ˙ DOT ABOVE 02DA # ˚ RING ABOVE 2122 # ™ TRADE MARK SIGN 2126 # Ω OHM SIGN 2190 # Å© LEFTWARDS ARROW 2191 # Å™ UPWARDS ARROW 2192 # Å® RIGHTWARDS ARROW 2193 # Å´ DOWNWARDS ARROW 2194 # °Í LEFT RIGHT ARROW 2195 # ¢’ UP DOWN ARROW 0391 # Éü GREEK CAPITAL LETTER ALPHA 0392 # Ɇ GREEK CAPITAL LETTER BETA 0393 # É° GREEK CAPITAL LETTER GAMMA 0394 # É¢ GREEK CAPITAL LETTER DELTA 0395 # É£ GREEK CAPITAL LETTER EPSILON 0396 # ɧ GREEK CAPITAL LETTER ZETA 0397 # É• GREEK CAPITAL LETTER ETA 0398 # ɶ GREEK CAPITAL LETTER THETA 0399 # Éß GREEK CAPITAL LETTER IOTA 039A # É® GREEK CAPITAL LETTER KAPPA 039B # É© GREEK CAPITAL LETTER LAMDA 039C # É™ GREEK CAPITAL LETTER MU 039D # É´ GREEK CAPITAL LETTER NU 039E # ɨ GREEK CAPITAL LETTER XI 039F # É≠ GREEK CAPITAL LETTER OMICRON 03A0 # ÉÆ GREEK CAPITAL LETTER PI 03A1 # ÉØ GREEK CAPITAL LETTER RHO 03A3 # É∞ GREEK CAPITAL LETTER SIGMA 03A4 # ɱ GREEK CAPITAL LETTER TAU 03A5 # É≤ GREEK CAPITAL LETTER UPSILON 03A6 # É≥ GREEK CAPITAL LETTER PHI 03A7 # É¥ GREEK CAPITAL LETTER CHI 03A8 # ɵ GREEK CAPITAL LETTER PSI 03A9 # Ω GREEK CAPITAL LETTER OMEGA 03B1 # Éø GREEK SMALL LETTER ALPHA 03B2 # É¿ GREEK SMALL LETTER BETA 03B3 # É¡ GREEK SMALL LETTER GAMMA 03B4 # ɬ GREEK SMALL LETTER DELTA 03B5 # É√ GREEK SMALL LETTER EPSILON 03B6 # Ƀ GREEK SMALL LETTER ZETA 03B7 # É≈ GREEK SMALL LETTER ETA 03B8 # É∆ GREEK SMALL LETTER THETA 03B9 # É« GREEK SMALL LETTER IOTA 03BA # É» GREEK SMALL LETTER KAPPA 03BB # É… GREEK SMALL LETTER LAMDA 03BC # É GREEK SMALL LETTER MU 03BD # ÉÀ GREEK SMALL LETTER NU 03BE # Éà GREEK SMALL LETTER XI 03BF # ÉÕ GREEK SMALL LETTER OMICRON 03C0 # π GREEK SMALL LETTER PI 03C1 # Éœ GREEK SMALL LETTER RHO 03C2 # V GREEK SMALL LETTER FINAL SIGMA 03C3 # É– GREEK SMALL LETTER SIGMA 03C4 # É— GREEK SMALL LETTER TAU 03C5 # É“ GREEK SMALL LETTER UPSILON 03C6 # É” GREEK SMALL LETTER PHI 03C7 # É‘ GREEK SMALL LETTER CHI 03C8 # É’ GREEK SMALL LETTER PSI 03C9 # É÷ GREEK SMALL LETTER OMEGA MikeL
Re: Perl6 Operator List (REMAINING ISSUES)
On Thu, 31 Oct 2002 [EMAIL PROTECTED] wrote: : %a ^[op]= @b # hash v array : @a ^[op]= %b # array v hash What would those mean? Are you thinking only of hashes with numeric keys? Larry
Re: [RFC] Perl6 Operator List, Take 5
On Thu, 31 Oct 2002, Iain 'Spoon' Truskett wrote: : To be honest, as easy as it is to type ^a^v or ^k,[1] it's still Thanks, I didn't know it was that «easy» in vim. :-) : typing an awful lot just to get a character. Surely the Perl operator : Huffman encoding should take into account the length of time it takes to : type the darn thing. Sure, but that's only one half of Huffman. You also have to consider the frequency of use. (And as a second order effect, whether you want to discourage frequent use. :-) I personally think vector ops are pretty special, and should remain so. I have enough familiarity with (read: contempt for) APL that I don't want multi-dimensional operators to be the default, regardless of how they're spelled. Special ops should look special. : Personally, I'm against non US-ascii chars being part of the core : language. It's fine if people want their Unicode identifiers, or import : modules to change operators, but I'd like to think I can at least read : and write my own code in non-Latin-1 environments. Perl 6 is written in Unicode. This will cause more pain in the short term, but I'm trying to optimize for twenty years from now. (Yes, this message is in Latin-1, but that can be considered an encoding of the first 256 codepoints of Unicode.) Larry
Re: Vectorizing operators for Hashes
On Thu, 31 Oct 2002, Markus Laire wrote: : I don't think there should be any upper limit for operator-lengths. There will never be any official limits. Perl is not about arbitrary limits. But I will tell you that I only added = to Perl 5 because I knew there would never be a == operator. We'll have to relax that a bit for Perl 6, but we're still trying vaguely to avoid the Icon trap. Only compositions of operators will be allowed to get longer than 3 chars. And we try to keep the basic operators at 2 or less. The really great thing about the French quotes is that they visually keep the user aware of the composition. «+=» is obviously a variety of +=, whereas ^+= is not obvious, though shorter. (Square brackets are even better at that, but have other problems.) Larry
Re: Vectorizing operators for Hashes
Austin Hastings writes: --- [EMAIL PROTECTED] wrote: I agree. But I think that we can get away here with just hash properties , just like hash behaviour in regexps is controlled by properties . e.g. union: (%a,%b) ^is no_strict_keys ; (%a %b) ^is default_value ( 0 ) ; %a ^[+] %b intersection : (%a,%b) ^is strict_keys ; %a ^[+] %b this maybe longer but clear : one line - one concept . Arcadi, How would this work for hashes with differing properties? E.g., %a = (apple = 1, abacus = 2); %b = (banana = 3, abacus = 2); %a ^is strict_keys; %b ^is no_strict_keys; %c = %a ^[+] %b; What would happen? in the result hash there will be only keys of %a, because %b *can admit unknown keys*, but %a - cannot %a rules?: %c == (abacus = 4) %b rules?: %c == (apple = 1, abacus = 4, banana = 3) strict_keys filters result?: %c == (apple = 1, abacus = 4) =Austin arcadi
Re: Vectorizing operators for Hashes
Austin Hastings writes: but I am not shure ... sure thanks . sorry that I write so badly . I'll try to be better . (Unless you do this on purpose :-) Cheers, =Austin __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
Re: Vectorizing operators for Hashes
Me writes: union: intersection : How would this work for hashes with differing properties? %a ^is strict_keys; %b ^is no_strict_keys; What would happen? in the resulting hash only ( and all ) keys of %a will be present. because %b *admits* unknown keys but %a does not. although I admit that property names can be much better . That's one reason why I suggested control of this sort of thing should be a property of the operation, not of the operands. -- ralph arcadi .
Re: Vectorizing operators for Hashes
Larry Wall writes: On Thu, 31 Oct 2002, Me wrote: : That's one reason why I suggested control of this sort : of thing should be a property of the operation, not of : the operands. I think that by and large, the operator knows whether it wants to do union or intersection. When you're doing «+», it's obviously union that you want, with undef defaulting to 0. And «//» would want intersection. Larry so is really going to the direction that many official operators will be wysiwig Unicode staff like «+» , and then for some slice of the comunity there will be ( TeX - like ?? ) ascii shortcuts , because we need them ( what was the length of the tread to figure out how to write and read them ) . So perl take placeholders from Mathematica , vector operations from Matlab , and greek and all other funny characters from TeX : use TeX; \gamma = \alpha \hyper[\sum] \beta ; arcadi .
Re: Perl6 Operator List (REMAINING ISSUES)
Larry Wall writes:
On Thu, 31 Oct 2002 [EMAIL PROTECTED] wrote:
: %a ^[op]= @b # hash v array
: @a ^[op]= %b # array v hash
What would those mean? Are you thinking only of hashes with numeric keys?
Larry
no but hash can have property that tells how to turn its keys to
integer indexes if it fins itself in the ^[op] situation .
just like %hash can have a property that tells it how to behave in
regexp /%hash/ . And then just like here there may be some default
value for that property . I dont know what it should be . is it sane ?
%hash is if_in_vectorized_op_map_keys_to_integers_as { some function
returning integer }
arcadi .
Re: [RFC] Perl6 HyperOperator List
Thats ugly, IMO. Now this is going to sound wild (probably) and I have not thought too much about it and there are probably others who can see the pitfalls quicker then me. But could () be available for hyper operators ? I will sit back now and watch the firewaorks, as I wont be in the UK on Nov 5 :-) Graham. yes if you demand a prefix a ^(+=) b where ^ can be replaced (almost ) everything . arcadi .
Perl6 Operator List (REMAINING ISSUES)
Michael Lazzaro writes: OK, by my count -- after editing to reflect Larry's notes -- only a few issues remain before the ops list can be completed. 1) Need a definitive syntax for hypers, ^[op] and «op» have been most seriously proposed -- something that keeps a bracketed syntax, but solves ambiguity issues. 2) Possible inclusion of unary prefix ^, meaning complement. (Assuming doesn't conflict with (1)) 3) Possible inclusion of like/unlike or similar as synonyms for ~~ !~. Which we don't have to decide now. All other op issues, by my count, revolve around the meanings of specific hyperop constructs. There is one, overriding question with the hyperops, which is the precise relation between an op, an assignment op, and their (three!) hyperop equivs: A op B A op= B A ^[op] B A ^[op=] B A ^[op]= B If we can formalize the precise relationship between the three hypers in the presence of scalar and list (and hash?) values for A and B, I believe we can answer nearly all the hyperop questions definitively. as I understand , every such construct will be macro preprocessed parser and in real program ( that is in parrot ) there will be no vector operations in perl sence , only as optimizations . so I think that if we are talking about oprator list , we just can state ( and we did ) that such operators are present in language . their prcize functionality may be defined or changed by pragma or module. what I want to say is that we definitely have ^[op] staff so somebody in or out of sanity will ask ( or make a mistake ) what is %a ^[op] %b and the answer already is a question of ( Apo 29 ? ). the language have beasts $x, y, %z and they can talh through op , ^[op] , ... so they will , or at least try . although by the laws of jungle something can be made a taboo . But thats life... arcadi .
Re: UTF-8 and Unicode FAQ, demos
And if you really want to drool at all the neat glyphs that the wonderful, magical world of math has given us, check out: http://www.unicode.org/charts/PDF/U2A00.pdf now *theres* some brackets! MikeL
Re: Vectorizing operators for Hashes
On Thu, 31 Oct 2002, Me wrote: : That's one reason why I suggested control of this sort : of thing should be a property of the operation, not of : the operands. I think that by and large, the operator knows whether it wants to do union or intersection. When you're doing +, it's obviously union that you want, with undef defaulting to 0. And // would want intersection. Ok. So I accidentally got something right! ; (control of this sort of thing should be a property of the operation, not of the operands.) There are clearly some operations where adverbs make sense. Presumably one of the classes of op for which adverbs might make sense is hyperop. Assuming so, did my suggestion of ^adverb make sense to you as a way to distinguish op and hyperop adverbs? -- ralph
Re: Vectorizing operators for Hashes
Me writes: union: intersection : %a ^is strict_keys; %b ^is no_strict_keys; in the resulting hash only ( and all ) keys of %a will be present. because %b *admits* unknown keys but %a does not. Yes, but the general case is that one wants to be able to control nuances of (hyper)operations, and Larry introduced adverbs for precisely that reason. Just because one can get away with controlling this particular issue via noun adjectives (variable properties) does not mean one should. (Although, conversely, just because adverbs seem more more appropriate in this case doesn't mean one shouldn't for some reason use properties as you suggest.) there is one mor epossibility : temp sub infix:^[op] is force_hash_to_intersect ; ( I'm compleatly not sure about that sintax ) sinse vectorization of any op is orthogonal concept to details of that particular op , maybe we can controll behavior of that vectorization by ( ...? ) properties . we need it not only for hashes ; maybe somebody will wont ( 1,2 ) ^[op] ( 1, 2, 3 ) to return array of length 3 ; arcadi
RE: [RFC] Perl6 Operator List, Take 5
Larry Wall:
# Perl 6 is written in Unicode.
Great. That's a wonderful policy. But it *shouldn't influence routine
coding in any way*. I have no problem with user-defined Unicode
operators. I have a *huge* problem with built-in Unicode operators, and
a gargantuan problem with built-in Unicode operators that are generally
useful.
I can honestly say at this point that I'd rather give up $iterator
than lose hyperops. And I consider relegating them to the
digraphs losing them, because I'm never going to be able to remember how
to type them, and neither will anybody else.
Let's look at this logically. Here's all the punctuation (non-\w)
characters on my keyboard and what they do in Perl 6:
TERMOPERATORDOUBLE
OPERATOR
` backticks nonenone
' string constantsnone** none
string constantsnonenone
# comment comment comment
$ scalar sigilnonenone
@ array sigil nonenone
% hash sigil modulo none
sub sigil junction and** logical and
! logical not none (?)none
^ complement junction xor** logical xor**
| nonejunction or** logical or
/ regex divide defined or (in
5.9)
* list flatten* multiplyexponent
- numify and negate subtraction
postdecrement
+ numify**addition
postincrement
~ stringify* concat**smart
match
= noneassignment
comparison
\ get reference nonenone
.. method call** method call** range constructor
? force to bool* none** trinary operator
, nonelist composer list composer
; nonestatement end statement end
(in parentheses)super-comma none
: nonesuper-comma package
separator, trinary operator
( ) expression grouping sub parameters yuck
{ } hash composing hash subscripts yuck
block composing block composing yuck
[ ] array composing array subscriptsyuck
iterator syntax comparison ops shift-left, shift-right
UNUSED: 5 8 9
Items marked with a * are new, ** are changed. There are twenty-two
'none's on that list, but none of them line up. (Isn't Perl great?!?)
';;' is available (it doesn't mean anything in either term or operator
context), but it's really ugly. The other possibilities I see there
have the same problem.
There are potentially some meaningless sequences, especially with
sigils, but those'll look quite cluttered. Actually, one of the few
good meaningless ones is ^[op] (with the square brackets). In term
context it would normally mean bitwise complement this array, and in
operator context it would mean add this array to an xor junction. If
we lose xor junctions (which I'm not necessarily advocating, mind you),
this sequence is pretty much open.
Damn. Larry, I don't envy you your job. :^)
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Re: UTF-8 and Unicode FAQ, demos
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Date: Thu, 31 Oct 2002 10:11:00 -0800 From: Michael Lazzaro [EMAIL PROTECTED] X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/ And if you really want to drool at all the neat glyphs that the wonderful, magical world of math has given us, check out: http://www.unicode.org/charts/PDF/U2A00.pdf now *theres* some brackets! Ooh! Let's use 2AF7 and 2AF8 for qw! MikeL
Re: plaintive whine about 'for' syntax
Ed Peschko wrote:
Larry Wall writes:
I think decent formatting would make it clearer:
fora; b
- $x is rw; y {
$x = $y[5];
}
But this isn't very scalable:
Sure it is. You just have to think more two-dimensionally...
for a; b; c; d; e
- $a_variable1 is rw, $a_variable2 is rw;
$b_variable is rw;
$c_variable is rw;
$d_variable is rw;
$e_variable1 is rw, $e_variable2 is rw
{
}
:-)
BTW, Both Larry and I do understand the appeal of interleaving
sources and iterators. We did consider it at some length back
in January, when we spent a week thrashing this syntax out.
Of course, I can't speak for Larry, but in the end I concluded
that interleaving iterator variables is a false win, since it
trades reduced syntactic complexity for increased semantic
complexity, but only really improves the readability of a
comparatively rare case.
Damian
Re: [RFC] Perl6 HyperOperator List
Austin Hastings wrote: In the C that I learned, the ^| ops were bitwise. Likewise, the || ops were lazy booleans. So what's a single-letter boolean act like? Is it lazy? Does it retain its bitwise-ness but (since boolean) force evaluation for 1 or 0 first? I just don't understand what the implied behavior is, since the reference is outside my experience. Since they're producing a boolean result, both C? and C?| could be implemented lazily. However, I suspect they mightn't be, just to keep them consistent (in their evaluation of operands) with the other bitwise ops. What's $a? 1 | 5 10 Yes (by precedence) Umm, is this wrong? Yep. Sorry. (1|5) 10 Yes (explcitly). This one is still correct. traits = any ( ... ) requirements = .. .. if $requirements eq $traits Should that be traits = all()? No. Because later we say (effectively): print True love\n if all(desiderata) eq any(traits) In other words we want *all* the desired characteristics to be matched by *some* trait. If the comparison was Call(...) eq all(...), then you're asking for every characteristic to be the same as every trait, which obviously can't happen. This is just a case where the logic of English phraseology has several implicit assumptions that computational logic can't just fudge over. (In other words: Can you write Apoc.Flexible now, please?) Well, I'd *like* to, but since that would involve giving up my first vacation in two years, and consequently getting divorced...no. ;-) Damian
Re: Perl6 Operator (REMAINING ISSUES)
On 2002-10-31 at 12:45:23, David Wheeler wrote: Plus, it turns out not to be at all hard to type on Mac OS X. ;-) Well, the angle quotes happen to fall within Latin-1, and so they're easier to get to. On Windows you can either set up special key mappings or just type ALT+171 for « and ALT+187 for », which gets wearisome after a while although you can get your fingers taught pretty quickly. Vim and emacs and XIM all take care of the UNIX case. Once you wander away from Latin-1 into the more general world of Unicode, you start running into trouble on the input side. On Windows you pretty much have to use the Character map accessory. Emacs and vim still work on UNIX, but I don't know of a XIM implementation for general Unicode. (Although if you log into your Unix machine using Kermit-95, it has a keystroke sequence for arbitrary Unicode input). Presumably, though, if Perl did have Unicode operators, it would also have an ASCII alternative, even if only something like \u00ab and \u00bb. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: UTF-8 operator possibilities
On Thursday, October 31, 2002, at 12:18 PM, Chip Salzenberg wrote: According to Michael Lazzaro: ?? ?? ?? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? Am I the only person who discovered Korean spam on p6-lang? Rats. I was trying to write mostly Greek spam. ;-) MikeL
Re: Vectorizing operators for Hashes
--- Larry Wall [EMAIL PROTECTED] wrote: On Thu, 31 Oct 2002, Markus Laire wrote: The really great thing about the French quotes is that they visually keep the user aware of the composition. «+=» is obviously a variety of +=, whereas ^+= is not obvious, though shorter. (Square brackets are even better at that, but have other problems.) I'm still unconvinced that square brackets won't work. But compared to Larry giving up «foo bar baz», «sont petits pommes de terre» __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
Re: plaintive whine about 'for' syntax
Damian Conway writes:
BTW, Both Larry and I do understand the appeal of interleaving
sources and iterators. We did consider it at some length back
in January, when we spent a week thrashing this syntax out.
Of course, I can't speak for Larry, but in the end I concluded
that interleaving iterator variables is a false win, since it
trades reduced syntactic complexity for increased semantic
complexity, but only really improves the readability of a
comparatively rare case.
Damian
but why ? I am just curious about details.
is it complicated for immediate component of for loop ( mentioned by
Larry Wall ) to cut-and-paste to reconstruct the original stream list
and block signature.
1) for a - $x ; b - $y { ... }
===
2) for a ; b - $x ; $y { ... }
at the price of - not being consistently closure declarator
*everywhere* and having a bit different meaning inside for ( and only
for , because all other topicalizers dont know about streams -- am I
right ?) . Which it is already not exactly , since immediate component
of for loop preprocess the closure signature to match the streams .
and besides, it seems to me that both 1) and 2) can coexist since for
loop can controll what happens between for and {...} . but maybe I
am wrong.
I am just curious .
arcadi .
Re: UTF-8 and Unicode FAQ, demos
--- Luke Palmer [EMAIL PROTECTED] wrote: And if you really want to drool at all the neat glyphs that the wonderful, magical world of math has given us, check out: http://www.unicode.org/charts/PDF/U2A00.pdf now *theres* some brackets! Ooh! Let's use 2AF7 and 2AF8 for qw! Frankly, I don't know HOW we've lived for so long without larger than and smaller than operators. =Austin __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
Re: [RFC] Perl6 HyperOperator List
Graham Barr wrote: On Thu, Oct 31, 2002 at 12:16:34PM +, [EMAIL PROTECTED] wrote: ... using backtick in vector operators ... A pair of backticks could be used if the vector-equals distinction is required: @a `+`= @b; @a `+=` @b; Thats ugly, IMO. Oh, I wasn't claiming that it's pretty. I think we're past being able to find something that's pretty. In general I find backticks fairly jarring on the eyes, but they have to be used for _something_ ... Smylers
Re: plaintive whine about 'for' syntax
[EMAIL PROTECTED] writes:
1) for @a - $x ; @b - $y { ... }
===
2) for @a ; @b - $x ; $y { ... }
You've got it! Semicolon naturally breaks things apart, not groups them
together!
--
Anything to do with HTML processing /usually/ involves a pact
with an evil supernatural being, I find.
-- Sean Burke
Primitive Boolean type?
While writing documentation: a trivial question on the boolean type, Cbit: my bit $light_switch; Q: Can bits/bools be undefined? Perl conventions would indicate yes. Does that mean that an array of bits: my bit bitfield; takes up, at minimum, two bits per, um, bit? Sorry if this question is as stupid as it looks. I'm just worried that maybe it isn't. MikeL
RE: [RFC] Perl6 Operator List, Take 5
--
On Thu, 31 Oct 2002 11:26:13
Brent Dax wrote:
I can honestly say at this point that I'd rather give up $iterator
than lose hyperops.
I was thinking the same thing not long ago. But now
that I think about it, is operator ever going to be
confused for $File_Handle? The vector operation cosy
up well to the concept of iteration anyway. Hell, if
were desperate (and I think we are) then why not just
double the brackets to [op] or [op]. Sure it's
ugly, but I prefer it to ^[op] any day of the week,
and it's not going to be ambiguous.
All that said, can anyone come up with a case to
confuse op with $File_Handle?
-Erik
And I consider relegating them to the
digraphs losing them, because I'm never going to be able to remember how
to type them, and neither will anybody else.
Let's look at this logically. Here's all the punctuation (non-\w)
characters on my keyboard and what they do in Perl 6:
TERMOPERATORDOUBLE
OPERATOR
` backticks nonenone
' string constantsnone** none
string constantsnonenone
# comment comment comment
$ scalar sigilnonenone
@ array sigil nonenone
% hash sigil modulo none
sub sigil junction and** logical and
! logical not none (?)none
^ complement junction xor** logical xor**
| nonejunction or** logical or
/ regex divide defined or (in
5.9)
* list flatten* multiplyexponent
- numify and negate subtraction
postdecrement
+ numify**addition
postincrement
~ stringify* concat**smart
match
= noneassignment
comparison
\ get reference nonenone
.. method call** method call** range constructor
? force to bool* none** trinary operator
, nonelist composer list composer
; nonestatement end statement end
(in parentheses) super-comma none
: nonesuper-comma package
separator, trinary operator
( )expression grouping sub parameters yuck
{ }hash composing hash subscripts yuck
block composing block composing yuck
[ ]array composing array subscriptsyuck
iterator syntax comparison ops shift-left, shift-right
UNUSED:5 8 9
Items marked with a * are new, ** are changed. There are twenty-two
'none's on that list, but none of them line up. (Isn't Perl great?!?)
';;' is available (it doesn't mean anything in either term or operator
context), but it's really ugly. The other possibilities I see there
have the same problem.
There are potentially some meaningless sequences, especially with
sigils, but those'll look quite cluttered. Actually, one of the few
good meaningless ones is ^[op] (with the square brackets). In term
context it would normally mean bitwise complement this array, and in
operator context it would mean add this array to an xor junction. If
we lose xor junctions (which I'm not necessarily advocating, mind you),
this sequence is pretty much open.
Damn. Larry, I don't envy you your job. :^)
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Get 25MB of email storage with Lycos Mail Plus!
Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
RE: [RFC] Perl6 Operator List, Take 5
Erik Steven Harrison writes: All that said, can anyone come up with a case to confuse op with $File_Handle? it seems that parser cannot confuse them because op is operator and parser expect operator, while $File_Handle is a term . but human can confuse . I personally also like op sintax. arcadi .
RE: [RFC] Perl6 Operator List, Take 5
Erik Steven Harrison:
# All that said, can anyone come up with a case to
# confuse op with $File_Handle?
If you assume infinite lookahead, it's fine, but if not...
something ...
Is that a call to
sub something() returns(IO::Handle)
or a hypered
sub operator:something($operand:)
?
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Re: plaintive whine about 'for' syntax
* Ed Peschko ([EMAIL PROTECTED]) [01 Nov 2002 07:19]:
[...]
for @a - $a_variable1 is rw, $a_variable2 is rw;
@b - $b_variable is rw;
@c - $c_variable is rw;
@d - $d_variable is rw;
@e - $e_variable1 is rw, $e_variable2 is rw;
{
}
is much, *much* clearer. IMO the current 'for' syntax suffers from
action at a distance, even if that distance is within the same line.
Related things aren't paired up nearly close enough to each other.
Give this man a +1. I do prefer to have associated things placed
with each other. And, as Simon pointed out, ';' is used to break
things apart, thus the syntax above makes somewhat more sense.
The best part is that I can easily comment out, delete, add part of
the expression without worrying that I'm deleting the wrong thing.
It may not be often that I will use the construct for multiple
iterators, but I can foreseeably use at least 2, and with the
added ease I can imagine using more =)
cheers,
--
Iain.
Re: [RFC] Perl6 Operator List, Take 5
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Date: Thu, 31 Oct 2002 14:45:16 -0800 From: Erik Steven Harrison [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] X-Sent-Mail: off Reply-To: [EMAIL PROTECTED] X-Sender-Ip: 152.18.50.63 Organization: Angelfire (http://email.angelfire.mailcity.lycos.com:80) Content-Language: en X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/ -- On Thu, 31 Oct 2002 11:26:13 Brent Dax wrote: I can honestly say at this point that I'd rather give up $iterator than lose hyperops. I was thinking the same thing not long ago. But now that I think about it, is operator ever going to be confused for $File_Handle? The vector operation cosy up well to the concept of iteration anyway. Hell, if were desperate (and I think we are) then why not just double the brackets to [op] or [op]. Sure it's ugly, but I prefer it to ^[op] any day of the week, and it's not going to be ambiguous. All that said, can anyone come up with a case to confuse op with $File_Handle? sub postfix:bar returns handle; $y = undef bar; That has two syntactically valid interpretations. It wouldn't take even that much to confuse the parser, though. Luke
Re: Primitive Boolean type?
On Thursday, October 31, 2002, at 02:43 PM, Michael Lazzaro wrote: Q: Can bits/bools be undefined? Perl conventions would indicate yes. IIRC, native data types, which are all lowercase (e.g., int, bit, long, etc.) cannot be undef. However, their class equivalents (e.g., Int, Bit, Long, etc) can be undef. HTH, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Perl6 Operator (REMAINING ISSUES)
On 31 Oct 2002 at 15:59, Mark J. Reed wrote: Once you wander away from Latin-1 into the more general world of Unicode, you start running into trouble on the input side. On Windows you pretty much have to use the Character map accessory. Emacs and vim still work on UNIX, but I don't know of a XIM implementation for general Unicode. (Although if you log into your Unix machine using Kermit-95, it has a keystroke sequence for arbitrary Unicode input). Emacs and vim also works on Windows, not just UNIX. -- Markus Laire 'malaire' [EMAIL PROTECTED]
Re: [RFC] Perl6 HyperOperator List
--- Luke Palmer [EMAIL PROTECTED] wrote: --- Damian Conway [EMAIL PROTECTED] wrote: Austin Hastings wrote: traits = any ( ... ) requirements = .. .. if $requirements eq $traits Should that be traits = all()? No. Because later we say (effectively): print True love\n if all(@desiderata) eq any(@traits) In other words we want *all* the desired characteristics to be matched by *some* trait. If the comparison was Call(...) eq all(...), then you're asking for every characteristic to be the same as every trait, which obviously can't happen. This is just a case where the logic of English phraseology has several implicit assumptions that computational logic can't just fudge over. Does this imply some sort of depth matching is required for these expressions? In this case, there's T = tall dark handsome D = (tall dark handsome) | (Australian) | (rich old) So when I say: all(@desiderata) # I hated that ^[!]() poem does that implicitly search down until it finds a singleton (Australian) or a conjunction (old rich)? And likewise does saying any(@traits) do some sort of implicit (de) construction looking for a singleton or a disjunction? Obviously, yes. So you're saying that the all() can't work at the a|b|c level, because that would be conjunctive disjunction. (Doc, tell me straight: how long do I have?) So the evaluation alternates through the possibilities, looking for a chance to apply all. I think you've got it mixed up: all() and any() don't work with junk, they _are_ junk. any($a) is just $a all($a) is just $a It doesn't do matching, not unless it collapses right there. So the only time it does matching is when it collapses, which has nothing to do with whether all() or any() are present. It has to do with whether a value is a junction. all(1, 2, 3) === 1 2 3 any(1 2 3) is still just 1 2 3 It matches: all(1, 2, 3) $x 1 2 3 $x because the junction is forced to collapse there. Understand? Maybe I just think differently. When I'm trying to actually DO the comparison, I'm forcing at least a partial collapse, no? I mean, maybe the traits are tall dark old handsome Australian so the three choices collapse to two, either of which would match. But regardless, when the actual == appears in the code, some determination needs to be made in order to figure out which way to go. So I'm trying to build rules in my brain for how these things are compatible-ized? And I'm trying to figure out when to specify which junction. =Austin __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
Re: Perl6 Operator List
Larry Wall writes:
sub postfix:! (num $x) { $x 2 ?? $x :: $x * ($x - 1) ! }
which could be fixed with the _:
sub postfix:! (num $x) { $x 2 ?? $x :: $x * ($x - 1) _! }
Weird, but it's all consistent with the distinction we're already
making on curlies, which gave a great increase in readability.
does it mean that *all* postfix operators have to be attached
without space to their operand or used with space eater modifyer
or
only those for which parser ( or we ) knows that they may be confused
with binary op or term ?
probably the same question for prefix operators .
aracdi
Re: [RFC] Perl6 HyperOperator List
Oops. About that op thing, I was wrong. Though there is a case that does it: sub bar(); sub postfix:bar($x) returns IO::Handle; $x = length bar; If it's possible to have a distinct sub and an operator with the same name. If not, I believe the distinction is precisely the same as that of named unary op with its argument optional. Except with infinite lookahead. Ummm, okay, it's not possible. Because of less than and friends, it's less possible than [op]. Luke
Question about for loop
for a - $x, $y { ... $x is topic ... }
for a ; b -
$x, $y ; $z { ... WHAT is topic ? ... }
what is topic in multi stream loop ?
arcadi
Re: [RFC] Perl6 HyperOperator List
Date: Thu, 31 Oct 2002 15:16:17 -0800 (PST)
From: Austin Hastings [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
--- Luke Palmer [EMAIL PROTECTED] wrote:
--- Damian Conway [EMAIL PROTECTED] wrote:
Austin Hastings wrote:
traits = any ( ... )
requirements = .. ..
if $requirements eq $traits
Should that be traits = all()?
No. Because later we say (effectively):
print True love\n
if all(@desiderata) eq any(@traits)
In other words we want *all* the desired characteristics to be
matched
by *some* trait. If the comparison was Call(...) eq all(...),
then
you're asking for every characteristic to be the same as every
trait,
which obviously can't happen.
This is just a case where the logic of English phraseology has
several implicit assumptions that computational logic can't just
fudge over.
Does this imply some sort of depth matching is required for these
expressions?
In this case, there's
T = tall dark handsome
D = (tall dark handsome) | (Australian) | (rich old)
So when I say:
all(@desiderata) # I hated that ^[!]() poem
does that implicitly search down until it finds a singleton
(Australian) or a conjunction (old rich)?
And likewise does saying
any(@traits)
do some sort of implicit (de) construction looking for a singleton
or a
disjunction?
Obviously, yes.
So you're saying that the all() can't work at the a|b|c level,
because
that would be conjunctive disjunction. (Doc, tell me straight: how
long do I have?) So the evaluation alternates through the
possibilities, looking for a chance to apply all.
I think you've got it mixed up: all() and any() don't work with junk,
they _are_ junk.
any($a) is just $a
all($a) is just $a
It doesn't do matching, not unless it collapses right there. So the
only time it does matching is when it collapses, which has nothing to
do with whether all() or any() are present. It has to do with
whether
a value is a junction.
all(1, 2, 3) === 1 2 3
any(1 2 3) is still just 1 2 3
It matches:
all(1, 2, 3) $x
1 2 3 $x
because the junction is forced to collapse there. Understand?
Maybe I just think differently. When I'm trying to actually DO the
comparison, I'm forcing at least a partial collapse, no?
I mean, maybe the traits are
tall dark old handsome Australian
so the three choices collapse to two, either of which would match.
But regardless, when the actual == appears in the code, some
determination needs to be made in order to figure out which way to go.
So I'm trying to build rules in my brain for how these things are
compatible-ized?
And I'm trying to figure out when to specify which junction.
sub hyperless ($left, $right) {
given {.isa Disjunction} {
when $left {
? grep { hyperless $_, $right } states($left)
when $right {
? grep { hyperless $left, $_ } states($right)
otherwise {
! grep - $a { grep - $b { $b $a } states($right) }
states ($left); }
}
}
Assuming states() on a nonjunction just returns its argument. This
code just gives true or false, not the junction of matching states
like it should.
I think what I have there is right, though I can't be sure.
Luke
Re: [RFC] Perl6 HyperOperator List
On Thu, Oct 31, 2002 at 12:16:34PM +, [EMAIL PROTECTED] wrote: ... using backtick in vector operators ... A pair of backticks could be used if the vector-equals distinction is required: @a `+`= @b; @a `+=` @b; Thats ugly, IMO. Oh, I wasn't claiming that it's pretty. I think we're past being able to find something that's pretty. In general I find backticks fairly jarring on the eyes, but they have to be used for _something_ ... I hear there's a vacancy for a qw(...) equivalent now . . . No, I'm not really suggesting this. But I am reminded by this whole endeavour of a certain text adventure. get underscore Taken. get bracket Taken. get guillemot Taken. get caret Taken. get backtick Oops! While you were reaching for the backtick, you drop the guillemot, and both tumble to the ground. (Whine: my Perl undergrad students are too young to remember or appreciate text adventures. At least some of you oldsters here will understand.) -- Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED] Is it, err, Mildred? O.K., no. How 'bout - Diana? Rachel? Ariel, her name is Ariel. - _The Little Mermaid_
RE: Perl6 Operator (REMAINING ISSUES)
Markus Laire:
# Emacs and vim also works on Windows, not just UNIX.
So does DOS 'edit'. That doesn't mean Windows users use it. Windows
users want tools that look and act like Windows tools--if they didn't,
they'd be using another OS. Neither GNU emacs nor xemacs fits the bill,
and I doubt vim does either.
I'm an aberration--I use Windows, but I have a Cygwin toolkit installed
and use it regularly. Still, I use VS.Net (with Visual Perl) for my
editing, not a Unix editor. When telnetting, I use emacs, so I
installed XEmacs, used it for a while, and decided I didn't like it for
my local work. It had some really cool features--I was *very*
pleasantly surprised at how nicely it meshed with CVS--but it just
didn't fit my Windows-shaped brain.
You can bet that if I, a Perl core hacker who keeps two copies of
cmd.exe open at all times with c:\cygwin\bin in his path, am not going
to use XEmacs, your average Joe who downloads ActiveState Perl 6 to test
his hit-counter script won't use emacs or vim either.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Re: [RFC] Perl6 HyperOperator List
get guillemot Taken. Extra credit for those of you who remembered that that's a bird, not a punctuation mark. -- Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED] Is it, err, Mildred? O.K., no. How 'bout - Diana? Rachel? Ariel, her name is Ariel. - _The Little Mermaid_
Re: [RFC] Perl6 HyperOperator List
On Thursday, October 31, 2002, at 03:47 PM, Deborah Ariel Pickett wrote: (Whine: my Perl undergrad students are too young to remember or appreciate text adventures. At least some of you oldsters here will understand.) Hey! We're not old, we're just version 1.0! Can we have a grue operator? It would be invisible, and eat everything it operated on. Oh, wait... I think Damian already has that module. MikeL
Re: Perl6 Operator (REMAINING ISSUES)
actually , ones we decide that ^ *is necessary for vectorization , we
can allow other brackets , optional brackets ( where unambiguous ) ,
and spaces inside the brackets :
a ^+= b
a ^[+]= b
a ^(+)= b
a ^( + )= b
a ^{ + }= b
a ^{+}= b
a ^[ + ]= b
right, and what does this all mean? I have yet to see a good meaning for
array ^[+]= array2 ...
Perhaps, having just ^ as a vector op, and using ^[op] to disambiguate (or
as an equivalent) is the way to go.
Ed
Re: plaintive whine about 'for' syntax
On 10/31/02 5:33 PM, [EMAIL PROTECTED] wrote:
Damian Conway writes:
BTW, Both Larry and I do understand the appeal of interleaving
sources and iterators. We did consider it at some length back
in January, when we spent a week thrashing this syntax out.
Of course, I can't speak for Larry, but in the end I concluded
that interleaving iterator variables is a false win, since it
trades reduced syntactic complexity for increased semantic
complexity, but only really improves the readability of a
comparatively rare case.
but why ? I am just curious about details.
Yeah, I'd like to hear those details too, because the alternate syntax:
1) for @a - $x ; @b - $y { ... }
sure looks a lot more attractive and sensible to me, and I agree with all
the arguments in favor of it so far. In particular:
* No look here, then look there connection between (possibly) widely
separated items.
* Simple to add or remove/comment-out individual stream/item(s) pairs
without having to count what are essentially positional parameters to make
sure you haven't mis-mapped anything in the process.
* More familiar use of the semicolon (IMO)
-John
Re: [RFC] Perl6 HyperOperator List
On Fri, Nov 01, 2002 at 07:54:01AM +1100, Damian Conway wrote:
Austin Hastings wrote:
traits = any ( ... )
requirements = .. ..
if $requirements eq $traits
Should that be traits = all()?
No. Because later we say (effectively):
print True love\n
if all(desiderata) eq any(traits)
In other words we want *all* the desired characteristics to be matched
by *some* trait. If the comparison was Call(...) eq all(...), then
you're asking for every characteristic to be the same as every trait,
which obviously can't happen.
This is just a case where the logic of English phraseology has
several implicit assumptions that computational logic can't just
fudge over.
I don't understand this either, but my quibble is where did the all in
the all(desiderata) come from? Lets see if I've got this straight
a b is equivalent to all(a, b)
x | y is equivalent to any(x, y)
Yes?
so:
all(a, b) eq any(a, b, c)
should be true because all() of a and b are in the any() list. Yes?
If I'm right about that, I would expect
(a b) | (c d) eq any(a, e, g)
to be false because it should try ANY of the two junks (a b) or
(c d) the first fails because there is no b and the second fails
because there is no c and no d. I would also expect
(a b) | (c d) | g eq any(a, e, g)
to be true because any() of the terms (g in this case) on the left is
fully satisfied by terms on the right. In the original example the
desiderata is an | junk at the topmost level. I don't see why it
suddenly gets all() wrapped around it. Wouldn't that just be
all[ any all(), all(), all() ]
which is the same as
any all(), all(), all()
I'm not sure I'm explaining this very well, let me try with the example
that's giving me bother.
$requirements = tall dark handsome
| old rich
| Australian;
for - $candidate {
my $traits = any( split /ws/, $candidate );
print True love: $candidate\n
if $requirements eq $traits;
}
Lets say that $candidate = tall dark rich Australian, traits then
becomes any(tall, dark, rich, Australian). So, does
$requirements eq $traits? To me that expands to:
(
(
(tall eq tall) or \
(tall eq dark) or True because tall eq tall
(tall eq rich) or
(tall eq Australian)/
) AND (
(dark eq tall) or \
(dark eq dark) or True because dark eq dark
(dark eq rich) or
(dark eq Australian)/
) AND (
(handsome eq tall) or \
(handsome eq dark) or False no matches
(handsome eq rich) or
(handsome eq Australian)/
)
) ***OR*** (
(
(old eq tall)or \
(old eq dark)or False no matches
(old eq rich)or
(old eq Australian) /
) AND (
(rich eq tall) or \
(rich eq dark) or True because rich eq rich
(rich eq rich) or
(rich eq Australian)/
)
) ***OR*** (
(Australian eq tall) or \
(Australian eq dark) or True because Australian eq Australian
(Australian eq rich) or
(Australian eq Australian) /
)
Junk 1: tall dark handsome
Junk 2: old rich
Junk 3: Australian;
Junk 1 fails because the candidate is not handsome. Junk 2 fails because
the candidate is not old. Junk 3 succeeds because the candidate is
Australian.
This means that the candidate matches overall because junks 1, 2 and 3
are related by | which is any. I don't see how or why you would wrap an
all() around that. There is all()ness going on, but it's represented in
the above by the ands which are in turn grouped with any (the ors).
Why isn't this example
print True love\n
if any(desiderata) eq any(traits)
Does whether it's any() or all() not depend on what the top level
operator in the junction is? Am I missing something?
andrew
--
Gemini: (May 21 - June 21)
You will be the first one put up against the wall in next week's bloody
revolution in skin care.
Re: [RFC] Perl6 HyperOperator List
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Date: Fri, 1 Nov 2002 03:08:37 +
From: Andrew Wilson [EMAIL PROTECTED]
Mail-Followup-To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Content-Disposition: inline
X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
On Fri, Nov 01, 2002 at 07:54:01AM +1100, Damian Conway wrote:
Austin Hastings wrote:
traits = any ( ... )
requirements = .. ..
if $requirements eq $traits
Should that be traits = all()?
No. Because later we say (effectively):
print True love\n
if all(@desiderata) eq any(@traits)
In other words we want *all* the desired characteristics to be matched
by *some* trait. If the comparison was Call(...) eq all(...), then
you're asking for every characteristic to be the same as every trait,
which obviously can't happen.
This is just a case where the logic of English phraseology has
several implicit assumptions that computational logic can't just
fudge over.
I don't understand this either, but my quibble is where did the all in
the all(@desiderata) come from?
First, I'd like to say that your explanation was immaculate. You
understand junctions perfectly, from what I can tell.
I think Damian was ignoring the the top level any() in order to make
the explanation clearer (or forgot about it ;). Consider it as though
@desiderata contained the (all) states of only one of the (any) states
in his $requirements. I think that's what (effectively) meant.
Indeed, worry not. It was just a bit of an oversimplification.
Luke
Lets see if I've got this straight
a b is equivalent to all(a, b)
x | y is equivalent to any(x, y)
Yes?
so:
all(a, b) eq any(a, b, c)
should be true because all() of a and b are in the any() list. Yes?
If I'm right about that, I would expect
(a b) | (c d) eq any(a, e, g)
to be false because it should try ANY of the two junks (a b) or
(c d) the first fails because there is no b and the second fails
because there is no c and no d. I would also expect
(a b) | (c d) | g eq any(a, e, g)
to be true because any() of the terms (g in this case) on the left is
fully satisfied by terms on the right. In the original example the
@desiderata is an | junk at the topmost level. I don't see why it
suddenly gets all() wrapped around it. Wouldn't that just be
all[ any all(), all(), all() ]
which is the same as
any all(), all(), all()
I'm not sure I'm explaining this very well, let me try with the example
that's giving me bother.
$requirements = tall dark handsome
| old rich
| Australian;
for - $candidate {
my $traits = any( split /ws/, $candidate );
print True love: $candidate\n
if $requirements eq $traits;
}
Lets say that $candidate = tall dark rich Australian, traits then
becomes any(tall, dark, rich, Australian). So, does
$requirements eq $traits? To me that expands to:
(
(
(tall eq tall) or \
(tall eq dark) or True because tall eq tall
(tall eq rich) or
(tall eq Australian)/
) AND (
(dark eq tall) or \
(dark eq dark) or True because dark eq dark
(dark eq rich) or
(dark eq Australian)/
) AND (
(handsome eq tall) or \
(handsome eq dark) or False no matches
(handsome eq rich) or
(handsome eq Australian)/
)
) ***OR*** (
(
(old eq tall)or \
(old eq dark)or False no matches
(old eq rich)or
(old eq Australian) /
) AND (
(rich eq tall) or \
(rich eq dark) or True because rich eq rich
(rich eq rich) or
(rich eq Australian)/
)
) ***OR*** (
(Australian eq tall) or \
(Australian eq dark) or True because Australian eq Australian
(Australian eq rich) or
(Australian eq Australian) /
)
Junk 1: tall dark handsome
Junk 2: old rich
Junk 3: Australian;
Junk 1 fails because the candidate is not handsome. Junk 2 fails because
the candidate is not old. Junk 3 succeeds because the candidate is
Australian.
This means that the candidate matches overall because junks 1, 2 and 3
are related by | which is any. I don't see how or why you would wrap an
all() around that. There is all()ness going on, but it's represented in
the above by the ands which are in turn grouped with any (the ors).
Why isn't this example
print True love\n
if any(@desiderata) eq any(@traits)
Does whether it's any() or all() not depend on what the top level
operator in the junction is? Am I missing something?
andrew
--
Gemini: (May 21 - June 21)
You will be the first one put up against the wall in next week's bloody
revolution in skin care.
RE: [RFC] Perl6 Operator List, Take 5
On Fri, 1 Nov 2002 [EMAIL PROTECTED] wrote: : Erik Steven Harrison writes: : : : All that said, can anyone come up with a case to : confuse op with $File_Handle? : : : : it seems that parser cannot confuse them because op is operator and : parser expect operator, while $File_Handle is a term . All unary operators show up when a term is expected, not an operator. Larry
Re: Primitive Boolean type?
On Thu, 31 Oct 2002, Michael Lazzaro wrote: : While writing documentation: a trivial question on the boolean type, : Cbit: Please don't think of Cbit as a boolean type. There is no boolean type in Perl, only a boolean context. Or looking at it from the other direction, *every* type is a boolean type. : Does that mean that an array of bits: : : my bit bitfield; : : takes up, at minimum, two bits per, um, bit? Just one per. Larry
Re: [RFC] Perl6 Operator List, Take 5
On Wed, 30 Oct 2002, Larry Wall wrote: If no one saw them then it could well be a problem on my end. I'm trying to use a mailer (pine) that doesn't know about UTF-8 in a «+» b I'm using Pine 4.33 on FreeBSD 4.3, and I see these fine. --Dks
Re: [RFC] Perl6 HyperOperator List
On Fri, 1 Nov 2002, Damian Conway wrote: : Austin Hastings wrote: : : In the C that I learned, the ^| ops were bitwise. : : Likewise, the || ops were lazy booleans. : : So what's a single-letter boolean act like? Is it lazy? Does it retain : its bitwise-ness but (since boolean) force evaluation for 1 or 0 first? : I just don't understand what the implied behavior is, since the : reference is outside my experience. : : Since they're producing a boolean result, both C? and C?| could be : implemented lazily. However, I suspect they mightn't be, just to keep : them consistent (in their evaluation of operands) with the other bitwise : ops. What you're saying is correct, except that I don't think we should be confusing lazy with short-circuit. A lazy operator wouldn't evaluate *either* side until it jolly well had to. If you say () = 1..Inf; it shouldn't even try to produce a 1. I don't much care whether they short-circuit or not. I could argue it either way. I think it'd be okay if they short-circuit. Anybody who uses an operator like ? expecting it to force a side effect on the second expression is nuts. And there's something (though not much) to be said for having an exact equivalent for C's operator. Larry
Re: [RFC] Perl6 Operator List, Take 5
On Thu, 31 Oct 2002, Dave Storrs wrote: : On Wed, 30 Oct 2002, Larry Wall wrote: : : If no one saw them then it could well be a problem on my end. : I'm trying to use a mailer (pine) that doesn't know about UTF-8 in : : a «+» b : : I'm using Pine 4.33 on FreeBSD 4.3, and I see these fine. I sent those as Latin-1, not UTF-8. Larry
Re: [RFC] Perl6 Operator List, Take 5
* Larry Wall ([EMAIL PROTECTED]) [31 Oct 2002 08:22]: [...] This is currently running in a window that does Latin-1 rather than UTF-8. Do these French quotes come through? @a «+» @b The window may say Latin-1, but the mail header said UTF-8. As it happens, I couldn't see them until I piped the message through less. That said, I've probably got a misconfiguration somewhere. I usually have trouble with top-bit set chars, and ms codepagisms. cheers, -- Iain.
Re: [RFC] Perl6 Operator List, Take 5
On Fri, 1 Nov 2002, Iain 'Spoon' Truskett wrote: : This is currently running in a window that does Latin-1 rather than : UTF-8. Do these French quotes come through? : : a «+» b : : The window may say Latin-1, but the mail header said UTF-8. : : As it happens, I couldn't see them until I piped the message through : less. That said, I've probably got a misconfiguration somewhere. : I usually have trouble with top-bit set chars, and ms codepagisms. I was misconfigured here. My pine was marking it as UTF-8 even though the window was Latin-1. So you ought to be able to see this: a «*» b. I'm definitely going to look into mutt though...gotta have Unicode email. Larry
Re: [RFC] Perl6 Operator List, Take 5
* Larry Wall ([EMAIL PROTECTED]) [01 Nov 2002 15:59]: [...] I was misconfigured here. My pine was marking it as UTF-8 even though the window was Latin-1. So you ought to be able to see this: @a «*» @b. That appeared perfectly. I'm definitely going to look into mutt though...gotta have Unicode email. So I'm told =) Me? I'd be happy if more mailers supported the Mail-Followup-To header. I'm not too concerned about unicode since my xterm doesn't support it anyway =) Obviously, I'll look into it one of these days. Soon after Perl 6 is released, I imagine. cheers, -- Iain.
Re: [RFC] Perl6 HyperOperator List
Larry wrote: I don't much care whether they short-circuit or not. I could argue it either way. I think it'd be okay if they short-circuit. Anybody who uses an operator like ? expecting it to force a side effect on the second expression is nuts. And there's something (though not much) to be said for having an exact equivalent for C's operator. Well, would you mind saying it then? Because there's certainly something to be said against having an exact equivalent for C's operator. Luke
