Re: [RFC] Perl6 HyperOperator List
[EMAIL PROTECTED] (Smylers) writes: > In general I find backticks fairly jarring on the eyes, but they have to > be used for _something_ ... I think ugliness is actually a feature for vector ops. No sense having to strap your programmers to the mast. -- In a sense Christianity is like Jazz - if you need to ask the questions you won't understand the answers. - Bob Billing
Perl 6 Summary for last week
The Perl 6 Summary for the week ending 20021027 You may have noticed that this summary is late. Um... [looks sheepish, shuffles feet], the dog ate my homework. I did a tiny bit of procrastination at the beginning of the week and then got totally overtaken by events involving failed AC adaptors and general confusion. Sorry folks, it will probably happen again, but hopefully not in the near future. So, kicking off, as is customary, with perl6-internals before getting down to attempting to summarize the monster that was perl6-language: C# and Parrot The dialogue with Rhys Weatherley and Gopal V from the DotGNU project continues apace, mostly to do with clarifying what C# needs in the way of datatypes and the like. It appears that Leon Brocard is the go to guy if you need to know the exact details of almost anything in a language spec. Maybe he's just really good with Google. Gopal V wondered if there was someone involved in p5i who would mind acting as a liaison with the DotGNU people, who could give them a heads up when, say, the packfile format changed. Leopold Toetsch wondered what sort of changes were potential C# breakers, as there were probably things that we thought of as `internal' that the C# team could be depending on. Leo also thought that the liaison person should probably be Dan. http://makeashorterlink.com/?K57E12E42 Scratchpad confusion At the end of last week, Allen Short pointed out some discrepancies between the implementation of scratchpads and the description of them in PDD6. John Sillito reckoned that PDD6 was waiting on a rewrite from Dan, especially where Scratchpad PMCs were concerned as there were a couple of different patches waiting on Dan's say so. Dan also offered some clarification, but hasn't ruled on the Scratchpad PMCs yet. http://makeashorterlink.com/?B58E25E42 Help! Bugs! Crawling all over me! OR The road to 0.0.9 Steve Fink wants the GC bugs ironed out before he goes adding much in the way of new features, and he wants to start putting together a 0.0.9 with working GC too. To that end he deliberately broke all the tests by turning GC_DEBUG on for tests. There's a certain amount of cleverness involved in how he did this; read his post if you're interested. Peter Gibbs found what he thought was a fix for a couple of the failures and pointed to the possibility of a fundamental problem in MultiArray as the culprit for the remaining failure. Steve applied this patch with much rejoicing, and then came up with a trial patch that seemed to fix the multiarray triggered failure. This patch had not been finalized by the end of the week. Steve also kicked off discussion of the forthcoming 0.0.9 release, when he posted his list of prerequisites and sparked off a decent amount of discussion of various points. Steve's overarching goal for this release appears to be 'bug reduction and general consolidation'. http://makeashorterlink.com/?N19E21E42 http://makeashorterlink.com/?S2AE12E42 Keyed ops, the return. I think it's safe to say that some people aren't entirely happy with keyed ops as they stand now in Parrot. The week before, Leopold Toetsch had written a proposal for keyed ops. This week he supplied a proof of concept patch. Jürgen Bömmels liked it but Dan took a little more convincing. I'm not sure he is entirely convinced yet, but he's willing to live with it. http://makeashorterlink.com/?U5BE62E42 64-bit ints and non-capable hardware Dan announced that he was about to bite the bullet and declare that INTVALS have to be 64 bit integers and wanted to know of any (plausible) platforms that have neither native nor emulated 64 bit integers. Martin D Kealey pointed at what sounds like a scary proposal from C99 involving declarations and clever compilers and wondered if it might be a way forward for parrot. Rhys wondered how well the idea would play with something as dynamic as Parrot and the languages expected to run on it, but Martin didn't seem to think it would be much of a problem. http://makeashorterlink.com/?W1CE23E42 http://makeashorterlink.com/?Y1DE23E42 Configuring and DOD Erik Lechak couldn't get the latest parrot to build on WinXP. Josh Wilmes diagnosed a problem with the way the configuration tools probed for stack direction, and patched things so that stack direction detection was done at runtime once more. Jason Gloudon, who had moved the detection phase out into configuration time wasn't sure that this was a good idea 'cos it would lead to a performance hit in the stack walking code. Nicholas Clark, with his clever head on, came up with three different ways of doing things at runtime without a performance hit, and Dan blessed the third choice. http://makeashorte
Flexops as information preserving Bitops
So, on the train this morning, I had a moment of Satori. What's wrong with doing what we think of as bitwise operations using the flexops and adding a 'bitwise' context? So, a bitwise op becomes: bitwise ( $a | $b | $c & $d ); And the superposition will collapse in a 'mash everything together in bitop fashion' way. Or it'll stay entangled until it knows whether it's in numeric or string based context, but, once that is known, it'll do the bitwise collapse. Just a thought. Note that this doesn't preclude having bitwise ops as well, but it does look like being a handy dandy method to hang off the SuperposedCollection class (whatever it ends up being called). -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: Question about "for" loop
<[EMAIL PROTECTED]> writes:
> for @a -> $x, $y { ... $x is topic ... }
>
> for @a ; @b ->
> $x, $y ; $z { ... WHAT is topic ? ... }
>
> what is topic in multi stream loop ?
The first argument to the sub. Always. Unless you do 'is topic' after
a different arg. So, in the example given, $x is the topic.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: [RFC] Perl6 Operator List, Take 5
Luke Palmer writes: > > > > 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 > > it seems that this example does not work because : if is postfix op then it have to be "attached" $y = undef _ and "_" is just (optional) part of the name of all postfix operators. or $y = undef the first interpretation canneot work because unary undef op requires lvalue expression as its argument , and is not . but it seems , that anyway , the problem here is not with 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 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:)
>
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 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: Primitive Boolean type?
On Thursday, October 31, 2002, at 10:36 PM, Michael Lazzaro wrote: 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. :-) How do you answer that question when it's asked of Perl 5? David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Primitive Boolean type?
On Thursday, October 31, 2002, at 10:36 PM, Michael Lazzaro wrote: > 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. :-) Why? Plenty of languages get along just fine without a Boolean type. BASIC, C, LISP, Perl5, Python, TCL . . . -- 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 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: plaintive whine about 'for' syntax
On Thursday, October 31, 2002, at 10:03 PM, John Siracusa wrote:
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)
The current syntax offers a significant advantage, though. I'm assuming
parser knows to look for equal numbers of things on both sides of
the ->. If we go with the proposed alternate syntax, won't we run into
the problem where it sees:
for @a -> $a; as a complete postfix for loop that just happens to do
nothing?
I suppose the same could be said for the existing syntax. "for @a;"
would look like a loop with the default topic variable. Maybe I'm just
wrong, but the proposed syntax seems to introduce ambiguity by breaking
the for loop up a bit too much, while the current use of the "->" and
semicolons holds the whole thing together.
As for maintaining the sanctity of the semicolon, I would offer that
consistency of the arrow operator is more important.
Re: UTF-8 and Unicode FAQ, demos
On Thu, 31 Oct 2002, Luke Palmer wrote: > > now *theres* some brackets! > > Ooh! Let's use 2AF7 and 2AF8 for qw! Actually, I wanted to suggest »German quotes« instead of French for qw. :) ~ John Williams
Re: Perl6 Operator (REMAINING ISSUES)
On Thu, 31 Oct 2002, Ed Peschko wrote: > 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. Personally, I would like to see us come full circle back to just ^ again too. The main problem seems to be that we want ^ and ^^ for xor-ing things, so ^^ could be either a logical-xor or a vector-one-superposition. So what if we just made the [] optional? Then all the original hyper/vector documentation is still valid. (The meanings of ^+ ^|| ^<<= etc are all non-ambiguous.) For the ambiguous case, ^^ is logical-xor because it is used more often, and vector-one-superposition is unambiguously ^[^] . ~ John Williams
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: Perl6 Operator List
On Thu, 31 Oct 2002, Larry Wall wrote: > 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. And if there is no binary, then the postfix can have a space before it? Or are we introducing this new restriction to perl6 just because someone can define a binary operator:++ ? perl5 -le '$a = [[42]]; print $$a [0] [0] ++; print $$a[0][0]' 42 43 ~ John Williams
Re: Perl6 Operator (REMAINING ISSUES)
y> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm > Date: Fri, 1 Nov 2002 10:39:59 -0700 (MST) > From: John Williams <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > X-OriginalArrivalTime: 01 Nov 2002 17:40:00.0029 (UTC) FILETIME=[B38AC4D0:01C281CD] > X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/ > > On Thu, 31 Oct 2002, Ed Peschko wrote: > > > 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. > > Personally, I would like to see us come full circle back to just ^ again > too. > > The main problem seems to be that we want ^ and ^^ for xor-ing things, > so ^^ could be either a logical-xor or a vector-one-superposition. > > So what if we just made the [] optional? Then all the original > hyper/vector documentation is still valid. (The meanings of ^+ ^|| ^<<= > etc are all non-ambiguous.) For the ambiguous case, ^^ is logical-xor > because it is used more often, and vector-one-superposition is > unambiguously ^[^] . You know, I like it. In any "potentially ambiguous" cases, the non-vector version would be preferred. It doesn't seem exactly "elegant," but there's some appeal that I'm drawn to. Luke
Re: Perl6 Operator List
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm > Date: Fri, 1 Nov 2002 11:01:34 -0700 (MST) > From: John Williams <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> > X-OriginalArrivalTime: 01 Nov 2002 18:01:34.0398 (UTC) FILETIME=[B70BCDE0:01C281D0] > X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/ > > On Thu, 31 Oct 2002, Larry Wall wrote: > > > 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. > > And if there is no binary, then the postfix can have a space before it? > > Or are we introducing this new restriction to perl6 just because someone > can define a binary operator:++ ? > > perl5 -le '$a = [[42]]; print $$a [0] [0] ++; print $$a[0][0]' > 42 > 43 Ah, however: perl -le 'print($a ++)' syntax error at -e line 1, next char ) Execution of -e aborted due to compilation errors. So there's some mysterious rule like this in perl5, but I think it's got a couple more special cases, or something. Luke
Re: Perl6 Operator (REMAINING ISSUES)
> > right, and what does this all mean? I have yet to see a good meaning > > for > > @array ^[+]= @array2 ... > > I think it's this: > > @a [+=] @b -> @a[x] += @b[x] > > @a [+]= @b -> @temp = @a [+] @b; a = @temp; > Ok, so the '=' isn't being explicitly vectorized. So - @a ^[+]= @b; @a = (1,2,3,4); @b = (5,6,7,8); @temp = @a ^+ @b; = (1+5,2+6,3+7,4+8) = (6,8,10,12); @temp = (6,8,10,12); @a = (6,8,10,12); wheras: @a ^+= @b; $a[0] += $b[0]; $a[1] += $b[1]; $a[2] += $b[2]; $a[3] += $b[3]; $a[0] = 1 + 5; $a[1] = 2 + 6; $a[2] = 3 + 7; $a[3] = 4 + 8; @a = (6,8,10,12); ie: they are exactly the same. I'd say that '=' has *implicit* vectorization here in the array case. In the scalar case: @a ^[+]= 1; @temp = @a ^+ 1; it is exactly the same. @a ^+= 1; $a[0] +=1; $a[3] +=; So again, I don't see the difference between the two. ^[+]= and ^+= are synonyms as far as I can see, and hence no need for the first form. Ed
Re: Perl6 Operator (REMAINING ISSUES)
Ed Peschko writes: > > So again, I don't see the difference between the two. ^[+]= and ^+= are synonyms > as far as I can see, and hence no need for the first form. > > Ed > > > somebody before ( dont remember who) showed how they can be different if the first argument is scalar. arcadi .
Re: Perl6 Operator List
On Fri, Nov 01, 2002 at 11:01:34AM -0700, John Williams wrote: > On Thu, 31 Oct 2002, Larry Wall wrote: > > > 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. > > And if there is no binary, then the postfix can have a space before it? Sure, as long as you also put the space-eater. I'm not going to change my mind in the space of two messages. (Well, not this time...) > Or are we introducing this new restriction to perl6 just because someone > can define a binary operator:++ ? We are introducing a regularity. In a few spots it will look like a restriction. > perl5 -le '$a = [[42]]; print $$a [0] [0] ++; print $$a[0][0]' > 42 > 43 That will not parse in Perl 6. I promise. Larry
Re: Perl6 Operator (REMAINING ISSUES)
On Fri, 1 Nov 2002, Ed Peschko wrote: > @a ^[+]= @b; compared to > @a ^+= @b; > > ie: they are exactly the same. You are right, you get the same answer whether you do the hyper or the assignment first, except in the "scalar ^op= list", in which case doing the assignment last gets you the length of the list or some other useless result. > I'd say that '=' has *implicit* vectorization > here in the array case. In the scalar case: Right. ^= is rather pointless, because = already understands list context. OTOH, you can get some different effects out of ^= by virtue of the "dimensionally replicate, quantitatively undef-extend" rule for vectoring operators. @a ^= @b # @a.length == max( @a.length, @b.length ) @a ^= $b # all currently existing elements of @a are set to $b $b ^= @a # Yuck! $b = last element of @a. ~ John Williams
Re: Perl6 Operator (REMAINING ISSUES)
--- Ed Peschko <[EMAIL PROTECTED]> wrote: > > > right, and what does this all mean? I have yet to see a good > meaning > > > for > > > @array ^[+]= @array2 ... > > > > I think it's this: > > > > @a [+=] @b -> @a[x] += @b[x] > > > > @a [+]= @b -> @temp = @a [+] @b; a = @temp; > > > > Ok, so the '=' isn't being explicitly vectorized. So - > > @a ^[+]= @b; > > @a = (1,2,3,4); @b = (5,6,7,8); > > @temp = @a ^+ @b; = (1+5,2+6,3+7,4+8) = (6,8,10,12); > > @temp = (6,8,10,12); > > @a = (6,8,10,12); > > > wheras: > > @a ^+= @b; > > $a[0] += $b[0]; > $a[1] += $b[1]; > $a[2] += $b[2]; > $a[3] += $b[3]; > > $a[0] = 1 + 5; > $a[1] = 2 + 6; > $a[2] = 3 + 7; > $a[3] = 4 + 8; > > @a = (6,8,10,12); > > ie: they are exactly the same. I'd say that '=' has *implicit* > vectorization > here in the array case. Ed, Under normal definitions, you're right. But under overload, you're seeing two different sets of operators get invoked? @temp = @a [+] @b; @a = @temp; This invokes N iterations of (multidispatch(operator:+, $a[n], $b[n])), which likely results in: N x Some_Class.new N x Underlying_type.operator:+($a[n], $b[n]) N x Some_Class.operator:= followed by one invocation of @a.operator=. Potentially useful if objects should be "rebalanced" or "snapshot" or "transactionalized" or something whenever a vector operation happens. Especially where variables are tied, or represent fanciful classes with simplified interfaces, this will be significant. OTOH: @a [+=] @b This invokes N iterations of (multidispatch(operator:+=, $a[n], $b[n])) which likely results in (if it doesn't actually IMPLEMENT): N x Underlying_type.operator:+ N x Some_Class.operator:= and nothing else. So there's no "initialize the temp object" or "close down the original @a TIE" or "whatever" getting invoked. And that can be a win, database-session-closeout-wise, or whatever your TIE'ing application happens to be. =Austin __ Yahoo! - We Remember 9-11: A tribute to the more than 3,000 lives lost http://dir.remember.yahoo.com/tribute
Re: UTF-8 and Unicode FAQ, demos
On Fri, Nov 01, 2002 at 10:05:27AM -0700, John Williams wrote: > On Thu, 31 Oct 2002, Luke Palmer wrote: > > > > now *theres* some brackets! > > > > Ooh! Let's use 2AF7 and 2AF8 for qw! > > Actually, I wanted to suggest »German quotes« instead of French for qw. > > :) Well, the other guys are suggesting bow tie operators, so maybe we should keep «foo bar baz» with French quotes, and go with @a »*« @b for vector multiply. That suggests to me that the circumlocution could be >>*<<. That's presuming we also force the bitshifts to be qualified as +>> ~>>. Actually, we could use <> for qw too if here-docs always have to be <<' or <<". Or we could change here docs to vv"TAG" or some such that points downwards to where the text actually is. Larry
Re: Perl6 Operator (REMAINING ISSUES)
On Fri, Nov 01, 2002 at 10:35:08AM -0800, Ed Peschko wrote: > So again, I don't see the difference between the two. ^[+]= and ^+= are synonyms > as far as I can see, and hence no need for the first form. Only in the absence of overloading, and only because we've naively defined array ops to always do "union" rather than "intersection". If there were a vector op that took the shorter of two arrays as the overall length, then @a = @a »op« @b will truncate @a, while @a »op=« @b might only change the elements they have in common. I don't know if we'll have any such operators on arrays, but they've already been proposed for hashes. So %a »op=« %b might well be different from %a »op«= %b depending on what op is. Larry
Re: Perl6 Operator (REMAINING ISSUES)
On Fri, Nov 01, 2002 at 11:51:17AM -0700, John Williams wrote: > Right. ^= is rather pointless, because = already understands list > context. They're not quite the same because list assignment truncates first. To wit: @a = [1,2,3]; @b = [4,5]; @a = @b;# @a gets [4,5] @a ^= @b; # @a gets [4,5,undef] And if you define = as an "intersection" rather than a "union" op, you'd get @a ^= @b; # @a gets [4,5,3] Maybe. Or there could be a truncation implicit in intersection operators. > OTOH, you can get some different effects out of ^= by virtue of the > "dimensionally replicate, quantitatively undef-extend" rule for vectoring > operators. > >@a ^= @b # @a.length == max( @a.length, @b.length ) >@a ^= $b # all currently existing elements of @a are set to $b >$b ^= @a # Yuck! $b = last element of @a. Every possible utterance doesn't have to make practical sense... Larry
Re: Perl6 Operator (REMAINING ISSUES)
On Fri, 1 Nov 2002, it was written: > On Fri, Nov 01, 2002 at 10:35:08AM -0800, Ed Peschko wrote: > > So again, I don't see the difference between the two. ^[+]= and ^+= are synonyms > > as far as I can see, and hence no need for the first form. > > Only in the absence of overloading, and only because we've naively > defined array ops to always do "union" rather than "intersection". > If there were a vector op that took the shorter of two arrays as the > overall length, then > > @a = @a »op« @b Ooo! I have it! @a »op« @b # picks the shorter of the two lengths (intersection) @a «op» @b # picks the longer of the two lengths (union) Maybe the hyper-hash guys could work with it too. ~ John Williams
Re: Perl6 Operator (REMAINING ISSUES)
>> So again, I don't see the difference between the two. ^[+]= and ^+= are >> synonyms as far as I can see, and hence no need for the first form. > Only in the absence of overloading, and only because we've naively defined > array ops to always do "union" rather than "intersection". If there were a > vector op that took the shorter of two arrays as the overall length, then > > @a = @a »op« @b > > will truncate @a, while > > @a »op=« @b > > might only change the elements they have in common. I don't know if we'll > have any such operators on arrays, but they've already been proposed for > hashes. argh. you're scaring me just mentioning '»' and '«' as vector ops (ascii please!). Also, just mentioning array versus intersection scares me. You could make a case that: @a ^+= @b; does a truncate on @a if @b is shorter, and that @a v+= @b; is the 'true' union operator. You could hence argue that there are really two vector operators one for union and one for intersection, and that the place to define whether or not something as intersection or union belongs there, and not in the operator itself. Ed
vectorization (union and intersection operators)
I'm probably opening up a whole new can of worms here, but if we said that the
following were both vector operators:
^ == intersection operator
v == union operator
then these could have potentially useful meanings on their *own* as set
operators, as well as modifying other operators. For example:
@a = (1,2,3);
@b = (4,1,3);
@a = @a ^ @b; # @a = (1,3);
@a = @a v @b; # @a = (1,2,3,4);
ie @a = @a ^ @b; means
grep($MARK{$_}++, @a);
for @b { push (@result, $_) if ($MARK{$_} && !$MARK2{$_}++); }
@a = @result;
@a = @a v @b; means
grep( $MARK{$_}++, @a );
@result= @a;
for @b { push (@result, $_) if (!$MARK{$_}++) }
I know that this is far more useful behavior than the currently proposed meaning
of @a ^= @b... even though if its a little off kilter with the other meanings:
@a = (1,2,3);
@b = (4,1,3,5);
@a ^+= @b; # (5,3,6);
@a v+= @b; # (5,3,6,5);
etc. etc.
Ed
[RFC] Perl Operator List, TAKE 6
Adjusted for the most recent notes: includes «op» as the preferred (and
possibly only) spelling of "vectorize". Everything but a few hyperop
issues appears to be close to final, by my count: if/when Larry sticks
a fork() in it, it's done.
hyperoperators:
«op» - When used with any unary or binary operator,
"vectorizes" the operator.
»op« - [maybe] same, but intersection instead of union.
^[op] - [maybe] synonym for «op»
- [maybe] synonym for »op«
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 string context
^ - complement, type-specific
. - method call on current topic
.=- method call on current topic, replaces topic
++- preincrement
--- predecrement
unary and other postfix operators:
These are used as postfix operators when encountered where
an operator is expected. No space is allowed between these
postfixes and the elements they are operating on.
++- postincrement
--- postdecrement
... - synonym for ..Inf
()- method call
[]- array access
{}- hash access
binary operators:
< > <=>===!=<=>- comparision (numeric)
lt gtlegeeqnecmp- comparision (string)
+ - * / % **- arithmetic
+=-=*=/=%=**=
~ ~= - string concat
x x= - string repetition
xxxx= - list replication
&&||^^// - boolean operations
&&= ||= ^^= //=
and orxor err
+&+|+^<<>>- bitwise (integer) operations
+&= +|= +^= <<= >>=
~&~|~^- charwise (string) operations
~&= ~|= ~^=
?&?|?^- C-like boolean operations
?&= ?|= ?^= - (result is always just 1 or 0)
& | ^ - superpositional operations
&=|=^=- conjunctive, disjunctive, exclusive
all any one none- conj, disj, excl, dismissive
~~ !~- smart match, smart non-match
=>- pair creator
, - list creator
; - "greater comma", list-of-lists creator
: - adverbial
. - method call
.. - range
^.. - [maybe] range, exclusive of endpoint(s)
..^
^..^
=- assignment
:= - runtime binding
::= - compiletime binding
trinary operator:
?? ::- if/else
parens, misc, and quotelike operators:
These may appear where a term is expected.
()
[]
{}
m// - shorthand, "matches"
s/// - shorthand, "substitute"
tr/// - shorthand, "transliterate"
'...' "..." `...` /.../
q qq qx rx qw [qm?]
<...>- iteration
(heredocs) - [exact format unknown; probably as perl5]
magical whitespace modifier:
_ - When used at the end of a line or between
statement elements, acts to "remove" whitespace
when interpreting the statement. (Allows
whitespace to appear without invoking any
special interpretations normally associated
with that whitespace.)
named unary (prefix) operators, terms, and other
important assorteds, identified when possible:
-X - [op] filetest operators
ref - [op]
exists - [op]
delete - [op]
defined - [op]
undef- [op]
undef- [term]
temp - [op]
let - [op]
but - [op] val properties
${ } - [deref] dereference scalarref
@{ } - [deref]
%{ } - [deref]
&{ } - [deref]
... - [term] yada**3
Inf - [term]
NaN - [term]
is - [declar] var properties
-> - [declar] like 'sub'
hash - [declar] force hash context
MikeL
Re: Primitive Boolean type?
On Friday, November 1, 2002, at 08:02 AM, Mark J. Reed wrote: 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. :-) Why? Plenty of languages get along just fine without a Boolean type. BASIC, C, LISP, Perl5, Python, TCL . . . In langs that do not recognize boolean as a type, the convention is either to use an untyped thing or the "littlest possible" thing as a boolean type. (The latter has more possibilities for efficiency, obviously.) Let's look at a presumably common Perl6 construct: If boolean is not a type, smart people are going to use the smallest possible thing, e.g. "bit", to declare boolean "true/false" vars and attributes. has bit $.is_plugged_in; They're going to do it whether we want them to or not (at least, I know I would), because they want to store a true/false value, and they want it to be enforced, and they want it to be small. So the above is the closest to DWIM that we have in Perl6 if you want to store a boolean value in a very compact form, correct? If not, how better would we say it? Since a "bit" can't even have properties (tho a "Bit" can), it really is, for all practical purposes, a boolean value, and can be treated as such. Fine and dandy, that's OK. But is that WYM? No. We've declared that a "bit" is _not_ a boolean, so the above is just a hack. It's not WYM it all, it just happens to do the right thing for all possible cases. And for proof that it's wrong, we have "Bit". "Bit" can be "1 but false", or "0 but true", etc. "Bit" is therefore much more clearly not a boolean: it's a 1 or 0, not a true or false. The usage of "bit" as a boolean breaks down if you think of it as the primitive of "Bit". It's not WYM anymore. So what is the "official" way to efficiently store the result of a boolean expression, for example? If not as a "bit", then what? If anything, I would suggest a primitive type, "bool", that has no promoted type "Bool". It can just be a placeholder -- a "bit" alias -- but I still don't understand the compelling reason for saying: has bit $.is_plugged_in; when WYM is, unambiguously: has boolean $.is_plugged_in; It's an excruciatingly common case, and yet we're making it into something that takes more than one sentence to explain. We're ignoring the feathers and the quacking: is this a case of being Too Smart For Our Own Good, here? MikeL
Re: Primitive Boolean type?
On Friday, November 1, 2002, at 12:24 PM, Michael Lazzaro wrote:
So what is the "official" way to efficiently store the result of a
boolean expression, for example? If not as a "bit", then what?
If anything, I would suggest a primitive type, "bool", that has no
promoted type "Bool". It can just be a placeholder -- a "bit" alias
-- but I still don't understand the compelling reason for saying:
has bit $.is_plugged_in;
when WYM is, unambiguously:
has boolean $.is_plugged_in;
The problem with this is that you have explicitly introduced true and
false into the language, and have therefore destroyed the utility of
context:
my boolean $bool = 0; # False.
my $foo = ''; # False context.
if ($foo eq $bool) {
# Oops!
}
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Re: [RFC] Perl Operator List, TAKE 6
On Friday, November 1, 2002, at 12:21 PM, Michael Lazzaro wrote: ^[op] - [maybe] synonym for «op» - [maybe] synonym for »op« I think that would be: `<> - synonym for «op» `>>op<< - synonym for »op« Unless I misunderstood Larry's post, in which case it might be: `<>` - synonym for «op» `>>op<<` - synonym for »op« Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: [RFC] Perl Operator List, TAKE 6
On Fri 01 Nov, Michael Lazzaro wrote: > >(heredocs) - [exact format unknown; probably as perl5] > There are comments by Larry in Appo 2 wrt RFCs 111 and 162. Appo 2: === 111 aaa Here Docs Terminators (Was Whitespace and Here Docs) 162 abb Heredoc Contents RFC 111: Here Docs Terminators (Was Whitespace and Here Docs) Fine. RFC 162: Heredoc contents I think I like option (e) the best: remove whitespace equivalent to the terminator. By default, if it has to dwim, it should dwim assuming that hard tabs are 8 spaces wide. This should not generally pose a problem, since most of the time the tabbing will be consistent throughout anyway, and no dwimming will be necessary. This puts the onus on people using nonstandard tabs to make sure they're consistent so that Perl doesn't have to guess. Any additional mangling can easily be accomplished by a user-defined operator. RFC111: === Perl6 should ignore any whitespace before the terminator of a heredoc on any line. Further it should ignore any whitespace ";"s (and comments) that follow the terminator. Perl should also ignore whitespace between the << and the terminator. Discussion took place on allowing statements following the terminator, but generally these where thought of as a bad idea. So only ";" and comments should occour on the same line. All of these should work: print
Re: [RFC] Perl Operator List, TAKE 6
On Fri, 1 Nov 2002, Michael Lazzaro wrote: >... - synonym for ..Inf Did I miss the report of the bistable ... operator's death? I've looked around, but I can't seem to find it. ~ John Williams
RE: Primitive Boolean type?
David Wheeler [mailto:david@;wheeler.net] wrote:
> The problem with this is that you have explicitly introduced true and
> false into the language, and have therefore destroyed the utility of
> context:
>
>my boolean $bool = 0; # False.
>my $foo = ''; # False context.
>if ($foo eq $bool) {
># Oops!
>}
If I am not mistaken, we already have explicitly introduced
true and false into the language:
my $bar = 0 but true;
my $bas = 0 but false;
A boolean type is therefore not quite as big a stretch as
you imply.
But we still have to deal with the expression issue:
if ($bar eq $bas) {} # true
if (?$bar eq ?$bas) {} # false
my $bool = true;
if ($bool eq $bar) {} # ???
Presumably, there exist rules for implicit casting when
comparing objects of different types. If we have a rule
that says that "if either operand is a boolean, then both
are compared as booleans", then things would work just
fine (except the the things I haven't considered ;-)).
The question of "what is C" is really an implementation
issue. It could be a superposition of all true values; or it
could just be a predefined value, that has some special magic
associated with it. Perhaps its just a keyword, whose context
determines whether it is a value, or a property.
Dave.
RE: [RFC] Perl Operator List, TAKE 6
David Wheeler wrote: > On Friday, November 1, 2002, at 12:21 PM, Michael Lazzaro wrote: > > > ^[op] - [maybe] synonym for «op» > > - [maybe] synonym for »op« > > I think that would be: > >`<> - synonym for «op» >`>>op<< - synonym for »op« > > Unless I misunderstood Larry's post, in which case it might be: > >`<>` - synonym for «op» >`>>op<<` - synonym for »op« I think that was: `<> - synonym for «op» `>>op`<< - synonym for »op« Larry wrote: > I could see using backtick as the "escape" code for things > like `<< or `>> which would turn into what some benighted > soul called "girly" angles. -- 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]
[RFC] Perl Operator List, TAKE 6
Michael Lazzaro writes:
> magical whitespace modifier:
>
>_ - When used at the end of a line or between
>statement elements, acts to "remove" whitespace
>when interpreting the statement. (Allows
>whitespace to appear without invoking any
>special interpretations normally associated
>with that whitespace.)
>
my understanding from the discussions was that
"free" ( separated by spases ) _ is still placeholder . and it
becomes "spaceeater" only when "attached" to operator . And a special
rule for block ending curly "}_" .
_ - "spaceeater" modifier
Generally , no space is allowed between term and postfix
operator. to relax that rule use the "spaceeater"-prefixed form
_op of the operator. e.g. @a[1] is same as @a _[1] . Binary
operator is allowed to have no space before it if there is no
postfix operator of the same name. Terms like {code} , {hash} ,
[array] have to have space before them if stand after term.
or
Any postfix operator op can be used in the form _op. that allows
whitespace to appear between term and operator without invoking
any special interpretations normally associated with that
whitespace.
arcadi
Re: Primitive Boolean type?
On Friday, November 1, 2002, at 01:38 PM, David Whipp wrote: Presumably, there exist rules for implicit casting when comparing objects of different types. If we have a rule My initial assumption is that nothing would change. Namely, == compares numerically, eq compares strings, and '?' enforces booleanness. In numeric context, bool evaluates to 1 or 0; in string context, "1" or "0": my bool $t = 1; ($t == 1) true ($t == 5) false ($t == ?5) true ($t eq '') false ($t eq '0') false ($t eq '1') true ($t eq 'foo') false ($t eq ?'foo') true which is the exact equiv of "bit" behavior, I believe. It's just a more descriptive name for a common usage. But here's where things get more interesting. If say $t is a numeric "bit", not a true boolean: ($t == (0 but true )) (1 != 0, so false) *** ($t == (1 but false)) (1 == 1, so true ) *** ($t == ?(0 but true )) (1 == 1, so true ) ($t == ?(1 but false)) (1 != 0, so false) Which may or may not be surprising. But if you say you can store true booleans as a "bool" type, and '==' knows how to deal with them: ($t == (0 but true )) (true == true, so true ) *** ($t == (1 but false)) (true != false, so false) *** ($t == ?(0 but true )) (true == true, so true ) ($t == ?(1 but false)) (true != false, so false) Whether that is an argument for or against a non-numeric 'bool' type depends on your point of view. In any event, if I want to store the result of a boolean expression: my $lit = ($lights == "on"); What type do I declare $lit as, in order for it to do what I mean? MikeL
eq Vs == Vs ~~ ( was Re: Primitive Boolean type?)
Michael Lazzaro [mailto:mlazzaro@;cognitivity.com] wrote > On Friday, November 1, 2002, at 01:38 PM, David Whipp wrote: > > Presumably, there exist rules for implicit casting when > > comparing objects of different types. If we have a rule > > My initial assumption is that nothing would change. Namely, == > compares numerically, eq compares strings, and '?' enforces > booleanness. In numeric context, bool evaluates to 1 or 0; in string > context, "1" or "0": Perhaps I was assuming things that I shouldn't. So lets clarify. In Perl6, we have 3 equality operators: ==, eq and ~~. The last of these is a special "smart-match", so it doesn't really count as an equality operator. In Perl5, == compares numerically; and eq compares stringically (if that's a real word ;). In Perl6, everything is an object. So almost everything is neither a number nor a string. It probably doesn't make sense to cast things to strings/ints, just to compare them. We probably want a standard method: .equals(), that does a class-specific comparison. The question is, will we be modifying the definnitions of == and eq, so that one will call the .equals method explicity. And what does the other do? Do we want to define them in terms of identity vs equality? Then, is identity a class-specific thing (i.e. a .identical() method); or is it an "address-in-memory" kind of thing? Did I miss a previous discussion of this? Dave.
RE: Perl6 Operator (REMAINING ISSUES)
On 31 Oct 2002 at 16:04, Brent Dax wrote: > 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. gvim looks and acts a lot like usual Windows editors if you install it in proper 'windows compatible' mode. Still it is a bit different. -- Markus Laire 'malaire' <[EMAIL PROTECTED]>
Re: Perl6 Operator (REMAINING ISSUES)
to me , this discussion approaches the conclusion that
^[] and v[] are *just* another operators with their own behavior
that accept as ( optional ) argument a Code reference .
to follow the beautifull philosophy of perl6 -- "A is just B" we can
say ( following Larry Wall )
...
> A Perl5 magic is just a property.
> A Perl5 attribute is just a property.
> A block is just a closure.
> A control structure is just a subroutine that can call closures.
...
(maybe...)
A "for" loop is *almost* a subroutine that can call closures .
A vector operation is just a ( cryptographic ) "for" loop
with one or two input streams and name inside brackets
as a closure.
so it is just a function :
sub infix:^[] ( Code &op : Array @a , Array @b
) is parsed /^[ | \[\] ]/
{
my @inds = union( @a.keys, @b.keys);
return for @inds {
&op ( @a[$_] , @b[$_] ) ;
}
}
sub infix:v[] ( Code &op : Array @a , Array @b
) is parsed /^[ | \[\] ]/
{
my @inds = intersection( @a.keys, @b.keys);
return for @inds {
&op ( @a[$_] , @b[$_] ) ;
}
}
or maybe
sub infix:^[] ( Code &op : Array @a , Array @b
) is parsed /^[ | \[\] ]/
{
return for @a ; @b -> ($x is rw ; $y is rw ) {
&op ( $x , $y ) ;
}
}
sub postfix:^[] ( Code &op : Array @a
) is parsed /^[ | \[\] ]/
{ for @a -> $x is rw &op( $x ) }
and analogous things for v[] . and this can be prefix, infix, postfix
; and each argument can be $a, @a, %a ; so it is a multimethod.
in that case the vectorization is *compleatly* orthogonal to the
details of op and we even can have something like
@a ^[{ $^a > $^b ?? 1 :: ($^a,$^b) := ($^b,$^a) }] @b
arcadi
Re: UTF-8 and Unicode FAQ, demos
Larry has been consistently using OxAB op 0xBB in his messages to represent a (French quote) hyperop, (corresponding to the Unicode characters 0x00AB and 0x00BB) which is consistent with the iso-8859-1 encoding (despite the fact that my mailserver or his mailer insists on labelling those messages as UTF-8). However, the UTF-8 encoding of those Unicode characters actually is: 0xC2AB op 0xC2BB .. As far as I understand it, the UTF-8 encoding only allows single byte representations of characters if they fall in the 0x00 to 0x7F range. So the question is, if I'm writing a program and I actually want to use one of these ops, do I put 0xAB op 0xBB or 0xC2AB op 0xC2BB ? -- Matt, who'd never thought he'd have to do hex dumps to debug his Perl programs ;) -- Matthew Zimmerman Interdisciplinary Biophysics, University of Virginia http://www.people.virginia.edu/~mdz4c/
Re: [RFC] Perl Operator List, TAKE 6
On Fri, Nov 01, 2002 at 12:21:43PM -0800, Michael Lazzaro wrote: > +&+|+^<<>>- bitwise (integer) operations > +&= +|= +^= <<= >>= I might have missed this, but if + introduces bitwise operations, why aren't we using it in the shift operations? +&+|+^+<+>- bitwise (integer) operations +&= +|= +^= +<= +>= Would seem to be more consistent and frees up << and >> for something else. andrew -- Virgo: (Aug. 23 - Sept. 22) It's been almost three decades, but you think you're finally beginning to recover from the long, national nightmare of Vietnam movies.
Re: Perl6 Operator (REMAINING ISSUES)
Larry Wall <> writes:
> On Fri, Nov 01, 2002 at 11:51:17AM -0700, John Williams wrote:
> > Right. ^= is rather pointless, because = already understands list
> > context.
>
> They're not quite the same because list assignment truncates first. To wit:
>
> @a = [1,2,3];
> @b = [4,5];
>
> @a = @b; # @a gets [4,5]
>
> @a ^= @b;# @a gets [4,5,undef]
>
> And if you define = as an "intersection" rather than a "union" op, you'd get
>
> @a ^= @b;# @a gets [4,5,3]
>
> Maybe. Or there could be a truncation implicit in intersection operators.
>
is it possible to make more clear this entry in the perl6 just-ice :
for loop is just ...
because it seems that all "plaintive wine" flows because that is
unclear .
because the second part seems to be obvious :
vector operation is just a "for" loop with arguments "scattered" around (
and inside) it .
something like
sub operator:^[] (Code &op, @a, @b) is parsed /\^\[\]/ { ... }
if we assume that ^[] staff is just a "for" loop ( that is, subroutine
) with one ( for prefix/postfix) or two ( for infix ) input streams (
wich can be degenerate if one of the arguments is scalar ) ( and ^[] is
more general , because it can accept hashes ( maybe we should allow
hash as input stream in "for" loop ) ) so if we assume that,
than probably the decision on union/intersection in vector ops and for
loop with multiple streams should be unifyed .
in for loop we have special "|" , "&" , stream separators to
distinguish/force what we want. why for vector operations this have to
be more implicit ? ( or may be I misunderstood and It is not ) .
in other words , is it going to be that each op will have its own
default behavior ( with respect to unify/intersect and such ) when
vectorized ? can I define an operator and be sure about its behavior
when vectorized , or should I specify it at scalar operator definition
, or should I define explicitely both scalar and vector version.
arcadi
Re: Perl6 Operator (REMAINING ISSUES)
On Sat, Nov 02, 2002 at 02:18:44AM +0200, [EMAIL PROTECTED] wrote:
>
snip ...
>
> in that case the vectorization is *compleatly* orthogonal to the
> details of op and we even can have something like
>
> @a ^[{ $^a > $^b ?? 1 :: ($^a,$^b) := ($^b,$^a) }] @b
>
I agree with all that you said above, I'm just saying we should make typing []
*optional*. 99% of the time, people are not going to need it, as they are not
defining their own operators as you did above.
Ed
Re: [RFC] Perl Operator List, TAKE 6
> "ML" == Michael Lazzaro <[EMAIL PROTECTED]> writes: ML>+&+|+^<<>>- bitwise (integer) operations ML>+&= +|= +^= <<= >>= ML>~&~|~^- charwise (string) operations ML>~&= ~|= ~^= i think those descriptions need to be a little better. i would say 'bitwise operations on (integer|string) value. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com - Stem and Perl Development, Systems Architecture, Design and Coding Search or Offer Perl Jobs http://jobs.perl.org
Re: Perl6 Operator (REMAINING ISSUES)
Ed Peschko writes: > I agree with all that you said above, I'm just saying we should make typing [] > *optional*. 99% of the time, people are not going to need it, as they are not > defining their own operators as you did above. > > Ed > > long ago ( when xor was "!" and ^ was called hyper ) Larry Wall was talking about allowing spaces between "bulding blocks of long operators @a ^ .+ = @b . so optional [ ] in vector operations becomes *very* similar to optional ( ) in function call . Now almost sure , that name of the vectorization will change couple of times ( and if it's sub one ( everyone will ! ) can define alias &operator:^[] := &operator:`<<>>` ( very vague ) ). so , maybe , the fruitfull way to generalize vector operations is to say : perl do not have vector operations . perl have operator algebra ( does it ? ) that can produce "vector" version of any operator , but more so . op op = ^ op v op t op ... arcadi
Re: eq Vs == Vs ~~ ( was Re: Primitive Boolean type?)
See http://archive.develooper.com/perl6-internals@;perl.org/msg11308.html for a closely-related discussion. /s On Fri, 1 Nov 2002, David Whipp wrote: > In Perl6, everything is an object. So almost everything is > neither a number nor a string. It probably doesn't make sense > to cast things to strings/ints, just to compare them. We > probably want a standard method: .equals(), that does a > class-specific comparison. > > The question is, will we be modifying the definnitions of == > and eq, so that one will call the .equals method explicity. And > what does the other do? Do we want to define them in terms of > identity vs equality? Then, is identity a class-specific thing > (i.e. a .identical() method); or is it an "address-in-memory" > kind of thing? > > Did I miss a previous discussion of this? > > > Dave. >
