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 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 C 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 | (5&10)
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 //, $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/
Re: operator:alt-0171 and operator:alt-0187
--- Iain 'Spoon' Truskett <[EMAIL PROTECTED]> wrote: > * 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. Somewhere, deep in the bowels of some Digital Equipment .. err .. Compaq .. err .. HP building, there's a guy getting major wood because ALL THAT WORK that he chipped in so many years ago on the 'X' keyboard input routines is about to be justified. FINALLY, someone in the US is going to actually use the [compose] key. Woo-hoo! (Except for the PCLinux guys, who didn't get a "Compose" key. But maybe they can liquid-paper over the "Windows" key and write in "Compose" and «voila»!) [Note smooth, casual insertion of guillemets into daily conversation ...] How much of the "length of time it takes to type the darn thing" is because right now we don't use those symbols? Most PC keyboards make the tilde (~) character a PITA by putting it out at top-left or top-right (or, worse, just below backspace). The reason -- most people aren't writing perl or awk code, and so aren't using that symbol. This is, IMO, one of those cases where if we suck it up and adopt the operator, and if the operator's as useful as it seems, then it will take about two weeks before this problem is history. Everyone will know how to generate the symbol, with the same encoding, on however many keyboards. And Tim O'Reilly will be happy because for once newbies will actually READ the preface chapter of the perl books, in which conventions and fonts and such are explained -- that's where the first of the masonic secrets (Perlish rite) will be illuminated. =Austin PS: MSIE doesn't like alt-. I'm still doing copy and paste. But I have CONFIDENCE... __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
Re: [RFC] Perl6 Hyperoperator backtick
--- [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: > > * 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. This almost makes more sense than the ^[] stuff. But see below. > A pair of backticks could be used if the vector-equals distinction is > required: > > @a `+`= @b; > @a `+=` @b; Now it does make more sense. Use them as quotes, please, since that's the understood usage (and becase syntax highlighters know how to do this). I don't even mind if they keep the "dual use" of run-gather and vectorize. (They probably can't, since prefix ops would look like run-gathers.) @a = @b `+` @c; "let @a be the result of running PLUS with inputs @b and @c" Yeah! =Austin __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
Re: Vectorizing operators for Hashes
--- [EMAIL PROTECTED] wrote:
> I agree. But I think that we can get away here with just hash
> properties , just like hash behaviour in 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?
%a rules?: %c == ("abacus" => 4)
%b rules?: %c == ("apple" => 1, "abacus" => 4, "banana" => 3)
strict_keys filters result?: %c == ("apple" => 1, "abacus" => 4)
=Austin
__
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
Re: [RFC] Perl6 Operator List, Take 5
On Wednesday, October 30, 2002, at 01:52 PM, Michael Lazzaro wrote: Applications/Utilities/"Key Caps" (Again, OSX) which shows you where they all are. The «» quotes, for example, are option-\ and shift-option-\ Oh, well, I guess those aren't *too* far out of the way... David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Vectorizing operators for Hashes
> > union: > > intersection : > > How would this work for hashes with differing properties? > > %a ^is strict_keys; > %b ^is no_strict_keys; > > What would happen? 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
Re: [RFC] Perl6 Operator List, Take 5
On Thu, 2002-10-31 at 04:02, Iain 'Spoon' Truskett wrote: > * 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. I agree considering, this isn't APL and the problems people have had mailing examples (let alone creating them!). I've got to admit all of these operators are scaring me. Seems alot like Brooks' second-system effect. Brian Wheeler [EMAIL PROTECTED]
Re: worth adding collections to the core language?
On Thu, 31 Oct 2002, Austin Hastings wrote: : Damian Conway admits: "Everything in Perl6 is 'Junk'" : : Who can't see *this* coming on slashdot? :-) Cool. Perl 6 "junk" gives new meaning to "Pathologically Eclectic Rubbish". Larry
Re: [RFC] Perl6 Operator List, Take 5
On 31 Oct 2002, brian wheeler wrote: : I agree considering, this isn't APL and the problems people have had : mailing examples (let alone creating them!). Nevertheless, it has already been decreed that Perl 6 programs are written in Unicode. That's not gonna change... : I've got to admit all of these operators are scaring me. Seems alot : like Brooks' second-system effect. But that's our slogan: Perl 6 is second-system effect done right. :-) Larry
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. Larry
Re: [RFC] Perl6 HyperOperator List
On Thu, 31 Oct 2002, Graham Barr wrote: : On Thu, Oct 31, 2002 at 12:16:34PM +, [EMAIL PROTECTED] wrote: : > 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 ? It would work for binary ops, but unfortunately, nothing that looks like a term can work for unary ops. (Also parens are already used as a postfix operator that means call the preceding function ref.) Larry
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 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 { }
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:^[] 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: Perl6 Operator (REMAINING ISSUES)
Michael Lazarro wrote: > 1) Need a definite syntax for hypers >^[op] and <> > have been most seriously proposed -- something that keeps a > bracketed syntax, but solves ambiguity issues. hm. What was wrong with just '^' again? Reading the threads, it seems to have gotten lost in the shuffle. Ed
Re: Vectorizing operators for Hashes
> temp sub infix:^[] is force_hash_to_intersect ; Right. A property used as you suggest is effectively an adverb applied at op definition rather than use. > maybe somebody will wont ( 1,2 ) ^[op] ( 1, 2, 3 ) to return array of > length 3 ; Right. It's quite plausible that one would want to be able to control this at op use, rather than definition. -- ralph
Re: Perl6 Operator (REMAINING ISSUES)
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm > Date: Thu, 31 Oct 2002 11:13:28 -0800 > From: Ed Peschko <[EMAIL PROTECTED]> > Content-Disposition: inline > X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/ > > Michael Lazarro wrote: > > > 1) Need a definite syntax for hypers > > ^[op] and <> > > have been most seriously proposed -- something that keeps a > > bracketed syntax, but solves ambiguity issues. > > hm. What was wrong with just '^' again? Reading the threads, it seems to have > gotten lost in the shuffle. Xor needs it. I'd place hypers in front of xor on my importance list, but that's just me. > Ed >
Re: Perl6 Operator (REMAINING ISSUES)
> > 1) Need a definite syntax for hypers > > ^[op] and <> > > have been most seriously proposed -- something that keeps a > > bracketed syntax, but solves ambiguity issues. > > hm. What was wrong with just '^' again? Right. I didn't have a problem with ^ in the first place. But... A ^ prefix visually interferes a lot more with the op being hypered. I didn't understand that until I first saw use of square brackets (interestingly, use of angle brackets didn't grab my attention, though that may have been due to other factors). Personally, I liked the use of single backtick someone suggested. I suspect that this is because it seemed to be just as good as square brackets at getting out of the way visually (vastly better than ^); was enough to catch my attention to suggest something special was going on; was just one, unshifted, character (or two, if used for a `op`= variant); and seemed to be the least disruptive (it left ^ for other duties and just meant one needed to eliminate `` for a syscall; hmm, maybe that's not acceptable...) -- ralph
Re: Perl6 Operator (REMAINING ISSUES)
On Thu, Oct 31, 2002 at 01:36:20PM -0600, Me wrote: > > > 1) Need a definite syntax for hypers > > > ^[op] and <> > > > have been most seriously proposed -- something that keeps a > > > bracketed syntax, but solves ambiguity issues. > > > > hm. What was wrong with just '^' again? > > Right. I didn't have a problem with ^ in the first place. > > But... > > A ^ prefix visually interferes a lot more with the op being > hypered. I didn't understand that until I first saw use of > square brackets (interestingly, use of angle brackets > didn't grab my attention, though that may have been > due to other factors). I know it clutters up things a bit, that's my very argument; that ^[ ] clutters up things even *more*. especially, with use of arrays: @array[1,2,3] ^[+=] @array[4,5,6]; bleah. @array[1,2,3] ^+= @array[4,5,6]; Not much of a improvement, but its palpable. There's some comfort knowing that '^' is being used as a sigil for an operator, and that all you need is one keystroke in order to use it. I guess it depends on how much hyperoperators are meant to be used. The more they are, the shorter the operator should be. Oh by the way. IMO 'vector' operators should be the proper term. Looking at the above sentence, the term 'hyperoperator' should be quietly euthanized. (or quickly shot.) Ed
UTF-8 operator possibilities
Here is more to think about. No freaking out, this is just for
mulling...
If we, for the moment, assume the use of «op» for hypers, that
obviously raises the _possibility_ of using some other Unicode/UTF-8
characters for other "very special" tasks. I'm not actually advocating
most of these (no APL, please) but note that some chars might have
distinct possibilities, especially with superpositions:
-- a wide variety of unary and binary ops, some obscure, some obvious:
± × ÷ ≤ ≥ ≠ ≅ ≈ ≡
∩ ∪ ⊂ ⊃ ⊆ ⊇ ∈ ⊄ ∉
⇒ ⇔
∧ ∨ ∴ ∀ ∃ ∠ ⊥ ∝ √ ∫ ∇ ∅ ⊕ ⊗ ∍
† ‡ ˇ ∑ ∏ ∆ Ω ¡ ¿ ¬ ∂ • º ©
(including things like:)
∑@array - summation
∏@array - product
±$x - { any(+$^x,-$^x) }
$v ∈ @array; # element of
-- possible alternate separators in place of ';', where ';'
would result in doing a very, very wrong thing:
for (@x • @y) -> ($x • $y) { ... } - (bullet)
for (@x ∫ @y) -> ($x ∫ $y) { ... }
for (@x ‡ @y) -> ($x ‡ $y) { ... }
for (@x † @y) -> ($x † $y) { ... }
for (@x ⊥ @y) -> ($x ⊥ $y) { ... }
-- a global var like "epsilon" or "mu" that sets a +-bound
for "like" comparisions between floating point nums,
to locally allow comparisions with a settable degree
of accuracy:
{
temp µ = 0.5;
( 10/3 == (1/3) * 10 ); # FALSE, floating point issues
( 10/3 ~~ (1/3) * 10 ); # TRUE, is within µ
}
(OK, we could name that $EPSILON, or anything else in ASCII.
but you gotta admit it looks really slick. If you can see it.)
;-)
-- *plenty* more wierd bracketing and quotelikes, if you dare:
«thing»
‡thing‡
†thing†
∫thing∫
§thing§
¶thing¶
≤thing≥
-- and, of course, terms (e.g. "duh" synonyms)
∞ - Inf
π - Pi
ø - null set
Just something to think about -- No reason to go all APLish, but if we
find we need another few chars for some obscure but incredibly useful
operations, there _are_ possibilities. Depends primarily on which
characters are most widely recognized on the various platforms, and how
confident we are or aren't that we should say "deal with it" to people
with non-Unicode-capable editors.
And note that using special chars for special things may increase
readability significantly, since we don't have to worry as much about
similar-looking punctuational strings doing completely different
things, which is already a bit of a problem.
Oh, and here's another tip for you OSX types:
From within Mail, choose Format -> Font -> Show Fonts.
From the "Extras" menu, choose "Show Characters"
you are presented with the grouped listings for every character
that exists on your computer, along with Unicode identifiers. Double
click them to insert them into your email. :-) (Note that you can
also use it in BBEdit.)
MikeL
Re: Perl6 Operator (REMAINING ISSUES)
> > A ^ prefix visually interferes a lot more > > I know it clutters up things a bit, that's my very argument; that > ^[ ] clutters up things even *more*. especially, with use of arrays: > > @array[1,2,3] ^[+=] @array[4,5,6]; > > bleah. > > @array[1,2,3] ^+= @array[4,5,6]; > > Not much of a improvement, but its palpable. Maybe. I slightly prefer the first line right now. But it's close, and I think I've gotten too used to both notations to know what I'd think if I saw one or other for the first time, and I don't know what I'd think after a month of use of one or other. As I said, it's close. This will defintely be my last email on the topic... There's a couple other reasons to go for ^[op]. One is that [] is more obviously indicative to a newbie that there is some array aspect to how the op applies than ^ (or backtick) would be. Another is that bracketing works better to indicate the difference between the two ...= variants that might be useful: @a ^[+=] @b @a ^[+]= @b # vectorize the +, not the = @a ^+= @b @a ^+^= @b # vectorize the +, not the = ?!? > '^' is being used as a sigil for an operator, and that all > you need is one keystroke in order to use it. On my keyboard it's two (shift and the 6 key). > Oh by the way. IMO 'vector' operators should be the > proper term. Oops. Yes. -- ralph
Re: plaintive whine about 'for' syntax
Larry Wall writes:
> I think decent formatting would make it clearer:
>
> for@a; @b
> -> $x is rw; y {
>$x = $y[5];
> }
But this isn't very scalable:
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
{
}
wheras:
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.
And I'd curse it if I was writing 'for' expressions as complicated as the
second one. Which I WILL do, especially when writing code generators.
Ed
Re: UTF-8 operator possibilities
According to Michael Lazzaro: >?? ?? ?? ??? ??? ??? ??? ??? ??? >??? ??? ??? ??? ??? ??? ??? ??? ??? >??? ??? >??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? Am I the only person who discovered Korean spam on p6-lang? -- Chip Salzenberg - a.k.a. -<[EMAIL PROTECTED]> "It furthers one to have somewhere to go."
Re: Perl6 Operator (REMAINING ISSUES)
On Thursday, October 31, 2002, at 11:36 AM, Me wrote: A ^ prefix visually interferes a lot more with the op being hypered. I didn't understand that until I first saw use of square brackets (interestingly, use of angle brackets didn't grab my attention, though that may have been due to other factors). If we're talking about operators being "hypered," then I think that «op» makes a lot of sense. It reminds me of Perl 5's "spaceship" operator, <=>, and I think of a spaceship taking the operator and jumping into hyperspace. What could be a better analogy than that, quantumly speaking? Plus, it turns out not to be at all hard to type on Mac OS X. ;-) Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: plaintive whine about 'for' syntax
Ed Peschko wrote:
Larry Wall writes:
I think decent formatting would make it clearer:
for@a; @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 C, 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: Perl6 Operator (REMAINING ISSUES)
> Maybe. I slightly prefer the first line right now. > But it's close, and I think I've gotten too used to > both notations to know what I'd think if I saw one > or other for the first time, and I don't know what > I'd think after a month of use of one or other. As > I said, it's close. This will defintely be my last > email on the topic... likewise.. > > There's a couple other reasons to go for ^[op]. > > One is that [] is more obviously indicative to a > newbie that there is some array aspect to how > the op applies than ^ (or backtick) would be. I think that this advantage pales to the cost of having to type three characters every single time someone has to use a vector operation. Its just as easy for a newbie to say 'aha! ^ means array!'. > Another is that bracketing works better to indicate > the difference between the two ...= variants that > might be useful: > > @a ^[+=] @b > @a ^[+]= @b # vectorize the +, not the = > > @a ^+= @b > @a ^+^= @b # vectorize the +, not the = ?!? > Ok, I can sort of see this, but what the #%@@$ do both of these things mean? I can see @a ^+= @b meaining $a[0] += $b[0] $a[0] += $b[1] $a[0] += $b[2] $a[0] += $b[3]...etc but @a ^[+]= @b?? I swear, this whole vector operator thing would be a lot easier to understand if everything was vectored or not, ie: @a = @b ^+ @c; was a syntax error or was optimised to: @a ^= @b ^+ @c; In that case, ^[+]= doesn't really make sense. Ed
Re: Perl6 Operator (REMAINING ISSUES)
Me writes:
> > > A ^ prefix visually interferes a lot more
> >
> > I know it clutters up things a bit, that's my very argument; that
> > ^[ ] clutters up things even *more*. especially, with use of arrays:
> >
> > @array[1,2,3] ^[+=] @array[4,5,6];
> >
> > bleah.
> >
> > @array[1,2,3] ^+= @array[4,5,6];
> >
> > Not much of a improvement, but its palpable.
>
> Maybe. I slightly prefer the first line right now.
> But it's close, and I think I've gotten too used to
> both notations to know what I'd think if I saw one
> or other for the first time, and I don't know what
> I'd think after a month of use of one or other. As
> I said, it's close. This will defintely be my last
> email on the topic...
>
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
all that can *coexist* !
> There's a couple other reasons to go for ^[op].
>
> One is that [] is more obviously indicative to a
> newbie that there is some array aspect to how
> the op applies than ^ (or backtick) would be.
>
> Another is that bracketing works better to indicate
> the difference between the two ...= variants that
> might be useful:
>
> @a ^[+=] @b
> @a ^[+]= @b # vectorize the +, not the =
>
> @a ^+= @b
> @a ^+^= @b # vectorize the +, not the = ?!?
>
>
> > '^' is being used as a sigil for an operator, and that all
> > you need is one keystroke in order to use it.
>
> On my keyboard it's two (shift and the 6 key).
>
>
> > Oh by the way. IMO 'vector' operators should be the
> > proper term.
>
> Oops. Yes.
>
> --
> ralph
>
>
Re: [RFC] Perl6 HyperOperator List
--- 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 C, 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". But on the other side, not all of the traits have to be "matched." It won't be fatal if the traits are tall & dark & handsome & socialist old & rich & fat Australian & impotent so long as some subset (ANY?) of the traits completely match ALL the desired bits. So I can't use "all(@traits)" because that would OVERSPECIFY. But I don't feel right using "any(@traits)" because that feels like either saying "traits[x] == all-these-things" which is wrong, or "traits was a list, like desiderata, which contains one of these" which is wrong, too. It's right to say "there is SOME trait in @traits that matches each @desiderata" But of course, SOME is "choose one", and that means "any". (BTW: Will there be an alternate build of p6 that does NOT depend on the axiom of choice?) Damian, your reward for this whole flexible values mess is to spend the rest of your life being retained by large companies to explain this stuff to blockheads like me. Welcome to hell. =Austin __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
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, C: 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 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 []. 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 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 HyperOperator List
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm > Date: Thu, 31 Oct 2002 14:07:34 -0800 (PST) > From: Austin Hastings <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/ > > > --- 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 C, 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? Luke > But on the other side, not all of the traits have to be "matched." It > won't be fatal if the traits are > > tall & dark & handsome & socialist > old & rich & fat > Australian & impotent > > so long as some subset (ANY?) of the traits completely match ALL the > desired bits. > > > So I can't use "all(@traits)" because that would OVERSPECIFY. > > But I don't feel right using "any(@traits)" because that feels like > either saying > > "traits[x] == all-these-things" > > which is wrong, or > > "traits was a list, like desiderata, which contains one of these" > > which is wrong, too. It's right to say > > "there is SOME trait in @traits that matches each @desiderata" > > But of course, SOME is "choose one", and that means "any". > > (BTW: Will there be an alternate build of p6 that does NOT depend on > the axiom of choice?) > > Damian, your reward for this whole flexible values mess is to spend the > rest of your life being retained by large companies to explain this > stuff to blockheads like me. Welcome to hell. > > =Austin > > > > __ > Do you Yahoo!? > HotJobs - Search new jobs daily now > http://hotjobs.yahoo.com/ >
RE: [RFC] Perl6 Operator List, Take 5
Erik Steven Harrison writes: > > > All that said, can anyone come up with a case to > confuse with <$File_Handle>? > > it seems that parser cannot confuse them because is operator and parser expect operator, while <$File_Handle> is a term . but human can confuse . I personally also like sintax. arcadi .
RE: [RFC] Perl6 Operator List, Take 5
Erik Steven Harrison:
# All that said, can anyone come up with a case to
# confuse with <$File_Handle>?
If you assume infinite lookahead, it's fine, but if not...
...
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 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 []. 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 with <$File_Handle>? sub postfix:bar returns handle; $y = undef ; 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 C, > 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 thing, I was wrong. Though there is a case that does it: sub bar(); sub postfix:bar($x) returns IO::Handle; $x = length ; 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 C,
> > 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 C, 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 //, $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 C, 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 //, $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
Re: Perl6 Operator List
On Fri, 1 Nov 2002 [EMAIL PROTECTED] wrote: : 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 ? I think a postfix has to be "attached" always. If there is no postfix, then a binary operator doesn't need to have space before it. Otherwise it does. : probably the same question for prefix operators . You can always put a space after a prefix operator, since you can only get one of those when a term is expected. Larry
Re: Primitive Boolean type?
On Thu, 31 Oct 2002, David Wheeler wrote: : 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. That is correct. It probably throws an exception if you try to assign an undefined value to a lowercase type. (Though an IEEE num might well set itself to NaN instead.) Larry
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 with <$File_Handle>? : > : > : : it seems that parser cannot confuse them because 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, : C: Please don't think of C 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
Re: [RFC] Perl6 Operator List, Take 5
On Thu, 2002-10-31 at 12:15, Larry Wall wrote:
> On 31 Oct 2002, brian wheeler wrote:
> : I agree considering, this isn't APL and the problems people have had
> : mailing examples (let alone creating them!).
>
> Nevertheless, it has already been decreed that Perl 6 programs are
> written in Unicode. That's not gonna change...
>
Fair enough. However it seems the world isn't ready for unicode
operators. Ok, maybe its me that's not ready. Being a boring American
from the midwest I don't need no stinking French quotes! :) The fries
are good, though.
Anyway, I think that this is a good discussion (despite there being too
many threads to try to follow) and an important one. However,
considering I've spent the last 45 minutes trying to figure a quick way
to enter french quotes into my mailer and editor without them both being
very different and without resorting to cutting and pasting is showing
me that there are big problems with my environment (redhat 8, emacs,
evolution) and I suspect I'm not the only one. Displaying the glyphs
has been ok, for the most part, but its been hit and miss, depending on
other people's configuration. Some tables of operators have had lots of
holes.
It seems that to write effective perl using the new features requires me
to change not only how I think in the language, but also how I use my
computer. I think this might be too big of a leap for some. Unless
there's a compromise. Which brings up a question I hesitate to ask:
will there be the equivalent of trigraphs to cover the non-ascii
characters used? While ??< is a terrible substitute for {, it did get
the job done when people weren't able to press the '{' key. It gave
some visual clue as to what was going on, and was fairly easy to
remember. It doesn't bother me if someone wants to use @StraÃe for an
array, but it gets bad if when instructing others I have to pull some
voodoo key sequence (especially one which is different for each platform
and/or program being used) in order to get the job done. Explaining
emacs' M-x was bad enough for some of the non-programmers in my
organization.
I'm going to go back to lurking now, because I do trust (most) of you.
Though Dan is pretty odd sometimes. :) I know that all of this will get
resolved in a (hopefully) sane fashion. I just wanted to voice my
concerns.
> : I've got to admit all of these operators are scaring me. Seems alot
> : like Brooks' second-system effect.
>
> But that's our slogan:
>
> Perl 6 is second-system effect done right.
>
> :-)
>
But, doesn't *everyone* say that? :)
Brian
> Larry
Re: Primitive Boolean type?
Larry Wall wrote:
> Please don't think of C 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.
Er... dang. While I certainly agree with the concept in principle, I'm
having a hard time sticking to it when I'm writing beginner-level docs.
Suppose I'm declaring something like:
class Appliance {
has bit $.is_plugged_in;
has bit $.is_turned_on;
has bit $.has_ul_approval;
}
I'm declaring three attributes that are specifically always either true
or false. They can *only* be true/false, or yes/no, or 1/0 -- they have
no other possible values, and I want to declare them in such a way as to
clearly enforce that behavior. C<$.is_plugged_in> is never "5" or
"timmy" -- only true or false, period! By definition, my _intention_ is
therefore to declare these three attributes as containing "boolean" values.
The problem I'm having is that there are few good ways to describe the
above behavior without using the word "boolean". The word is
conspicuous in its absence; it's like someone trying to describe Daffy
Duck to you without using the word "duck". Perhaps boolean is spelled
bit (or type bool ::= bit), but the associated value is unambiguously
"boolean", which makes the attribute logically "boolean" in type.
Similarly I would assume that we want the capability to refer to boolean
context by name (just as we can refer to scalar, list (array?), numeric,
string, and other contexts) if for no other reason than to be able to
make declarations like:
sub foo (int $i; str $s; bool $y) { ... }
which, from appearances, seems to strongly _imply_ to the user that
there is indeed a 'bool' type, just as there is an 'int' type and a
'str' type. (They may be wrong, but that's intuitively what the above
signature _appears_ to say.)
So while I understand the philosophical/semantic reasons for the absence
of a true boolean type, I wonder how easy it will be to describe the
principle to newcomers, and if it's worth it. When someone asks "what's
the boolean type in Perl?" I'd rather answer "bit" than "Perl doesn't
have one", if for no other reason than the latter answer will completely
freak them out. :-)
Feedback? What am I missing?
MikeL
Re: Primitive Boolean type?
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Thu, 31 Oct 2002 22:36:58 -0800
> From: Michael Lazzaro <[EMAIL PROTECTED]>
> X-Accept-Language: en,pdf
> Cc: [EMAIL PROTECTED]
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
>
> Larry Wall wrote:
> > Please don't think of C 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.
>
> Er... dang. While I certainly agree with the concept in principle, I'm
> having a hard time sticking to it when I'm writing beginner-level docs.
> Suppose I'm declaring something like:
>
> class Appliance {
>
> has bit $.is_plugged_in;
> has bit $.is_turned_on;
> has bit $.has_ul_approval;
> }
>
> I'm declaring three attributes that are specifically always either true
> or false. They can *only* be true/false, or yes/no, or 1/0 -- they have
> no other possible values, and I want to declare them in such a way as to
> clearly enforce that behavior. C<$.is_plugged_in> is never "5" or
> "timmy" -- only true or false, period! By definition, my _intention_ is
> therefore to declare these three attributes as containing "boolean" values.
I suppose, since anything can have the "true" or "false" properties,
you could roll your own boolean type like so:
class bool { }
Then
my bool $electricity;
Can contain nothing at all. But it can be true or false, since
"everything is a boolean." I like that idea. You would use it (a tad
awkwardly) as such:
$electricity but= true if $plug;
$electricity but= false if $short_circuit;
Luke
Re: Question about "for" loop
On Fri, Nov 01, 2002 at 02:40:08AM +0200, [EMAIL PROTECTED] wrote:
>
> for @a -> $x, $y { ... $x is topic ... }
>
> for @a ; @b ->
> $x, $y ; $z { ... WHAT is topic ? ... }
>
> what is topic in multi stream loop ?
Always the first, so $x in both. Unless you specify otherwise:
for @a ; @b ->
$x, $y is topic ; $z { ... $y is topic ... }
Try this:
http://www.perl.com/pub/a/2002/10/30/topic.html
Allison
