Re: [RFC] Perl6 Operator List, Take 5
On Wed, 30 Oct 2002 15:31:24 -0800, Michael Lazzaro wrote: Meaning that the list: +^- force to numeric context, complement ~^- force to string context, complement simply becomes: ^ - complement (type-specific) Does this include booleans? I really liked the idea that not and xor were just the same operator, but unary/binary. Otherwise, we have ! for boolean negation only, while ^ does the same thing for other types, as well as xor for everything. I don't mind leaving ! in as a synonym. -- Peter Haworth [EMAIL PROTECTED] Send this via the BT scuz-a-filtron -- Andy Wardley
Re: [RFC] Perl6 Operator List, Take 5
On Tuesday, November 5, 2002, at 06:51 AM, Peter Haworth wrote: On Wed, 30 Oct 2002 15:31:24 -0800, Michael Lazzaro wrote: Meaning that the list: +^- force to numeric context, complement ~^- force to string context, complement simply becomes: ^ - complement (type-specific) Does this include booleans? I really liked the idea that not and xor were just the same operator, but unary/binary. Otherwise, we have ! for boolean negation only, while ^ does the same thing for other types, as well as xor for everything. I don't mind leaving ! in as a synonym. Yes, almost certainly a ^ on a bit or boolean would be the same as ! -- they both would negate, since the complement of 1 is 0, and vice versa. MikeL
Re: [RFC] Perl6 Operator List, Take 5
Peter Haworth wrote: On Wed, 30 Oct 2002 15:31:24 -0800, Michael Lazzaro wrote: Meaning that the list: +^- force to numeric context, complement ~^- force to string context, complement simply becomes: ^ - complement (type-specific) Does this include booleans? I really liked the idea that not and xor were just the same operator, but unary/binary. Otherwise, we have ! for boolean negation only, while ^ does the same thing for other types, as well as xor for everything. I don't mind leaving ! in as a synonym. Perhaps C! is just a (preferred) synonym for C?^. Which suggests: Unary: ^ X eval X in scalar context, then bitwise complement polymorphically ~^ X eval X in string context, then bitwise complement chars +^ X eval X in numeric context, then bitwise complement number ?^ X eval X in boolean context, then bitwise complement bit ! X eval X in boolean context, then bitwise complement bit (preferred form) Binary Junctive: X ^ Y eval X and Y in scalar context and form their exjunction X ~^ Yeval X and Y in string context and form their exjunction X +^ Yeval X and Y in numeric context and form their exjunction X ?^ Yeval X and Y in boolean context and form their exjunction X ! Y eval X and Y in boolean context and form their exjunction Binary Bitwise: X .^ Yeval X and Y in scalar context and form their polymorphic bitwise XOR X ~.^ Y eval X and Y in string context and form their charwise bitwise XOR X +.^ Y eval X and Y in numeric context and form their bitwise XOR Binary Logical: X ?^^ Y eval X and Y in boolean context and compute their XOR X !! Yeval X and Y in boolean context and compute their XOR (preferred form) In other words: Unary:^ Junctive: ^ Bitwise: .^ Logical: ?^^ String contextualizer prefix: ~ Numeric contextualizer prefix:+ Boolean contextualizer prefix:? Synonym for unary and binary ?^: ! Synonym for binary ?^^: !! Incidentally, that leaves C^ free to be the unambiguous vectorizing prefix (modulo the C^+= ambiguity). I still vastly prefer C»op« though. Damian
Re: [RFC] Perl6 Operator List, Take 5
On Thu, 31 Oct 2002, Damian Conway wrote: Larry mused: Of course, Real Mathematicians will want [1..10) and (1..10] instead. Forgive me but is this syntax really necessary. Does it buy us enough over +1 and -1? And for what it's worth, Real Mathematicians do not use open intervals for integers! (Sorry for the late post, but p6l is always 200 messages ahead of me) -- Philippe BooK Bruhat One lesson learned is never enough. (Moral from Groo The Wanderer #104 (Epic))
Re: [RFC] Perl6 Operator List, Take 5
On (02/11/02 11:18), Philippe 'BooK' Bruhat wrote: Date: Sat, 2 Nov 2002 11:18:22 +0100 (CET) From: Philippe 'BooK' Bruhat [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: Re: [RFC] Perl6 Operator List, Take 5 On Thu, 31 Oct 2002, Damian Conway wrote: Larry mused: Of course, Real Mathematicians will want [1..10) and (1..10] instead. Forgive me but is this syntax really necessary. Does it buy us enough over +1 and -1? And for what it's worth, Real Mathematicians do not use open intervals for integers! BooK, we are not talking topology here even if we are free to borrow syntax from anywhere for notational convenience and mnemonic value. But here, this will buy us not much, will confuse editors like vi or emacs; Also the notation itself is not even universally adopted. In French schools, we were writing [1..10[ for the [1..10). I find the French notation more mnemonic because it shows clearly that the right bracket is porous. -- stef (Sorry for the late post, but p6l is always 200 messages ahead of me) -- Philippe BooK Bruhat One lesson learned is never enough. (Moral from Groo The Wanderer #104 (Epic))
Re: [RFC] Perl6 Operator List, Take 5
Luke Palmer writes: All that said, can anyone come up with a case to confuse op with $File_Handle? sub postfix:bar returns handle; $y = undef bar; That has two syntactically valid interpretations. It wouldn't take even that much to confuse the parser, though. Luke it seems that this example does not work because : if bar is postfix op then it have to be attached $y = undef _bar and _ is just (optional) part of the name of all postfix operators. or $y = undefbar the first interpretation canneot work because unary undef op requires lvalue expression as its argument , and iterator is not . but it seems , that anyway , the problem here is not with op sintax but with the fact that undef is *term* or *unary prefix op* . (and it is the only one ( ... ?? ) ) arcadi .
Re: [RFC] Perl6 Operator List, Take 5
On 2002-11-01 at 16:03:51, Iain 'Spoon' Truskett wrote: I'm not too concerned about unicode since my xterm doesn't support it anyway =) XFree86 4.2.0 xterm does UTF-8 (when requested to do so via the -u8 flag). If course, you need a Uniciode/ISO-10646 X11 font, but there are plenty of those around; several came with my RedHat 7.2 Linux distribution. Unfortunately the nicer X terminal emulators that come with KDE and Gnome don't seem to do UTF-8 yet. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
RE: [RFC] Perl6 Operator List, Take 5
--
On Thu, 31 Oct 2002 15:08:06
Brent Dax wrote:
Erik Steven Harrison:
# All that said, can anyone come up with a case to
# confuse op with $File_Handle?
If you assume infinite lookahead, it's fine, but if not...
something ...
Is that a call to
sub something() returns(IO::Handle)
or a hypered
sub operator:something($operand:)
Granted. So, I'm not as bright as I'd like to be. But
it's not unreasonable to ask for the parens to
disambiguate, and I think that I could live with a
required something() as opposed to girly French
angles I can't type, especially since (at least for
me) the vector ops are the common case.
I'll be up front and honest: I don't know enough about parsers. But don't we know what
operators were using before we parse, and use that knowledge to disambiguate? Sure we
can define new operators, but aren't we already assuming infinite lookahead if we can
define new operators and use them without a foreward declaration?
-Erik
?
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Get 25MB of email storage with Lycos Mail Plus!
Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
RE: [RFC] Perl6 Operator List, Take 5
From: Larry Wall [mailto:larry;wall.org] 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. In the quest for keys anyone can reach on any keyboard... instead of «*» why not: (*), )*(, )*(, [*], or [)*(] Which stands out best? @a «*» @b @a (*) @b @a )*( @b @a )*( @b @a [*] @b @a [)*(] @b IMHO [*] -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
Re: [RFC] Perl6 Operator List, Take 5
On Fri, Nov 01, 2002 at 09:39:28AM -0600, Garrett Goebel wrote: In the quest for keys anyone can reach on any keyboard... instead of «*» why not: (*), )*(, )*(, [*], or [)*(] Which stands out best? a «*» b a (*) b a )*( b a )*( b a [*] b a [)*(] b IMHO [*] That might or might not be a solution for the particular case, but I think that, over the long term, it would be much better to have a general solution to the problem of how to represent a character that's not mapped to the keyboard. In five years, everyone's display will be able to display any Unicode character. The keyboards will necessarily lag behind. But if we had a general way to represent a character as a sort of entity, we could translate to Unicode at some point in a kind of fixup pass. I could see using backtick as the escape code for things like ` or ` which would turn into what some benighted soul called girly angles. Larry
RE: [RFC] Perl6 Operator List, Take 5
Garrett Goebel said: Which stands out best? a «*» b a (*) b a )*( b a )*( b a [*] b a [)*(] b IMHO [*] I say go with the one with the cutest name. Garrett's choice is the bow-tie operator--not bad. This one: (*) is also a pretty good bow-tie. This one: )*( would be the talking-out-of-both-sides-of-your-face operator. Useful for marketing. But this one: )*( can, in the TMTOWTDI spirit, be either the Madonna or the Anna Nicole operator. I think the choice is clear. Thanks, John A see me fulminate at http://www.jzip.org/
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
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: [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: [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 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: [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: [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: [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: [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: [RFC] Perl6 Operator List, Take 5
--
On Thu, 31 Oct 2002 11:26:13
Brent Dax wrote:
I can honestly say at this point that I'd rather give up $iterator
than lose hyperops.
I was thinking the same thing not long ago. But now
that I think about it, is operator ever going to be
confused for $File_Handle? The vector operation cosy
up well to the concept of iteration anyway. Hell, if
were desperate (and I think we are) then why not just
double the brackets to [op] or [op]. Sure it's
ugly, but I prefer it to ^[op] any day of the week,
and it's not going to be ambiguous.
All that said, can anyone come up with a case to
confuse op with $File_Handle?
-Erik
And I consider relegating them to the
digraphs losing them, because I'm never going to be able to remember how
to type them, and neither will anybody else.
Let's look at this logically. Here's all the punctuation (non-\w)
characters on my keyboard and what they do in Perl 6:
TERMOPERATORDOUBLE
OPERATOR
` backticks nonenone
' string constantsnone** none
string constantsnonenone
# comment comment comment
$ scalar sigilnonenone
@ array sigil nonenone
% hash sigil modulo none
sub sigil junction and** logical and
! logical not none (?)none
^ complement junction xor** logical xor**
| nonejunction or** logical or
/ regex divide defined or (in
5.9)
* list flatten* multiplyexponent
- numify and negate subtraction
postdecrement
+ numify**addition
postincrement
~ stringify* concat**smart
match
= noneassignment
comparison
\ get reference nonenone
.. method call** method call** range constructor
? force to bool* none** trinary operator
, nonelist composer list composer
; nonestatement end statement end
(in parentheses) super-comma none
: nonesuper-comma package
separator, trinary operator
( )expression grouping sub parameters yuck
{ }hash composing hash subscripts yuck
block composing block composing yuck
[ ]array composing array subscriptsyuck
iterator syntax comparison ops shift-left, shift-right
UNUSED:5 8 9
Items marked with a * are new, ** are changed. There are twenty-two
'none's on that list, but none of them line up. (Isn't Perl great?!?)
';;' is available (it doesn't mean anything in either term or operator
context), but it's really ugly. The other possibilities I see there
have the same problem.
There are potentially some meaningless sequences, especially with
sigils, but those'll look quite cluttered. Actually, one of the few
good meaningless ones is ^[op] (with the square brackets). In term
context it would normally mean bitwise complement this array, and in
operator context it would mean add this array to an xor junction. If
we lose xor junctions (which I'm not necessarily advocating, mind you),
this sequence is pretty much open.
Damn. Larry, I don't envy you your job. :^)
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Get 25MB of email storage with Lycos Mail Plus!
Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
RE: [RFC] Perl6 Operator List, Take 5
Erik Steven Harrison writes: All that said, can anyone come up with a case to confuse op with $File_Handle? it seems that parser cannot confuse them because op is operator and parser expect operator, while $File_Handle is a term . but human can confuse . I personally also like op sintax. arcadi .
RE: [RFC] Perl6 Operator List, Take 5
Erik Steven Harrison:
# All that said, can anyone come up with a case to
# confuse op with $File_Handle?
If you assume infinite lookahead, it's fine, but if not...
something ...
Is that a call to
sub something() returns(IO::Handle)
or a hypered
sub operator:something($operand:)
?
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Re: [RFC] Perl6 Operator List, Take 5
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Date: Thu, 31 Oct 2002 14:45:16 -0800 From: Erik Steven Harrison [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] X-Sent-Mail: off Reply-To: [EMAIL PROTECTED] X-Sender-Ip: 152.18.50.63 Organization: Angelfire (http://email.angelfire.mailcity.lycos.com:80) Content-Language: en X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/ -- On Thu, 31 Oct 2002 11:26:13 Brent Dax wrote: I can honestly say at this point that I'd rather give up $iterator than lose hyperops. I was thinking the same thing not long ago. But now that I think about it, is operator ever going to be confused for $File_Handle? The vector operation cosy up well to the concept of iteration anyway. Hell, if were desperate (and I think we are) then why not just double the brackets to [op] or [op]. Sure it's ugly, but I prefer it to ^[op] any day of the week, and it's not going to be ambiguous. All that said, can anyone come up with a case to confuse op with $File_Handle? sub postfix:bar returns handle; $y = undef bar; That has two syntactically valid interpretations. It wouldn't take even that much to confuse the parser, though. Luke
RE: [RFC] Perl6 Operator List, Take 5
On Fri, 1 Nov 2002 [EMAIL PROTECTED] wrote: : Erik Steven Harrison writes: : : : All that said, can anyone come up with a case to : confuse op with $File_Handle? : : : : it seems that parser cannot confuse them because op is operator and : parser expect operator, while $File_Handle is a term . All unary operators show up when a term is expected, not an operator. Larry
Re: [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 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 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: [RFC] Perl6 Operator List, Take 5
On Tue, Oct 29, 2002 at 05:16:48PM -0800, Michael Lazzaro wrote: unary (prefix) operators: \ - reference to * - list flattening ? - force to bool context ! - force to bool context, negate not - force to bool context, negate + - force to numeric context - - force to numeric context, negate +^- force to numeric context, complement ~ - force to string context ~^- force to string context, complement Noe that we have gained ^ back from being a hyeroperator, could we not have ^ as a polymorphic complement operator. It can always be combined with ~ or + to force context, eg $a = ^ +$b; $a = ^ ~$b; We would then have a complement operator that I would assume objects could overload and do whatever they liked with. Graham.
Re: [RFC] Perl6 Operator List, Take 5
[EMAIL PROTECTED] (Larry Wall) writes: Still thinking about ..! or ..^ or some such. Could have ^..^ and ^.. too, for all that. We could indeed have a whole range of Japanese smiley operators. -- A year spent in artificial intelligence is enough to make one believe in God.
Re: [RFC] Perl6 Operator List, Take 5
LW said:
:...- readline
Iterate interator.
Couldn't we go the python way and assume that .. is implicit in
for statments:
$fh = open(..);
for $fh { # instead of for $fh
print $_;
}
For explicit iteration, we could well do just with a .next method:
while ($line = $fh.next) {
print $line;
}
And the old perl construct:
while () {
print $_
};
Could be replaced with a open() without arguments, such as:
for open() {
print $_;
}
And then .. could go back to being a gentler replacement of qw...
Or is there any problem that my blind eyes can't see?
-angel
Re: [RFC] Perl6 Operator List, Take 5
On Wed, 30 Oct 2002, Mark J. Reed wrote: : Larry's mail was *marked* as UTF-8, but by the time I got it it : had no French quotes in it in UTF-8, Latin-1, or any other encoding anymore. : My mailer understand UTF-8 just fine, and so does vim (which I used to : look at my spool file to check for encoding oddities); in my copy of his : message, there's just nothing there. All I can think is that some MTA : along the way - possibly our very own Exchange server - stripped them out. 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 an environment where vim does UTF-8. And I may have been in a UTF-8 window at the time. Things could easily get screwed up between them. (Anybody know of a version of pine that does UTF-8?) This is currently running in a window that does Latin-1 rather than UTF-8. Do these French quotes come through? a «+» b Larry
Re: [RFC] Perl6 Operator List, Take 5
On Wed, Oct 30, 2002 at 11:10:54PM +0200, Markus Laire wrote: If we are going to do math with ranges, we definitely need non- discreet ranges also. Or at least make sure it's easy enough to implement as a class. (1.9 .. 2.1) + (5..7) * (72.49 .. 72.51); I don't think that non-discrete ranges is what you mean. Perhaps you just want ranges whose step size is something other than 1 (1.9 .. 2.1 : 0.1) + (5..7) * (72.49 .. 72.51 : 0.01) ? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: [RFC] Perl6 Operator List, Take 5
--- Larry Wall [EMAIL PROTECTED] wrote: Do these French quotes come through? @a «+» @b Oui, M'sieu! __ 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 12:47 PM, Larry Wall wrote: This is currently running in a window that does Latin-1 rather than UTF-8. Do these French quotes come through? @a ´+ª @b Nope. But given that I don't even know where to go to type them in, and doing so will likely be a PITA...even though I *love* the idea of using these characters, might it be better to abandon them for now? Regards, David PS: What do they look like in this reply? -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: [RFC] Perl6 Operator List, Take 5
On Wed, Oct 30, 2002 at 01:25:44PM -0800, Austin Hastings wrote: --- Larry Wall [EMAIL PROTECTED] wrote: Do these French quotes come through? @a «+» @b Odd, I see them in this message. But In the message from Larry I see ?'s Graham.
Re: [RFC] Perl6 Operator List, Take 5
On Wednesday, October 30, 2002, at 01:28 PM, David Wheeler wrote: But given that I don't even know where to go to type them in, and doing so will likely be a PITA...even though I *love* the idea of using these characters, might it be better to abandon them for now? Oh, don't say that! I already know what all of these should mean! :-) ≈ … ∫ § ¿ ∆ ∑ Ω ø ¶ º ≠ ≤ ≥ ‹ › ‡ Ø ˇ ¬ Ç Œ ∞ ¡ • MikeL
Re: [RFC] Perl6 Operator List, Take 5
On Wednesday, October 30, 2002, at 01:35 PM, Graham Barr wrote: On Wed, Oct 30, 2002 at 01:25:44PM -0800, Austin Hastings wrote: --- Larry Wall [EMAIL PROTECTED] wrote: Do these French quotes come through? @a «+» @b Odd, I see them in this message. But In the message from Larry I see ?'s And I didn't see them in Austin's message, but I see them in yours. Your mailer did the right thing, it looks like. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: [RFC] Perl6 Operator List, Take 5
On Wednesday, October 30, 2002, at 01:43 PM, Michael Lazzaro wrote: Oh, don't say that! I already know what all of these should mean! :-) ≈ … ∫ § ¿ ∆ ∑ Ω ø ¶ º ≠ ≤ ≥ ‹ › ‡ Ø ˇ ¬ Ç Œ ∞ ¡ • Nice, I can see all of those. Your mailer is the same as mine, Apple Mail, and the headers are: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Which is correct. But let me ask you -- how did you input those characters? David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: [RFC] Perl6 Operator List, Take 5
On Wednesday, October 30, 2002, at 01:46 PM, David Wheeler wrote: But let me ask you -- how did you input those characters? Applications/Utilities/Key Caps (Again, OSX) which shows you where they all are. The «» quotes, for example, are option-\ and shift-option-\ :-) MikeL
Re: [RFC] Perl6 Operator List, Take 5
On Tue, Oct 29, 2002 at 11:39:26PM -0800, Michael Lazzaro wrote: So maybe the correct interpretation of the above is indeed this: (1..10)-1 # (1..10).length-1, e.g. 9 (oops!) Do range objects return their length in scalar context? (1..10) [-] 1 # (0..9) (correct, if that's WYM) That's how I would write it if that's what I meant. meaning that (1..10)-1 almost always does The Wrong Thing(!) Indeed. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: [RFC] Perl6 Operator List, Take 5
Maybe we've gone over this before but, if so, I don't remember ...
On Tue, Oct 29, 2002 at 05:16:48PM -0800, Michael Lazzaro wrote:
hyperoperators:
[op] - as prefix to any unary/binary operator, vectorizes the
operator
. - method call on current topic
What would [.]method() mean?
====!== - comparision
lt gtlegeeqnecmp
What do these do?
if $a [] @b { ... }# if $a all(*@b) ???
if @a [] @b { ... }# if $a[0] all(*@b)
#$a[1] all(*@b)
#$a[2] all(*@b) ... ???
| ^ - superpositional operations
$a [] @b # all($a,*@b) ???
@a [] @b # all(*@a,*@b) ???
= - pair creator
%hash = (@a [=] @b); # %hash{@a} = @b; ???
%hash = (@a [=] $b); # %hash{@a} = ($b) x @a;???
,- list creator
@a = ($b [,] @c); # @a = ($b, *@c); ???
;- greater comma, list-of-lists creator
:- adverbial
I'm not even sure how to hyper these two. I guess if I had an array
of range objects I could hyper ;
Would this write to several filehandles?
print @file_handles [:] fooey!\n;
.. - range
And this is the one that made me start thinking about hypering the
others
@a = @b[..]@c # @a = ($b[0]..$c[0], $b[1]..$c[1], ...) ???
@a = $b[..]@c # @a = ($b..$c[0], $b..$c[1], ...) ???
@a = @b[..]$c # @a = ($b[0]..$c, $b[1]..$c, ...) ???
I know that this stuff probably seems obvious to everyone, but I'd
rather have it explicit just in case :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: [RFC] Perl6 Operator List, Take 5
--- Jonathan Scott Duff [EMAIL PROTECTED] wrote:
Maybe we've gone over this before but, if so, I don't remember ...
On Tue, Oct 29, 2002 at 05:16:48PM -0800, Michael Lazzaro wrote:
hyperoperators:
[op] - as prefix to any unary/binary operator, vectorizes the
operator
. - method call on current topic
What would [.]method() mean?
@a = @b[.]method(); # Sets each @a[x] to @b[x].method()
Thinking out loud ...
@a = @b[.method()]; # Sets @a to the value stored in @b indexed by
# current context.method()
====!== - comparision
lt gtlegeeqnecmp
What do these do?
if $a [] @b { ... }# if $a all(*@b)
Credible.
if @a [] @b { ... }# if $a[0] all(*@b)
#$a[1] all(*@b)
#$a[2] all(*@b)
My inclination here is that $a[0] $b[0] $a[1] $b[1] ...
$a [] @b # all($a,*@b) ???
Questionable. Perhaps an array s.t. @result[x] = $a @b[x] ?
On the other hand, I like the idea of being able to distribute an
operator using this syntax...
@a = @b op $c
versus
?? = @b [op] $c
What's the difference? One maybe produces @b[x] op $c while the other
produces - { $result = $c; for @b - $b { $c op= $b; } }
But then it's not legal any more in array context unless @b is a LoL.
Erk!
@a [] @b # all(*@a,*@b) ???
Array s.t. @result[x] = @a[x] @b[x]
@a = ($b [,] @c); # @a = ($b, *@c); ???
LoL: @a[x] = ($b, @c[x])
I'm not even sure how to hyper these two. I guess if I had an array
of range objects I could hyper ;
Hypersemi is probably just the same as hypercomma, since the
circumlocutions needed to use it are such that you'll probably specify
the construction clearly.
But if not:
@a = @b [;] @c -- @a[x] = ((@b[x]) ; (@c[x]))
Would this write to several filehandles?
print @file_handles [:] fooey!\n;
.. - range
And this is the one that made me start thinking about hypering the
others
@a = @b[..]@c # @a = ($b[0]..$c[0], $b[1]..$c[1], ...) ???
@a = $b[..]@c # @a = ($b..$c[0], $b..$c[1], ...) ???
@a = @b[..]$c # @a = ($b[0]..$c, $b[1]..$c, ...) ???
You, too? Range was the first thing I started trying to hyper.
I know that this stuff probably seems obvious to everyone, but I'd
rather have it explicit just in case :-)
if $x == any(@b[..]@c)
print In one of the ranges...\n;
or
if $x ~~ any(@b[..]@c)
print In one of the ranges...\n;
Does .. create an implicit flexpr in numeric context, or does it
require smartmatch?
=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 Operator List, Take 5
When I'm trying to figure out what the default hypering semantics for
an operator would be, I use this:
***BEGIN CODE***
{
use strict;
use warnings;
sub _is_arrayref { ref $_[0] ref $_[0] eq 'ARRAY' }
sub hyper(\@\@) {
my($code, $a, $b)=@_;
my @results;
if(_is_arrayref($a)) {
if(_is_arrayref($b)) {
my $alen=$#{$a};
my $blen=$#{$b};
my $maxlen=$alen;
if($alen $blen) {
for($blen + 1 .. $alen) {
$b-[$_]='';
}
}
elsif($blen $alen) {
for($alen + 1 .. $blen) {
$a-[$_]='';
}
$maxlen=$blen;
}
for(0..$maxlen) {
push @results, vector($code, $a-[$_] ,
$b-[$_]);
}
if($alen $blen) {
$#{$b}=$blen;
}
elsif($blen $alen) {
$#{$a}=$alen;
}
}
else {
for(@$a) {
push @results, vector($code, $_, $b);
}
}
}
elsif(_is_arrayref($b)) {
for(@$b) {
push @results, vector($code, $a, $_);
}
}
else {
no strict 'refs';
no warnings 'once';
local *{caller().'::a'}=\$a;
local *{caller().'::b'}=\$b;
return $code-();
}
return @results;
}
}
my @a=qw(1 2 3); my @b=([qw(4 5 6)], [qw(7 8 9)], [qw(10 11 12)]);
print join ' ', hyper { $a + $b } @a, @b;
***END CODE***
With that in mind...
Jonathan Scott Duff:
# What would [.]method() mean?
Presumably, @foo[.]method() would call .method on each object.
#====!== - comparision
# lt gtlegeeqnecmp
#
# What do these do?
#
# if $a [] @b { ... }# if $a all(*@b)
# ???
# if @a [] @b { ... }# if $a[0] all(*@b)
# #$a[1] all(*@b)
# #$a[2] all(*@b)
# ... ???
Create a list of the results. For example:
@a=qw(1 2 3);
@b=qw(3 2 1);
print join ' ', hyper { $a $b } @a, @b;
#prints 1 0 0
# | ^ - superpositional operations
#
# $a [] @b # all($a,*@b) ???
# @a [] @b # all(*@a,*@b) ???
#
# = - pair creator
#
# %hash = (@a [=] @b); # %hash{@a} = @b; ???
# %hash = (@a [=] $b); # %hash{@a} = ($b) x
# @a; ???
I think that's correct. Actually, that's a really useful behavior...
# ,- list creator
#
# @a = ($b [,] @c); # @a = ($b, *@c); ???
#
# ;- greater comma, list-of-lists creator
# :- adverbial
#
# I'm not even sure how to hyper these two. I guess if I had
# an array of range objects I could hyper ;
Aren't these more syntax than operator?
# Would this write to several filehandles?
#
# print @file_handles [:] fooey!\n;
Perhaps.
# .. - range
#
# And this is the one that made me start thinking about
# hypering the others
#
# @a = @b[..]@c # @a = ($b[0]..$c[0], $b[1]..$c[1], ...) ???
# @a = $b[..]@c # @a = ($b..$c[0], $b..$c[1], ...) ???
# @a = @b[..]$c # @a = ($b[0]..$c, $b[1]..$c, ...) ???
That's a really good one. My naive implementation gives this:
1 2 3 4 1 2 3 4 5 1 2 3 4 5 6 2 3 4 5 6 7 2 3 4 5 6 7 8 2 3 4 5 6 7 8 9
3 4 5 6 7 8 9 10 3 4 5 6 7 8 9 10 11 3 4 5 6 7 8 9 10 11 12
Perhaps that would be:
[1 2 3 4] [1 2 3 4 5] [1 2 3 4 5 6] [2 3 4 5 6 7 8] [2 3 4 5 6 7 8 9] [3
4 5 6 7 8 9 10] [3 4 5 6 7 8 9 10 11] [3 4 5 6 7 8 9 10 11 12]
--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 Operator List, Take 5
On Wed, Oct 30, 2002 at 09:13:02AM -0800, Austin Hastings wrote:
--- Jonathan Scott Duff [EMAIL PROTECTED] wrote:
Maybe we've gone over this before but, if so, I don't remember ...
On Tue, Oct 29, 2002 at 05:16:48PM -0800, Michael Lazzaro wrote:
hyperoperators:
[op] - as prefix to any unary/binary operator, vectorizes the
operator
. - method call on current topic
What would [.]method() mean?
@a = @b[.]method(); # Sets each @a[x] to @b[x].method()
No, no. I'm talking about the unary . prefix
method blah {
.foo()
[.]foo() # What does this mean?
}
if @a [] @b { ... }# if $a[0] all(*@b)
#$a[1] all(*@b)
#$a[2] all(*@b)
My inclination here is that $a[0] $b[0] $a[1] $b[1] ...
Oops, that's what I meant. I had originally written
if all(*@a) all(*@b)
but then realized that the semantics would be all wrong.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: [RFC] Perl6 Operator List, Take 5
[.]foo() # What does this mean? One could argue that several ways, depending on what's in the current topic. It's the exact same thing as the binary form of dot, but with the left side being implied, as 'the current topic': topic is a scalar: hyperdot does nothing (scalar hyperop scalar == scalar op scalar) topic is a listref: listref is automatically dereferenced, foo method is called on all elements. (In other words, I imagine calling a hyper on scalars is not an error -- it just doesn't do anything more interesting than the normal op.) Note you could also perhaps say something like [.]$methodlist() to mean call each of these methods on (each of) the current topic(s), tho I'm not sure the syntax is accurate there. MikeL
Re: [RFC] Perl6 Operator List, Take 5
--- Jonathan Scott Duff [EMAIL PROTECTED] wrote:
On Wed, Oct 30, 2002 at 09:13:02AM -0800, Austin Hastings wrote:
--- Jonathan Scott Duff [EMAIL PROTECTED] wrote:
Maybe we've gone over this before but, if so, I don't remember
...
On Tue, Oct 29, 2002 at 05:16:48PM -0800, Michael Lazzaro wrote:
hyperoperators:
[op] - as prefix to any unary/binary operator, vectorizes
the
operator
. - method call on current topic
What would [.]method() mean?
@a = @b[.]method(); # Sets each @a[x] to @b[x].method()
No, no. I'm talking about the unary . prefix
method blah {
.foo()
[.]foo() # What does this mean?
}
Vector of invocations of the foo methods of the current topic.
Presumably you'd have an array in topic, or you'd use it in an array
context.
for @lol - @onelist {
@a = [.]foo();
}
=Austin
__
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
Re: [RFC] Perl6 Operator List, Take 5
On Wed, 30 Oct 2002, Austin Hastings wrote:
: No, no. I'm talking about the unary . prefix
:
: method blah {
: .foo()
: [.]foo() # What does this mean?
: }
:
: Vector of invocations of the foo methods of the current topic.
Except that the topic is by definition singular in a method, and so
is a method name. So it'd be no different from ordinary dot. Maybe
it's an error to use a vector op on two scalars.
: Presumably you'd have an array in topic, or you'd use it in an array
: context.
:
: for lol - onelist {
:a = [.]foo();
: }
Yes, that would work, though I'd love to see it:
for lol - onelist {
a = «.»foo();
}
instead. Maybe ^[+] (or whatever) is just a workaround for people
who can't figure out how to write «+». I love the shimmers on
either side of the operator. That's a nice plural visual metaphor.
I'd even be willing to give up «foo bar baz» meaning qw(foo bar baz)
for this.
Larry
Re: [RFC] Perl6 Operator List, Take 5
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? MikeL
Re: [RFC] Perl6 Operator List, Take 5
On Wednesday, October 30, 2002, at 12:17 PM, Michael Lazzaro wrote: 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? I use Mail.app, and saw the same thing you did. When I looked at the headers for Larry's email, I saw: Content-Type: text/plain; charset=UTF-8; But when I saw yours, you had: Content-Type: text/plain; charset=ISO-8859-1; format=flowed This tells me that Mail.app, for some reason, didn't know that it was supposed to use UTF-8 when showing Larry's mail. When I pasted his mail into a UTF-8 document in Emacs, it looked fine. Given that it's probably UTF-8 that Perl 6 source code is written in, I think that you and I might be better off using a smarter mailer. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: [RFC] Perl6 Operator List, Take 5
On 2002-10-30 at 12:23:53, David Wheeler wrote: This tells me that Mail.app, for some reason, didn't know that it was supposed to use UTF-8 when showing Larry's mail. When I pasted his mail into a UTF-8 document in Emacs, it looked fine. Given that it's probably UTF-8 that Perl 6 source code is written in, I think that you and I might be better off using a smarter mailer. David Larry's mail was *marked* as UTF-8, but by the time I got it it had no French quotes in it in UTF-8, Latin-1, or any other encoding anymore. My mailer understand UTF-8 just fine, and so does vim (which I used to look at my spool file to check for encoding oddities); in my copy of his message, there's just nothing there. All I can think is that some MTA along the way - possibly our very own Exchange server - stripped them out. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: [RFC] Perl6 Operator List, Take 5
On 30/10/02 15:33 -0500, Mark J. Reed wrote: On 2002-10-30 at 12:23:53, David Wheeler wrote: This tells me that Mail.app, for some reason, didn't know that it was supposed to use UTF-8 when showing Larry's mail. When I pasted his mail into a UTF-8 document in Emacs, it looked fine. Given that it's probably UTF-8 that Perl 6 source code is written in, I think that you and I might be better off using a smarter mailer. David Larry's mail was *marked* as UTF-8, but by the time I got it it had no French quotes in it in UTF-8, Latin-1, or any other encoding anymore. My mailer understand UTF-8 just fine, and so does vim (which I used to look at my spool file to check for encoding oddities); in my copy of his message, there's just nothing there. All I can think is that some MTA along the way - possibly our very own Exchange server - stripped them out. Wait. So you mean that a French quote isn't a question mark? I take back all those things I've said about the French in the last 24 hours. Cheers, Brian
RE: [RFC] Perl6 Operator List, Take 5
On 29 Oct 2002 at 22:29, Larry Wall wrote:
Of course, Real Mathematicians will want [1..10) and (1..10] instead.
That seems familiar, I like it ;)
There's also an issue of what (1..10) - 1 would or should mean, if
anything. Does it mean (1..9)? Does 1 + (1..10) mean (2..10)?
And what would ('a' .. 'z') - 1 mean?
If we are going to do math with ranges, we definitely need non-
discreet ranges also. Or at least make sure it's easy enough to
implement as a class.
(1.9 .. 2.1) + (5..7) * (72.49 .. 72.51);
--
Markus Laire 'malaire' [EMAIL PROTECTED]
Re: [RFC] Perl6 Operator List, Take 5
On Wed, Oct 30, 2002 at 03:33:57PM -0500, Mark J. Reed wrote: On 2002-10-30 at 12:23:53, David Wheeler wrote: This tells me that Mail.app, for some reason, didn't know that it was supposed to use UTF-8 when showing Larry's mail. When I pasted his mail into a UTF-8 document in Emacs, it looked fine. Given that it's probably UTF-8 that Perl 6 source code is written in, I think that you and I might be better off using a smarter mailer. David Larry's mail was *marked* as UTF-8, but by the time I got it it had no French quotes in it in UTF-8, Latin-1, or any other encoding anymore. My mailer understand UTF-8 just fine, and so does vim (which I used to look at my spool file to check for encoding oddities); in my copy of his message, there's just nothing there. All I can think is that some MTA along the way - possibly our very own Exchange server - stripped them out. At the risk of getting very boring: Larry's message: Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT but the body had literal 8 bit Latin 1 «+» So the headers were not correct, as far as my mutt thinks, and it showed me a question mark. Austin Hastings' message: Content-Type: text/plain; charset=us-ascii but the body had literal 8 bit Latin 1 «+» So the headers were also not correct. Michael Lazzaro's message: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable body contains =ABop=BB which my mutt happily displays as «op» His headers accurately describe the body. I don't know what my mutt is going to do outgoing with this message. Clearly 8 bit is even more troublesome for mailers than whitespace. So maybe its a bad thing to use for a language. *However*, based on previous experience, I do know that literal ASCII bel characters: do pass quite successfully from 7 bit ASCII to EBCDIC and back again during their travels. Maybe we can use them for something :-) Nicholas Clark -- C++ templates better than perl? http://www.perl.org/advocacy/spoofathon/
Re: [RFC] Perl6 Operator List, Take 5
On 30 Oct 2002 at 15:24, Jonathan Scott Duff wrote: On Wed, Oct 30, 2002 at 11:10:54PM +0200, Markus Laire wrote: If we are going to do math with ranges, we definitely need non- discreet ranges also. Or at least make sure it's easy enough to implement as a class. (1.9 .. 2.1) + (5..7) * (72.49 .. 72.51); I don't think that non-discrete ranges is what you mean. Perhaps you just want ranges whose step size is something other than 1 (1.9 .. 2.1 : 0.1) + (5..7) * (72.49 .. 72.51 : 0.01) That would also be usefull, but I definitely mean math with non-discrete ranges. How else are you going to calculate with numbers which have 'uncertainty-range' (not sure about right term) i.e. all math in physics. There are bound to be other uses. This should probably be a class, so only problem is then to be sure that it's possible to create such a class and use it with easy syntax. Then there is a question of what such expressions should return. A superposition of non-discrete anges encompassing all the possible solutions would be the easy way. Adding probability distributions to those ranges would also be usefull. Still this is an implementation detail. -- Markus Laire 'malaire' [EMAIL PROTECTED]
Re: [RFC] Perl6 Operator List, Take 5
Larry mused: On Tue, 29 Oct 2002, David Whipp wrote: : Larry Wall [mailto:larry;wall.org] wrote: : : unary (postfix) operators: : :... - [maybe] same as ..Inf [Damian votes Yes] : : I wonder if we can possibly get the Rubyesque leaving out of : endpoints by saying something like 1..!10. : Of course, ..! and ..^ have the same problem. But it just seems like it's really unlikely that someone would use a unary ! or ^ on the endpoint term. So with 1..!$x or 1..^$x it's likely to be right if we guess (per the longest token rule) that the operator is ..! or ..^. The same can't be said of .., alas. But at least it might produce a syntax error when it tries to parse the . Of course, Real Mathematicians will want [1..10) and (1..10] instead. I kind like ..^ the best because ^ is currently read exclusive of anyway, sort of... And the arrow can be read up to, at least on that end of it. I think that ..^ is going to be much, much more common than ^.. will be. Forgive me but is this syntax really necessary. Does it buy us enough over +1 and -1? Proposed Now 1..101..10 1..^10 1..9 1..^$x 1..$x-1 1^..10 2..10 $x^..10 $x+1..10 1^..^10 2..9 $x^..^$y $x+1..$y-1 I mean, for what it is, I do like the syntax, but is it useful enough to warrant the extra cognitive load it brings with it? Damian
Re: [RFC] Perl6 Operator List, Take 5
Graham Barr wrote: Now that we have gained ^ back from being a hyeroperator, could we not have ^ as a polymorphic complement operator. It can always be combined with ~ or + to force context, eg $a = ^ +$b; $a = ^ ~$b; We would then have a complement operator that I would assume objects could overload and do whatever they liked with. In creating my operator list I deliberated shied away from the unary and binary multimorphic forms. But I do see Graham's point and would favour retaining polymorphic unary C^ at least. Damian
RE: [RFC] Perl6 Operator List, Take 5
Larry Wall:
# This is currently running in a window that does Latin-1
# rather than UTF-8. Do these French quotes come through?
#
# @a + @b
No, but I'm running Outlook, so it's probably a bug on my end. :^) (It
does show up in that annoying variable-width font it switches to for
displaying UTF-8, though.)
--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 Operator List, Take 5
[EMAIL PROTECTED] (Damian Conway) writes: Forgive me but is this syntax really necessary. If you're going for user-definable operators, most of this syntax is entirely unnecessary. Take all the hairy stuff out of core and be done with it! This won't stop people arguing about it, though. :) -- Henry, I'm a Regent Master of the Ancient and Venerable House of Congregation. Being eccentrically dull is practically my job description. - Jonathan Jones
Re: [RFC] Perl6 Operator List, Take 5
[EMAIL PROTECTED] (Michael Lazzaro) writes: â  ⠦ ⠫ § ¿ â  â  Ω ø ¶ º â Â â ¤Â â ¥Â â ¹Â â ºÂ â ¡Â Ã Â Ë Â Â¬Â Ã Â Å Â â  ¡ ⠢ How does that translate to Perl 5? -- Almost any animal is capable learning a stimulus/response association, given enough repetition. Experimental observation suggests that this isn't true if double-clicking is involved. - Lionel, Malcolm Ray, asr.
Re: [RFC] Perl6 Operator List, Take 5
On Wednesday, October 30, 2002, at 03:07 PM, Damian Conway wrote: In creating my operator list I deliberated shied away from the unary and binary multimorphic forms. But I do see Graham's point and would favour retaining polymorphic unary C^ at least. Meaning that the list: + - force to numeric context - - force to numeric context, negate +^- force to numeric context, complement ~ - force to string context ~^- force to string context, complement simply becomes: ^ - complement (type-specific) + - force to numeric context - - force to numeric context, negate ~ - force to string context Correct? MikeL
Re: [RFC] Perl6 Operator List, Take 5
Michael Lazzaro wrote: Meaning that the list: + - force to numeric context - - force to numeric context, negate +^- force to numeric context, complement ~ - force to string context ~^- force to string context, complement simply becomes: ^ - complement (type-specific) + - force to numeric context - - force to numeric context, negate ~ - force to string context Correct? that was what I was advocating, yes. Damian
Re: [RFC] Perl6 Operator List, Take 5
On Thu, 31 Oct 2002, Damian Conway wrote: : Forgive me but is this syntax really necessary. : Does it buy us enough over +1 and -1? Well, that was my first thought, but... : Proposed Now : :1..101..10 : 1..^10 1..9 : 1..^$x 1..$x-1 : 1^..10 2..10 : $x^..10 $x+1..10 : 1^..^10 2..9 : $x^..^$y $x+1..$y-1 : : I mean, for what it is, I do like the syntax, but is it useful enough to : warrant the extra cognitive load it brings with it? I think it helps a lot as soon as you get outside the realm of integers. And I think it helps a lot with integers too. It seems like you just want 0..^$size all the time in any C-derived language. I don't think it's just Ruby envy... In general, for any type, how do you write [$min .. $max - $step : $step] when you don't even necessarily have subtraction defined? We don't know how to do z - 1 in Perl 5, for instance. Larry
Re: [RFC] Perl6 Operator List, Take 5
Larry elucidated: In general, for any type, how do you write [$min .. $max - $step : $step] when you don't even necessarily have subtraction defined? We don't know how to do z - 1 in Perl 5, for instance. Okay. I buy that. Damian
Re: [RFC] Perl6 Operator List, Take 5
On 30/10/02 13:41 -0800, David Wheeler wrote: On Wednesday, October 30, 2002, at 01:35 PM, Graham Barr wrote: On Wed, Oct 30, 2002 at 01:25:44PM -0800, Austin Hastings wrote: --- Larry Wall [EMAIL PROTECTED] wrote: Do these French quotes come through? @a «+» @b Odd, I see them in this message. But In the message from Larry I see ?'s And I didn't see them in Austin's message, but I see them in yours. Your mailer did the right thing, it looks like. And I see white question marks over black diamonds on a white background. Of course the OS X termcap is imfamous. Cheers, Brian
Re: [RFC] Perl6 Operator List, Take 5
On Tue, 29 Oct 2002, Michael Lazzaro wrote:
:(is whitespace allowed inside the brackets, e.g. [ + ] vs. [+] ?)
I don't think so.
: unary (prefix) operators:
:. - method call on current topic
I think we have to have unary .= as well, if we're to do the
.=replace
trick on $_.
: unary (postfix) operators:
:... - [maybe] same as ..Inf [Damian votes Yes]
I wonder if we can possibly get the Rubyesque leaving out of
endpoints by saying something like 1..!10.
: other postfix operators:
:
:()- (when operator is expected)
:[]- array access
:{}- hash access
These now consistently require no space, and they're all
when an operator is expected, not just ().
: binary operators:
:
:(do more of these have possible +~? prefix modifiers,
: or only the boolean |^ ops?)
Well, things like already imply numeric, and things like lt already
imply string. The booleans are already officially polymorphic.
: + - * / % ** x xx ~ - arithmetic
: +=-=*=/=%=**=x=xx=~=
I don't think of x or ~ as arithmetic exactly...
: . .| .^ - bitwise (integer)
: operations
: .= .|= .^= = =
These should be + etc.
: sum prodcat reduce- [maybe]
That's Apocalypse 29. :-)
: ~~ !~ - smart match, smart non-match
:like unlike- [maybe] [Damian votes No]
Undecided.
:.. - range
:... - [maybe] range, exclusive of endpoint [Damian votes No]
Still thinking about ..! or ..^ or some such. Could have ^..^ and ^..
too, for all that.
:::= - binding, but more so
Cute, but nonexplanatory. Binding at compile time.
: trinary operator:
:
:?? ::- if/else
:
: parens, misc, and quotelike operators
:()
:[]- [when term is expected]
:{}- [when term is expected]
Again, all of these are when a term is expected, not just the latter two.
:m// - shorthand, matches
:s/// - shorthand, substitute
:tr/// - shorthand, transliterate
:
:'...' ... `...` /.../
: q qq qx rx qw [qm?]
: [+ qr ?]
No, the qr is dead. Long live the rx.
:...- readline
Iterate interator.
:(heredocs) - [exact format unknown]
Probably still the same, at least until we start thinking about it...
: magical whitespace modifier
:_ - [maybe] remove whitespace/newline
:(briefly discussed, but not an operator?)
We need something here. Underline is available.
: explicit radix specifications for integers:
:(we'll just handle this issue separately, OK?)
Fine. I'm not sure we actually have to change anything here from Perl 5.
Syntactic mangling could easily work for anyone who wants base 42.
: other uncategorized:
:(no decisions are implied about these, e.g. are they
: ops, listops, methods, whatever... decide later)
:
:my our - [declar]
:mapgrep
:sqrt log sin cos tan (etc...) - math
:lc lcfirst uc ucfirst
:intord oct hex bin
oct and hex are arguably backwards, typewise. They don't produce
octal or hex types, but rather consume them.
Larry
RE: [RFC] Perl6 Operator List, Take 5
Larry Wall [mailto:larry;wall.org] wrote: : unary (postfix) operators: :... - [maybe] same as ..Inf [Damian votes Yes] I wonder if we can possibly get the Rubyesque leaving out of endpoints by saying something like 1..!10. Perhaps we could use the less-than symbol: 1 .. 10 Similarly: 1 .. 10 == 2..9 Dave.
RE: [RFC] Perl6 Operator List, Take 5
On Tue, 29 Oct 2002, David Whipp wrote:
: Larry Wall [mailto:larry;wall.org] wrote:
: : unary (postfix) operators:
: :... - [maybe] same as ..Inf [Damian votes Yes]
:
: I wonder if we can possibly get the Rubyesque leaving out of
: endpoints by saying something like 1..!10.
:
: Perhaps we could use the less-than symbol: 1 .. 10
:
: Similarly: 1 .. 10 == 2..9
That front one is backwards--it would have to be 1 .. 10.
But the biggest problem is that 1..$iterator is valid syntax.
Of course, ..! and ..^ have the same problem. But it just seems like
it's really unlikely that someone would use a unary ! or ^ on the
endpoint term. So with 1..!$x or 1..^$x it's likely to be right if
we guess (per the longest token rule) that the operator is ..! or ..^.
The same can't be said of .., alas. But at least it might produce
a syntax error when it tries to parse the . Or no, it wouldn't
necessarily. This parses:
1..$iterator + 1;
but wrongly as
1 .. $iterator +1;
Ick.
Of course, Real Mathematicians will want [1..10) and (1..10] instead.
Double ick.
I kind like ..^ the best because ^ is currently read exclusive of
anyway, sort of...
And the arrow can be read up to, at least on that end of it. I think
that ..^ is going to be much, much more common than ^.. will be.
There's also an issue of what (1..10) - 1 would or should mean, if anything.
Does it mean (1..9)? Does 1 + (1..10) mean (2..10)?
And what would ('a' .. 'z') - 1 mean?
I think I'd better go to bed now...
Larry
Re: [RFC] Perl6 Operator List, Take 5
Larry Wall wrote: :... - [maybe] range, exclusive of endpoint [Damian votes No] Could have ^..^ and ^..too, for all that. OK, I just gotta say, that's _d*mn_ clever. Exclusive of endpoint -- It looks like what it is, and vice versa. I guess that's why you're our fearless leader. :-) I'll revise according to the notes, do some cleanup, and repost the single, re-condensed list. I also want to say again, for the record, I'm *really* looking forward to programming in this. It's going to be FUN. Bwah-ha-ha! MikeL
Re: [RFC] Perl6 Operator List, Take 5
: I wonder if we can possibly get the Rubyesque leaving out of
: endpoints by saying something like 1..!10.
:
: Similarly: 1 .. 10 == 2..9
There's also an issue of what (1..10) - 1 would or should
mean, if anything. Does it mean (1..9)? Does 1 + (1..10)
mean (2..10)?
And what would ('a' .. 'z') - 1 mean?
1..10-1 # 1..9
1+1..--10# 2..9
'a'..'z'-- # a - y
?
--
ralph
PS. [op] is such a sweet improvement. the [op=] vs [op]=
trick that then became possible, the move of ^ back to its
previous meaning, is nice icing.
RE: [RFC] Perl6 Operator List, Take 5
Larry Wall:
# Of course, Real Mathematicians will want [1..10) and (1..10] instead.
#
# Double ick.
Reminds me of the number-line notation you learn about *before*
precalculus (or whatever the value of
$you.schooling.grade[12].class{math}.name is) confuses everything, with
open vs. closed circles on a number line. How about:
1 oo 10 # (1, 10)
1 o. 10 # (1, 10]
1 .o 10 # [1, 10)
1 .. 10 # [1, 10]
(The scary part is that I'm not sure I'm joking any more...)
# There's also an issue of what (1..10) - 1 would or should
# mean, if anything. Does it mean (1..9)? Does 1 + (1..10)
# mean (2..10)?
#
# And what would ('a' .. 'z') - 1 mean?
Er, I would hope that it would be the same as scalar('a' .. 'z') - 1, or
['a' .. 'z'] - 1, or +['a' .. 'z'] - 1, or 26 - 1, or 25. But that
wouldn't be weird enough, I suppose--it's looking like Perl 6 will be
the official language of *The Matrix*. Free your mind! :^)
--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 Operator List, Take 5
Brent Dax wrote: Larry Wall: # There's also an issue of what (1..10) - 1 would or should # mean, if anything. Does it mean (1..9)? Does 1 + (1..10) Actually, I would at first glance think, based on the parens, that: (1..10)-1 means ((1-1)..(10-1)) means (0..9) and if someone has been playing a lot with the superposition stuff, that is probably what they would indeed expect. That's also a valuable interpretation, since it means you can say things like (1..$n) * 10 And get a list (10,20,...) without having to change $n. However, by the same logic, array * 10 means array [*] 10 which it doesn't. So maybe the correct interpretation of the above is indeed this: (1..10)-1 # (1..10).length-1, e.g. 9 (oops!) (1..10) [-] 1 # (0..9) (correct, if that's WYM) meaning that (1..10)-1 almost always does The Wrong Thing(!) MikeL
