[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
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
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
<[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 giv
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, thou
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 ar
--
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:
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
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
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 a
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
>
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 thr
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
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 th
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
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
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.
> 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
> > 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 ^[+]= @
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.
a
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
> >
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
--- 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, s
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
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
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 ^=
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 bec
>> 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 we
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 operat
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
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 f
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
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:
`<>` - synony
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 D
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
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 ($
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 po
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
>
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 '?' enfor
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.
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. Neith
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 )
...
>
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
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?
+&+|+^
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
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
> "ML" == Michael Lazzaro <[EMAIL PROTECTED]> writes:
ML>+&+|+^<<>>- bitwise (integer) operations
ML>+&= +|= +^= <<= >>=
ML>~&~|~^- charwise (string) operations
ML>~&= ~|= ~^=
i think those descriptions need to b
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 h
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
49 matches
Mail list logo
